Product Managers are not “Pigs”

There is so much material about agile product management it is impossible to get to it all. What I am referring to is the discipline of product management, not software development, although I’m not really sure how you can separate the too. In one day, a phrase search of “agile product management” on Google went from 13,800 to 14,100 hits. I wonder if Google can index as fast as material is produced. The viewpoints and opinions vary from real practitioners to theorists. Pragmatic Marketing (an organization whose ideas I embrace greatly by the way) is totally on the agile product management bandwagon. They have an eBook on the subject. Click on the picture to download. There is even a post that I can’t seem to find anymore that picked apart the agile manifesto and how it is perfect for product management.

I’ll caveat all my comments by saying I do like the concepts discussed around agile product management and the pros do outweigh the cons. In practice it does bring a number of benefits to my product management team. Additionally, there seems to be no distinction between “Agile” and “Scrum” although going back a few years there has been multiple agile methodologies. Remember eXtreme Programming (XP) or maybe further back Rapid Application Development (RAD). Since Scrum is the new black and much of the material is how great agile product management can be I’ll share a few stumbling blocks.

Product Managers are not “Pigs”: The whole pig and chicken thing in scrum is a little odd but the Pigs are the ones committed to the project in the Scrum process - they are the ones with "their bacon on the line." Product Managers should definately be committed but should not fill 100% the Product Owner role. When they do they are spending too much time with development, inward facing, and not enough outward facing and building the channel. Daily standups are onerous. This is the area where I, and apparently quite a bit of the community, believe Scrum is weak. There is no clear role in the Scrum methodology for Product Managers. When you implement Scrum there is a large gravitational force that pulls you closer to development. That is a positive thing and a primary purpose of the methodology but also dangerous. Product managers should have their bacon on the line but it should come in the form of product P&L and revenue and not Sprint success. This area is the #1 issue for a product management team in a Scrum-based environment.

How many Pig pens do you have?: Product Managers rarely enjoy the benefit of managing one product. So now imagine a PM as a Product Owner doing what a Product Owner does for three products. Three daily standups...are you kidding? The challenge is greater if the development teams are all doing things slightly differently. My first experience with Scrum over three years ago was with one particular development manager who was giving it a try. The challenge was that particular product was one of the lowest revenue generators of the entire portfolio. Yet the process was requiring by percentage much more time than the highest revenue producer. This creates a problem for a Product Manager with multiple products and again why Product Managers should be committed but not Pigs.

Development managers need to be mighty: This holds true for any methodology really, but is even more so when implementing Scrum. Without a strong development manager (or Scrum Master) the Product Manager gets pulled too closely into a facilitation role and too close to the Sprint backlog. A strong development manager will take on part of the Product Owner role specifically to derive market requirements (Product backlog) into Sprint backlog line items. A Product Manager should not attempt, nor be asked to attempt, requirements at this level.

Don't try this at home. We're trained professionals: It will be impossible to adequately reap the benefits of agility if you are implementing it solely on text books without experience or consultation. In the end you will either follow the letter of the law so closely it doesn’t work or you will fail to implement properly the key components that actually give you the agility…like properly managing Sprints and their outcomes.

Spurts and Sprints: Scrum is based on the concept of Sprints. The idea is that you do as much work as possible in the backlog during a set period of time. Be wary when the sprint durations change to fit the work to be done (unless there is a good reason, see next point). Due to culture or the collective experience of the “Pigs” there will be a tendency to vary the duration of the Sprint for every time to fit what needs to be accomplished. That is just waterfall and the Sprint is a fancy name for development phase and the Sprint Backlog is just a requirements document. Furthermore, be wary when Sprints are created for testing and bug fixing.

“We didn’t actually complete the last sprint, we just
stopped it since time was up, so we are going to do a short sprint for testing
and bug fixes.”

Easy to see the problems that ensue.

Take all the time you need. We've abandoned time-to-market: A final point to make is be wary the Scrum and Sprint concept isn’t abused as a reason to not make commitments. Two ways this comes about:

1) There are specific features you need implemented for a strategic customer (polite way of saying something was sold we didn’t really have). Your Sprint durations are 4 weeks, you need it in 6 weeks, and the actual time it would take is 5 weeks. If you followed the Scrum/Sprint methodology to the letter you’d get part done in the first four weeks then have to wait for the end of the second four week Sprint to get the rest (you are now two weeks late), and then of course have to wait another Sprint for the testing and bug fixing and suddenly you are not agile despite having an agile methodology and you have a big problem.

2) Second way this comes about is if you plan to launch a certain set of features by a given date. Product launches are strategic after all. Let’s say for example you are launching a consumer software product in time for the holiday season. Your launch date is set, your features are largely set, but organizationally you are implementing Scrum to the letter.

“we are doing Scrum so we make no commitments and we have no
idea if all this stuff can be done when we want it to, we only look one Sprint
at a time and set goals, not commitments, and we reevaluate after each Sprint.
If we didn’t achieve our Sprint goals we will roll them forward into the next one. Of course it is your choice as product manager if you want to do that or not...”

You can see the snowball effect this creates and the problem you have.

So there are a few items to watch out for if you are going Agile and trying Agile Product Management. I wonder how many more items Google indexed in the time it took to write this post.