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, Ari 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)
On Product Management 
Interesting post. It seems the issue is well know as described above, and depending on the size of your organization you may need more or less roles to make it work. At our shop we run agile development across 3 products. Each product has what we call an ‘associate product manager’ or junior product manager. They are responsible the operational execution of the sprint, acceptance testing, writing and maintaining story details. Product managers (we currently have 2 for the 3 products) are focused on driving future direction of the product, working to help understand client needs, act as an escalation point etc. Being a startup they have to have the ability however to flex up and down very quickly from tactical to strategic, which isn’t always easy.
We have also undergone some recent adjustments in how scrums are executed moving it more to being a engineering owned process. Associate product managers still attend and listen with the intent to monitor progress, work to remove roadblocks etc, however what we found was no matter how much we tried, the developers always felt like they were reporting to the product representative instead of to each other which is the true intent – hence the subtle shift.
Kevin
Thanks for the comment and I agree with your two points.
1. Someone, Associate PM, Technical PM, Product Designer, Requirements Architect, etc. needs to work with the dev teams during the development cycle to keep things on track.
2. Scrums should be executed as an engineering owned process. This was a key point of my original post. Agile/Scrum is a development methodology and should be viewed as that. It should not spill over and force significant org or process changes to other teams such as Product Managment. Those outside of Development, should only have to be exposed to the interface of that methodology, thus the need for roles as defined in point #1.
As a PM I really don’t care how Engineering structures the development process. My focus is to know that what I need to get out of the development cycle matches the requirements that formed the key input.
i.e. I need a factory that creates software of high quality that meets requirements and is delivered on time. I’ll work with the factory managers to help certain problems along the way, but I really can’t become a factory manager.
Saeed
I hear a lot about agile. I have been a development manager for 17 years and always run a combination between RAD and JAD. What is the majore difference between them and agile?
Mark,
I’m not really the best person to answer your question, as I’m not specifically familiar with RAD and JAD. But here are 4 links from Wikipedia, that should help you (and others) understand the differences a bit more. If someone reading this can help answer Mark’s question that would be great.
JAD: http://en.wikipedia.org/wiki/JAD
RAD: http://en.wikipedia.org/wiki/Rapid_application_development
Scrum: http://en.wikipedia.org/wiki/Scrum_%28development%29
Agile: http://en.wikipedia.org/wiki/Agile_software_development
Saeed
Pingback: Agile/Scrum Software Development and Product Management « On Product Management
Good discussion. Some additional comments:
There are a few reasons that it is useful to have the product manager(s) in the SOS. In the SOS, teams bring up blocking issues and give a high level view into how things are going. It is good for the PM to have a feel for the progress so that they can get a feel for what to expect (both this iteration and future ones). They can also influence that progress (perhaps a requirement isn’t worth the effort going into it and can be lowered in priority / dropped). Finally, the blocking issue could be that the team needs guidance from the PM.
In our environment, it was completely up to the PM on whether to attend. Most attended the SOS at least semi-regularly because they found it valuable. If someone doesn’t in their environment, it might be the way that the SOS is being run.
On inputs to the development process… So you could continue to create your requirements as you always have. And then convert them (or have someone else convert them) to the format needed for consumption by the team. But the question you have to ask yourself is whether that’s the most efficient way to approach it… There’s a cost to the translation. First, it’s work that wouldn’t have to be done if you approached the initial requirements differently. Secondly, information always gets lost in translation. If you can eliminate the need to translate, you’ll get better communication.
My point re: developers deciding on functionality may have been missed. I agree that this could occur regardless of the Development methodology being used. However, as we start to adopt Agile methods, it looks like my Development team is taking some of the Agile tenets too literally – assuming that self directed teams and teams that can make decisions on their own without management approval to mean that they can decide on the functionality.
In our organization we have Business Analysts who are part of the Development Team. Their role has been to take the PRD level requirements that are created by Product Management to create Functional Requirements. Can this role act as the Product Owner or are they too close to Development? I agree that as the Product Manager I can’t afford the time to be the Product Owner as well, but need to be informed and involved in some of the decisions. Can a Product Owner that is part of the Product Management Team (i.e. “an associate PM”) co-exist with a BA on the Development side? Where does one role start and the other end when it comes time to writing the User Stories?
Saeed:
So it sounds like you feel Product Management is mostly detached from development (you say Scrum should be “engineering owned”). But my company is just now implementing Scrum and I am the “Product Manager”, and I’m hearing the phrase “One throat to choke” and that I am expected to soon be running the Scrum reviews (every two weeks). If that’s the case, am I really the Product Owner, not the Product Manager? Or can the same person do both in your opinion?
why wouldn’t you have your product manager as your product owner? that’s the stupidest thing (sorry, it is) that i’ve ever heard. Your product manager is the perfect person (that is if they have the damn enthusiasm, knowledge, and willingness to get their hands dirty).
Furthermore, to Stacy, product managers shouldn’t be gatekeepers between stakeholders, users, and the market to the developers. People developing your software should be given ready access to the users who they’re writing the product for. Product managers should manage the features and know who the right stakeholders or user proxies are to bring to the developers.
Manage the product! The title is self explanatory.
Sounds like your product manager is ‘protecting those relationships’.
Let me guess… your stakeholders are “Too busy” to participate in development.
Maybe you should reconsider making an application that people are too busy to help spec out!
Pingback: Agile/Scrum and Product Management (part 3) « On Product Management
Jeff,
It’s taken me a while to get to your comment above, The development process should be engineering owned. What gets developed should not be.
Product Management is responsible for defining what is built. This not only includes features, but interfaces (GUI, APIs, command line etc.), performance levels etc.
Engineering is responsible for how the “what” is implemented. Engineering needs to have a clear understanding of end expectations, but once that is clear, then the responsibility for implementation is clear.
The issue comes down to how much ongoing information is needed by the development team to do what is needed to sufficiently meet the requirements and expectations set by Product Management.
In an Agile model, the assumption from development is that the Product Owner essentially provides “just in time” information so they can get the job done. While this is great for the dev team — give me what I need when I say I need it — the reality is that Product Management cannot and should not be put into this position.
It will end up in failure for all parties, because the PM will be embedded in the development team and not have time to do all the other things that need to be done to keep the development pipeline primed to continue working.
Don’t let this happen to you. Point your managers to the articles I’ve written and that others have written. Check out part 3 of this series, as I reference others who make the case that the PM and the PO are two different roles.
Let me know how things work out.
Saeed
Pingback: Agile/Scrum - Reality Check « On Product Management
Pingback: The Cranky Product Manager never fails to disappoint, plus a blog you should read | The Cranky Product Manager