There have been a number of good comments on my original post on this subject and I thought, given that the Agile 2008 conference is happening here in Toronto this week, some additional focus was appropo.
Bhuwan, Ivan, Consultiq and Stacy all agreed with my position that the Product Manager shouldn’t be the Product Owner (Scrum role) if the meant that the Product Manager had to attend daily stand-up meetings with Development. This would force the Product Manager to be a daily tactical decision maker and would make it even more difficult to get out of the office, meet with customers, partners and prospects and do the fundamental research that is needed to ensure that the future success of the product is addressed.
Stacy wrote:
Many companies have assumed that Product Owner is equal to Product Manager. That’s a recipe for disaster — Product Managers can’t be in the daily stand-up, or the team will reach a point where they don’t know what to do next. … Product Management has to be that bridge between the market and development…and we can’t do that if we’re in the building, involved in the daily workings of Development.
I personally don’t like the name “Product Owner” for the role as it is defined in Scrum. At one company I worked at, we called it “Project Owner”, explicitly to remove the assumption that the Product Owner and Product Manager were one and the same.
In fact, on any sizable product release, there will be multiple scrum teams working on different aspects of the product, and thus in the Scrum terminology, there would be multiple “product owners” which doesn’t make sense. Now, the term “Project Owner” is not perfect either as there can then be confusion between the Project Owner and the Project Manager, but I think there is less potential confusion there than using the term “Product Owner”.
Steve wrote the following:
So, where does it say that if you move to an Agile/Scrum methodology that Development can make decisions on functionality without first consulting with the Product Manager/Product Owner?
Nowhere as far as I know. But this is not a problem with Scrum or Agile, but it exists in companies regardless of which Development methodology they use. Read my response below WRT Walter’s comment on how to address this issue IF the PM is not explicitly the “Product Owner”.
Walter left a thoughtful comment covering a number of topics. He suggested that the PM attend a Scrum of Scrums meeting to get away from the daily standup, but to still be involved. I have not worked in a company where they implemented a formal Scrum of Scrums type meeting so I can’t speak from experience, but I’m somewhat skeptical of the benefit, simply because the focus of Scrum of Scrums will be inter-team issues and not necessarily product/functionality issues that requires a PM’s attention. As stated in the Scrum of Scrums link above:
These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
Walter also suggests using a person with a role something like “Requirements Architect” who can attend the daily scrum instead of the PM. I agree with this. In fact, I wrote in the original post:
Other roles such as Product Designer need to be defined to take that day to day decision making role and act as the Product Owner, or at minimum, be the proxy for the Product Owner (if that is the PM) so that the PM doesn’t get bogged down by daily scrum meetings.
They key here is level of focus and ability to execute. It is very difficult for any one person to work at a very detailed tactical level — which is where the Product Owner needs to be — and still think, act and plan for the future at a strategic level which is where the Product Manager should focus. Having a Product Designer or a Requirements Architecture fulfill that tactical role but also know how and when to escalate decisions up to the Product Manager minimizes the impact on Development, but also allows for a scalable model that works for both PM and Development.
Walter continues:
Probably more important (and more time consuming) than the daily scrum is your participation in iteration planning, demos and retrospectives.
There will be other affects on the product manager when switching from waterfall to agile. You’ll want to approach your requirements differently. Instead of a list of things the software should / shouldn’t do, you should break it down into stories where each can be implemented independently, will add customer value and the team will be able to accomplish within an iteration.
Instead of saying “must”, “should”, or “frill”, you should rank them and update that ranking every iteration based on what was learned. Agile is all about attacking the most important things and changing based on what you’ve learned.
This is where the Product Designer or Requirements Architect can also play a significant role, by working with the Product Manager to take the requirements that have been collected and defined for the release, and translate them into effective and accurate user stories that can be readily consumed during sprints. Priorities can also be defined for the stories, so that as implementation proceeds, decisions can be made quickly to drop or reprioritize specific stories if lack of time/resources force the case.
By working with the PM in this way, the Product Designer (or equivalent role) gains a clear understanding of the requirements, their context and importance and can then work efficiently with the Development team to see them through implementation.
The Product Manager can (and should) regularly communicate with the Product Designer and Development Management, at minimum, at key milestones such as feature/functionality reviews, retrospectives etc. to ensure the development work continues to stay aligned with the original intent of the requirements. This also frees the PM to work with other teams such as Product Marketing, Marketing, Sales, Finance, as well as customers, partners and prospects and focus on overall product success.
In the end, the key is to ensure there is clear understanding of who has what authority and responsibilities, and people communicate effectively with one another to define, build and release the best product possible. No one role can succeed without the others, and in the end, all teams must either succeed together or fail together.
Saeed
Agile/Scrum Software Development and Product Management (part 1)