CAN: Shifting the Voice of the Business to the Team

I've been thinking about Mike Cottmeyer's "12 Keys to Success with Agile", specifically his bullet #3, single voice of the business, where he says "This cannot be shifted to the team..."

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.

Wearing the Right Hat

A Scrum Product Owner at a client of mine once told me he didn't trust development to build what he wanted built. Sadly, I find this quite common with the more technical POs. The lack of trust was largely due to his negative experience with some other dev team at a different company. His concern was that future value would be blocked by using a simplistic approach now. This PO therefore stepped way over the PO/DEV responsibility line into specifying some of the "how" for a set of stories.

Lack of trust is a significant issue. I could have told the PO that he needs to be able to trust the team. I could have suggested he create opportunity to build that trust, or change the team. Either way, that would take some time and we can work on that. But that's not the focus of this post.

And I could have explained emergent design and the danger of over-architecting things now. I could have told him YAGNI, but have also said that it is okay to share the big-picture vision with the dev team. That it's okay for the dev team to think about where they are headed long term as long as they "pay as you go" and not design and build too much up front. But that's not the focus of this post either.

The focus of this post is that I told him it was okay for him to not trust the developers for now and that it was okay for him to step over the line.

Now, before you take away my Agile Badge, let me explain myself.

Product Owner	Architect

I told the PO that if he is technically capable and can pull it off, then he can AT THE APPROPRIATE TIME review development's planned approach and make suggestions. I told him he can have a PO hat and an architect hat, but that he can only wear one at a time and he needs to wear the correct one at the correct time. He must wear the PO-only hat and only the PO hat during the planning game. Once the business requirement is sized, split, resized, scheduled, and planned, he can visibly remove his PO hat and put on his architect hat during the design and tasking part of the sprint.

In this case, I told him that I believe he is wrong and most likely doesn't need what he was requesting and that what he was requesting will greatly complicate the design and require much much more code than necessary. There was a better approach. Nevertheless, I didn't tell him not to put forth his ideas. For me, it's just a matter of timing.

What would you have done?