This week, I got to observe the kick off of a new Lean-Agile project. After being bogged down for several months in requirements gathering, it was amazing to watch this Lean-Agile project Team coalesce around an approach with priorities that would let them deliver value quickly. One of the greatest contributing factors to their success was the involvement of their Product Owner, who is perhaps the best example of a Product Owner I have ever seen.

The Planning Event was scheduled for most of the week and involved both developers and the Business. By the end of that week, they hoped to have a list of stories and tasks and milestones and get ready to start work. The Technical Owner and ScrumMaster had done a good job setting the stage. One of the smartest things they did was to arrange for our Scrum simulation training the week before this event to get the Developer Team familiar with the ideas.

As often happens, the first day was fairly frustrating for the Team. Many hours were consumed trying one approach and then another. As coaches, we had to walk that fine line explaining the process while allowing them to grapple with their situation and emerge a solution that workef for them. By the end of the day, they had a long list of stories and tasks and some method for organizing them. But it seemed they were a bit dispirited and dissatisfied with the result. The Product Owner felt frustrated that the team seemed to be churning.

We let them go home and think about it.

The next morning, the lead Net Objectives coach, Alan Chedalawada, met separately with the Product Owner to talk about a new tack to take. The Product Owner asked the team, “Would you like to hear how we got here? Why we are doing this project? What the customers are telling us?” For the next 20 minutes, he spoke passionately about his discussions with actual customers, his vision, and then crisply stated the four core points that defined the business value for the product. He concluded by saying, “Now, look. I am happy to tell you the business side and the outcomes I need to see. You all are responsible for the technical side and I respect that. But here’s how you need to make the technical decision: does your technical decision support one of these four points? Will the actual customer see the value of it?”

We call what he shared “The One Big Thing” and it became an epiphany moment for the team.

The developers walked to the board with the mass of stickies – stories and tasks – and started moving things around. “Look. We only have to deliver the concepts for these items. That will free us to focus on the functionality for these two items that seem to cover most of the questions we have. And we will be able to show users a fair amount.”

By the end of the day, the Developers and the Business had organized enough detail to load up their work for four weeks, sure that they could deliver something in line with the four points.

We held our first "Daily Scrum" (a 15 minute standup meeting for the Team) and off they went to work.

They couldn’t believe it. In two days, they had made more progress than they had in the previous two months of standard (waterfall) requirements gathering. It was a powerful experience, made possible by an engaged Product Owner.

In his excellent book, Managing Transitions: Making the Most of Change, William Bridges says it is important to cover four bases to help a team create a good beginning:

• The basic purpose behind the outcome you seek
• A picture of how the outcome will look and feel
• A step-by-step plan for phasing in the outcome
• A part that each person can play in both the plan and the outcome.

When a new Agile team is beginning, the Product Owner is mostly responsible for the first two: describing the purpose and drawing a picture for the outcomes he expects from the product (outcomes and behaviors, not technologies). He uses language and ideas the Team can understand and must reinforcing the message politely and repeatedly over the weeks and months to make sure the Team gets it.

The ability to do this can only arise from the Product Owner's deep understanding of the Voice of the Customer and of the needs of the Business. And this is why I think the Product Owner I observed was so exemplary. He set the stage for a great beginning based on his deep knowledge and his committed presence. And the powerful results that come from this.

(Note: I see the latter two - plan and part - lie more with the Technical Owner and the ScrumMaster, assisted by the Coach).

The Product Owner role is important and tough... which is one reason I recommend our Product Owner training program. It is also why we've been writing a fair amount about it and thinking about what makes for a good Product Owner.

I'd appreciate knowing what you think.

Technorati Tags: Lean-Agile Scrum

tag with del.icio.us