An Agile Planning Session Observed

June 27, 2006 — Posted by Jim Trott

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 [now Implementing Scrum for Your Team] 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 worked 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 [now Business Product Owner Certification by Net Objectives]. 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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Jim Trott

Jim Trott is a senior consultant for Net Objectives. He has used object-oriented and pattern-based analysis techniques throughout his 20 year career in knowledge management and knowledge engineering. He is the co-author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Software Development: Achieving Enterprise Agility, and the Lean-Agile Pocket Guide for Scrum Teams.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban