It can.
Earlier this week Scott Chacon of GitHub presented his approach to projects, called Developer Driven Development, in a keynote address at CodeMash 2011. I won't try to explain DDD here, since the details aren't germane to this post.
However, key to DDD is that you must have careful hiring practices, careful to the point that you only hire people that already demonstrate a commitment to the project and possess great knowledge of the domain. (My words, not his, but I think he'd agree.) Hire those that are already involved in the project or in related ones. Clearly, to be already involved in the project before you are hired likely implies you are either involved in an open source project or are an actively involved customer or user of the product, be it open source or commercial.
Can that be applied to Corporate America? Not completely sure, but we can certainly apply some lessons. If your team hasn't already caught the vision, you need to help them catch the vision. This is important on any project, agile or not. But its importance is indirectly proportional to the extent to which you have an effective voice for the business involved with the team. That is, the less that the team understands the business need already, the more that vision casting is needed. The more that the team knows the business need own their own, the less involvement the team needs from "the business".
I've been on at least one team of note in Corporate America that the single voice of the business was successfully shifted to the team. In this case the team sold the business on a need. The team was given the leeway to run with the idea. Each person brought to the project what they thought the project needed. Each person on the team had a voice in prioritization. Anything that was to get done had to have the support of the team. (So, this wasn't a free-for-all to the extent that an open source project would be. Everyone did not go off and build whichever feature they wanted. The team agreed to the iteration's backlog.)
This worked because the team wanted it to. We wanted to keep doing what we were doing. We liked the product, the project, the team. To keep it going we had to demonstrate value to the organization that was paying the bills. So, we listened to those using the product and took their needs and suggestions into consideration.
It worked much like the open source model: I build what I want, what is interesting to me. But motivation is multifaceted. I'd like help from others, so I have to consider their interests. I'd like my product to be useful, to be used. I'd enjoy a little fame or appreciation from others. I'd like enough money out of the project to take money off the table. So if I'm relying on the product to pay the bills or support my multifaceted motivation, then I'm going to listen to my users and supporters.
It's going too far to say that you cannot shift "single voice of the business" to the team. A trusting cross functional team with empowered team members sharing accountability who have the vision can BE the single voice of the business.
In your example, the team went to the business and said "this is what we want to do". The business said "okay, go do it". To me, the business made the decision that what the team wanted to do was the highest priority and that everything else could wait until the team was done.
ReplyDeleteThe team did not make that decision.
What happens in most corporate environments is that you have multiple stakeholders all asking for stuff from the team. The team is forced to manage the tradeoffs across these stakeholders, and will inevitably have to make decisions that need to be made by the business.
That is what cannot happen.
The point of #3 wasn't that the team can't manage a list of features in a backlog, even add featurs. The team shouldn't be asked to make decisions that are supposed to be owned by the business stakeholders.
Now, if we are talking about a small team where the business is the developers, that's a different story. If the team has been explicitly given permission to build whatever they want, with no guidance from the business, that's fine, but certainly not the way I would spend my money.
I stand by my point ;-) The business needs to make business decisions. If they choose to defer their business decisions to the team, whatever... but no complaining when you don't get what you expect.
Right -- the team in my story did not decide to go off on its own without permission.
ReplyDeleteBut the team did "have multiple stakeholders all asking for stuff from the team". Stuff from multiple other divisions of the company.
Why can't a team be smart enough, mature enough, trusted enough by the business to make prioritization decisions among stakeholders? Aren't we supposed to like generalizing specialists and trust and cross functional teams? Isn't it okay for a Product Owner to "pair" with a tester or programmer? Shouldn't the PO also be a generalizing specialist? Why would it be unwise to push that to the extreme, to go all the way, and have the team be the PO?
I respect you for standing by your point, of course. But you are wrong. :-) Or maybe your wording could be better. I'm okay giving a warning about this approach. It's certainly a more advanced approach. But we shouldn't say it "cannot happen". That wording implies that you cannot be agile or you cannot be successful or you really must not do this. That's going too far.
The team can't make the decision because they don't have enough information or exposure to do a proper return on investment analysis of all the features. I'd argue that if they did, then maybe the developers don't need the business people (or they could be running the same business by themselves)?
ReplyDeleteIn my view it is irresponsible and unethical for developers to make those kinds of decisions.
Thanks for commenting, joshilewis.
ReplyDeleteWhy do you assume all teams don't have the info they need? Maybe my team does. In fact, it's a rare product owner that can do a proper return on investment analysis of all the features. They usually wing it. In my example, the team understands the product and the need. The product was their idea in the first place.
For many companies it may indeed be irresponsible for developers to make these decisions, but not in all. That's my only point.
I don't see how ethics has anything to do with this.