Month: September 2008
I am writing a series on Win/Loss Analysis, and would be interested to get your input. Please send me a note if you:
- believe you have some best practices to share about Win/Loss analysis. I am looking for real-life stories of how Win/Loss changed your business, turned an account around, helped your team focus, or helped your career.
- have a horror story about Win/Loss. Sales getting misinformation? A customer going postal? Using a single data point to summarize a market?
I can keep your identity private if you wish, and I’ll make it easy for you to contribute.
Thanks – I hope to hear from you.
I’ve written a number of posts of late (1, 2, 3, 3a) on the topic of Agile/Scrum and Product Management. My goal was to discuss some of the issues I saw with Scrum in relation to software product management.
Given our blog stats, this is one of the hottest, if not THE hottest topic for software product managers today. Within the PM and (I’m assuming) development communities, there are a lot of questions and there is a lot of confusion on this topic. I’ll take a break from my multi-part series on Agile/Scrum and Product Management to bring a little clarity to this topic. If you don’t agree with me or have some comments, please post a comment or question below. It is only with discussion that clarity will be gained.
Agile is a software development philosophy
I made this point in my original article on this topic and it is a very important one to remember. There is so much hype around being “agile” these days: agile development, agile product management, agile companies etc. Who wouldn’t want to be “agile”? But, the second line of the Agile Manifesto clearly states:
Working software over comprehensive documentation
Emphasis on the word software is mine. So don’t get lost or caught up in the rest of it, at least in this discussion. There is nothing wrong with being “agile”, but don’t confuse the specific meaning of the word for the purposes of developing software, and the general meaning of the term “agile” that seems to get applied to everything from people, to departments and companies.
Scrum is a software development methodology
Based on the philosophy defined in the Agile Manifesto, and the Principles behind the Manifesto, Scrum is one of several, and arguably one of the most commonly used, “agile” software development methodologies. It defines specific roles, such as Scrum Master and Product Owner, and a set of best practices for creating high-performance development teams. By decomposing large development efforts into smaller user stories, implementing them via sprints or iterations, and daily progress tracking and reporting (via burndown charts) it is possible to detect potential project delays earlier than other non-Agile development methods.
Scrum is not a panacea for organizational issues
As a development methodology, Scrum can provide more visibility into potential problems in the development cycle earlier than other methodologies such as a traditional waterfall approach. But, Scrum will not solve any organizational problems you may have. It won’t make bad developers better. It won’t make bad product managers better. It won’t fix dysfunctional relationships between Product Management and Engineering. As a general rule, organizational problems cannot be addressed by process changes, and bad relationship between those two groups may actually get worse with Scrum because of the expectation of Engineering of that daily interaction with “the customer” or “the voice of the customer”.
As I’ve written previously, this principle of Agile — that business people and developers must work together daily throughout the project — is a cause for concern. I’ve seen development teams within the same company not talk to each other daily, let alone business people and developers. Personally, I find this requirement of daily interaction an over adjustment to the large lack of business/technical engagement that has generally plagued many software development projects. Regular, clear and meaningful communication across teams is needed, but daily communication isn’t always needed nor possible.
Scrum can increase developer productivity, but at a price
Every system requires tradeoffs. A lot of Scrum teams focus on velocity which is a Scrum term for the amount of product backlog functionality that a Scrum team can take on in a single sprint or iteration. But, given that analysis of the work needed takes place at the beginning of each sprint (in a sprint planning meeting), it can be difficult to plan out well in advance how how much progress on the backlog of features can be made in a fixed period of time.
Now why is that important? For a Product Manager in an ISV, sprints and iterations are simply a means to an end. The end being a release with a pre-defined and agreed upon set of functionality that will need to be marketed and sold, and much of which is likely tied to customer commitments related to opportunities or sales commitments. In short, the price for speed and agility via Scrum is a loss of certainty about the state of the software at a given time in the future.
This can lead to frustrating discussions between Product Management and some Scrum teams who adhere rigidly to the Scrum development model, and don’t understand the need of the business to be able to confidently communicate a planned future state of the product to customers, partners or other internal or external parties. Those parties need this information well in advance of the release, so they can make decisions related to their own objectives and goals.
Agile/Scrum should be viewed as an Ethos
Tom Grant at Forrester Research asked if people viewed Agile as a Creed or an Ethos. He defined the two as follows:
- Agile as a creed. One type of Agile enthusiast treats the methodology of choice as a set of firm guidelines, to be followed or ignored (at your peril). The closer you get to orthodoxy, as the Pharisees communicate by voice or in print, the better the results.
- Agile as an ethos. The other species of Agile enthusiast sees the methodology as a guide to action. Perfect adherence to its principles are impossible in an imperfect world, so the goal is to add a healthy dose of Agile to the blend of different techniques and imperatives.
First, let me make a point of clarification. I’m not sure if Tom meant it this way, but the way I interpret this, is that when he says “Agile”, it’s really referring to Scrum or any other specific Agile methodology. i.e. Agile is a software development philosophy, whereas the methodologies, like Scrum are defined based on the Agile philosophy.
So, for me, Scrum has to be ethos. And here’s why? No single development methodology can be applicable to every situation or every team. Scrum defines a number of best practices, but is not in itself dogmatic about exactly how everything must be done. This is a good thing. It provides people (IMHO) flexibility to implement what works best for them given time, people, needs and constraints.
If it were rigid, it could hardly be called “agile” could it?
Hopefully this helps provide some clarity into my views on this topic and a little more fodder for discussion. So comments please.
Look forward to pt. 4, because so far pt. 3 has done little to bring clarity to the issue. For example, in pt. 1 your Scrum definition calls the Product Owner the “voice of the customer,” but that’s exactly what the Cranky PM says the Product Manager should be. So which is it? To those of us trying to, hoping to, move to a more agile process, this type of contradictory advice is paralyzing.
One suggestion I saw that seemed to make sense is having an assoc. PM take on the product owner role. I like that, but it implies that the product owner comes from the product (business) team, not the engineering/tech team. Jennifer Fawcett, on the other hand, recommends the product owner come from engineering. Again, contradictory advice.
I know that each organization is different, and that there are no set rules, but after spending the last hour reading through your posts and replies, I’m more confused than I was before, and still not convinced that the product manager/owner aren’t one in the same.
Point taken. That’s what happens when you write a multi-part series with large lapses of time between each part. You forget that what you wrote in previous parts may not be as clear as you thought when you wrote them.
So before getting to part 4 (it’s coming soon, I promise), I want to address the comment above and make sure others are not seeing a similarly confusing message as they read the various parts one after another.
One point of confusion in the article above is the definition used for Product Owner in part 1.
The definition I gave:
The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.
is not my definition but the standard Scrum definition, and goes to the heart of the confusion of whether a Product Manager can/should also be the Product Owner. In this case, the definition came from the Scrum(development) page on Wikipedia. The same Wikipedia page has (at least at the time I’m writing this) another definition of Product Owner that reads:
- Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders
This is a little more generic definition than the first, as it does not explicitly reference “customer”.
If I could make changes, I’d do two things:
- Change the name from Product Owner to Iteration Manager, Requirements Manager, Requirements Analyst (or something similar)
- Define the role as: “The person responsible for ensuring that iterations focus on delivering on the priorities and objectives as defined by the customer or customer advocate. The Product Owner is responsible for Scrum related artifacts such as User Stories, Epics and prioritizing the Product Backlog during each release cycle.“
This does two things. By changing the name of the role, it removes any ambiguity about the scope of the role and the focus of the person in it. It also clarifies the relationship between this role and that of the “voice of the customer”, or as I call it the “customer advocate”. (i.e. the customer, the Product Manager or other similar entity).
(click to enlarge)
As you can see from the diagram, the scope is VERY narrow and the focus is on inbound development planning activities. In their article, they also state:
The Product Owner addresses Agile development teams’ intense need for real-time input on user stories, user interface design, and requirements when Agile Product Managers are inevitably away from their desks.
Enthiosys, like other people I referenced in part 3, state that the two roles should be filled by different individuals. The Product Manager is the voice of the customer (I agree with Cranky here), and in a prelude to part 4, I’ll say that I agree with Jennifer Fawcett that the Product Owner should be from Engineering.
Hope that helps clarify any confusion my previous posts may have caused.
Coming soon — part 4 — where the “Product Owner” should sit, and whether there is such as thing as an “Agile Product Manager”.
Continuing from part 2 of this series, I want to respond to one of the comments that was posted by a reader.
James Peckham commented:
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).
Yeah, so why wouldn’t you have your product manager as your product owner? Well, I could explain it in a lot of boring detail, but I’ll let others do it for me. I’m glad to see others on the web see this problem in the same way I do.
The difference between the two roles is very clear. From focus (strategic vs. tactical) all the way down to scope (release vs. iteration), the two roles are very different. There is no denying that external input is needed for the development team to be successful. The real question is who should provide that and at what level they need to provide it.
The CrankyPM, in her own unique way, also sums it up well:
You argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking. Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day.
Uh, no way. Not gonna happen.
Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market. How is she to do that without actually VISITING some customers and prospects? And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away. She cannot answer questions from the dev team within 5 minutes if she’s on a plane, or in a meeting, or on the phone with a customer.
There are reasons and roles within a successful team that allow this to work (even if it’s not completely agile). I advocate that are two product-related roles within an agile enterprise:
- The Enterprise Product Manager, who typically reports into marketing, and who owns the RELEASE
- The Agile Product Owner, who typically reports into engineering, and who owns the ITERATION
So, I hope this puts the question of Product Manager = Product Owner? to bed. There are clearly two roles, with difference responsibilities, and levels of focus. They need to work together during the development cycle to ensure that product development proceeds efficiently and correctly.
In part 4, I’ll talk about where the role of Product Owner should sit, and whether there is such a thing as an “Agile Product Manager”.
This is personal.
When you think back over your life, how many product ideas have slipped through your fingers? For me the number isn’t huge, but it’s not small either. Any one of those ideas could have been a huge success. In 2003, I remember starting a business plan about a product that would suggest new music to me based on things that I like, and better yet, things that others like me, like. Earlier this week, Apple introduced Genius, which is really a Genius, but it’s very similar to the idea I was toying with 5 years ago. My idea was focused on independent bands, and of course I would have struggled to get critical mass, which Apple has out of the gate.
And that’s just one of them. There are probably between 5 and 10 other really good ones.
I’m not bitter exactly. I know why I didn’t go for it. I was offered a great job, for which I moved to California, and I’m glad I did. The experience was awesome, and there was some great upside when Wily was acquired in 2006. I wouldn’t trade the experience living in the bay area.
And neither can I be certain that any of my ideas – especially my execution of the ideas – would have been successful.
But. But. But. I didn’t go for it. At the end of my life, am I going to look back and be glad I was safe? I know, I’ll be thinking about my kids, and their kids, and so on, but I’ll also be thinking about my career. And I think I’ll be disappointed if I hadn’t gone for it … at least once. Maybe more than once.
So right now I am stepping out. We’ll soon be launching some new consulting offerings from Eigen Partners. And we hope to develop products too. It won’t be easy, and it’ll be scary, and all that … but at least we’re going for it.
What about you? What’s holding you back? Share some of the product ideas you’ve had that could have been somthing, if you had gone for it. OR, better yet, if you went for it, how’s it going? Or how did it go?