I was working with a customer this week doing a process diagnostic. One of the things they happened to mention is that they miss waterfall. I was surprised as these days all I hear is how everyone wants to be more agile.

I asked for more, and the anecdote provided was that they cannot get commitment to specific Features being delivered as part of a release as they could in the past. Their requirements process had migrated from Features to User Stories where if they asked for a Feature the first response was give us the stories and then when asked when they can get the features they were told “when it’s done”!

Now of course, for any company where success is meeting market needs, this is not desired. So after that phase of the diagnostic was complete, I mentioned we could help them create an environment where Features and Stories can coexist and a release commitment could be created. I do not see this as breaking agile simply making it work in an environment where the Product Owner needs to meet the team’s needs but also the needs of a commercial company where commitment to stories is not enough. Do you agree?

What are the RIGHT requirements? It used to be you planned a release and listed the must-haves and got them… Eventually

But with agile we get the product backlog faster… Yeah? i.e are those the Right requirements?

Who owns the definition of the right requirements?

Of course, the words “right” and “own” are ambiguous and even within a specific company culture where they might have a specific meaning; they are oft clouded by perception, interpersonal dynamics, political clout, etc. Any stakeholder will likely have a different definition on the right requirements.

One thing agile does well is to formalize a role called the Product Owner, someone who represents the customer to the sprint (iteration) team. The Product Owner participates in the Sprint Planning session and answers clarification questions about the stories and other items in the Product Backlog.

Assuming the Product Owner is singular then there is at least one person to blame when the requirements are not “Right”, i.e. if the product fails, you should start asking the product owner what went wrong.

In my consulting work, I’ve noticed a interesting trend in multi-product manager organizations that embrace agile. They designate a “Lead PM” as the Product Owner, and to rotate that the Lead PM designation at regular intervals. That allows the reality of having the Product Owner (one person) participate in the daily stand-up and other sprint meetings (It does not scale well to have many product managers attending those meetings.) Instead they spread the hot seat and responsibility when you have a large organization to make the agile Product Owner concept work.

Now how does the Product Owner pick the right requirements?

More on that next week…