I was chatting with Jason Tanner of Enthiosys the other day, and he asked me how I defined “Agile Product Management.” What follows is more or less my answer, formatted a bit for the purposes of the blog.
All my discussions of “agile” anything start from how I describe agile at the 30,000 foot level, with the following rules:
Sprinting! (A sprint car at Eastbay Raceway in Florida, by jokerswild1963, CC 2.0 licensed)
Each time through that set of steps is an iteration or sprint, and you’re likely to have a lot of sprints before you get to a release.
I contrast this explicitly with the comparable rules for “waterfall”:
It’s a subtle difference when shown this way, but the difference is critical, and for a number of reasons:
Given this, how do I define agile product management? The steps for agile product management are no different than they are for other agile activities (like agile project management, what we usually mean when we say “agile”). Figure out all the things you want to do, prioritize the list, and do the most important thing on the list, then repeat.
What does that mean in practice? It means don’t spend time on unimportant things. Always know what’s most important (how I determine that is covered in another post), and focus on getting that to “done done” before doing something less important. And then when you’re ready to start again, redo the list, and reprioritize. As a product manager, I make a list of the features needed by the customer or the market, prioritize it, and write detailed requirements for the handful of the most important ones. Those I then socialize with the engineering team, both to get their rough estimates, as well as qualitative feedback on the feasibility of the features, open a conversation on what the feature really is, get ideas and innovations from engineering that might make the feature more valuable, and so on. That’s one iteration – then I do it all again for the next iteration.
Contrast this with a non-agile approach to product management. I’d start with the same list of features for the system, then write all the requirements, in enough detail for engineering to estimate them all. Then, after a lot of discussions, covering all the requirements (let’s hope we don’t miss an important one!) I got the (wrong) estimates from engineering, I’d then lay out the tasks in an optimal way to get all those requirements delivered, balancing a desire to get full functionality with a need to meet certain market milestones. Because I’m predicting the future, the resulting schedule is guaranteed to be wrong, and it will always be wrong in the undesirable direction.
At first glance my definition of agile may seem simplistic, and even missing something – where is all the stuff that people usually think of when they hear “agile”, like Scrum, sprints, retrospectives, velocity, and all that?
My point is that agile is not about specific tools or techniques (although agile methodologies may define or specific tools or techniques) – it’s a mindset about getting the most important stuff done-done as quickly as possible.
But let’s expand it a bit more and talk about where all that “agile stuff” is – or rather, where it arises from given my definition. For example, there’s a claim that agile teams keep getting faster, and they work more collaboratively and generally are superior to teams that aren’t using agile. But what’s really happening is that if you run a project based on my definition of agile – whose primary output is to get the most important things done first – you get lots of additional desirable side effects. You not only have a much better approach to the project management side, but you get to take advantage from a management perspective.
If people are always working on important stuff, then they are going to be more motivated to do a good job – this will improve quality over time. And if we’re getting insight – and corrective action – into how things are going on a very short timeframe, like a two week sprint, then we can apply changes directly when they are needed, and over time we can apply a LOT of changes. Simply doing a retrospective every sprint, rather than every project, gives you a lot more leverage, for three reasons:
If you only do a retrospective at the end of the project, as in waterfall, then you’re going to forget some of the problems you had, you’re not going to be able to fix all the problems you do remember because the change will be too big to do at one shot, and only the next project will benefit, not the one that just finished. All in all, a nearly complete waste.
In fact, you might want to think of my rule #3 as having a sub-step – “3.5. Take advantage of your new experience to improve your process.” That will happen every iteration, and you’ll get better a lot faster.
That’s the primary way you get better as an agile team, although there are a few other well-known practices you can apply that will immediately start to give you benefits, like team programming and other collaboration approaches, making sure that everyone on the team takes responsibility for getting to done-done (meaning that developers sometimes do a lot of testing, and testers contribute a lot to development), and always having a deliverable product.
Does this definition of agile resonate for you? Do you use another formulation that captures the key driving benefit of the agile approach? Do you have additional questions about agile and how all the benefits of agile arise from this simple set of rules? Let me know in the comments.
I’ll post again soon about agile, specifically answering why these rules result in getting better quality products to market faster. That’s another promise from the agile camp, and it’s interesting to think through how it happens. And we’ll touch on how to talk to management about agile. Management has historically liked the waterfall approach, because people it appears to be predictable – although the predictions are always wrong (way wrong). Agile seems suspect to management, on the other hand, because you can only say “we’ll get the most important stuff done first,” but you usually can’t commit to when that will happen.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.
Great post, Nils. Love the contrast in the rules for agile v waterfall. I'm not sure I see much difference between your descriptions for agile vs non-agile product management, though. (Under "Applying these to product management".) In both you describe writing detailed requirements, socializing with engineering and getting rough estimates. I may be missing something in your descriptions – they strike me pretty much the same.
I recently underwent the transformation from waterfall to agile. Both are SDLC processes, not product management processes. What I found was 3 areas of impact. One was on democratization of who wrote the requirements (stories in agile), and an unburdening of how detailed those requirements needed to be upfront.
Second was on how the roadmap was developed and managed. It forced us to consider evolving our roadmaps from a calendar of promised and made up dates to a true directional 12-month plan.
Third, it did cause us to re-think the role of the product manager. I was on the side of having two roles: the agile product owner – part of the agile team, inward facing, focused on execution – and the more traditional product manager role – outside the agile team, outward facing, focused on the roadmap and product strategy.
I like your point about agile not being a set of tools, but a mindset. The challenge for product management is to apply the principles of agile and lean "upstream" to the important work product management should be doing to feed agile execution with business intent. This is where there seems to be an opportunity to apply a more systematic, learning based approach.
Thanks so much for the comment, and I apologize for not seeing it and approving it for months!
The big difference I see between traditional and agile product management is that in agile product management, you only put your attention on the most important things right now – you only write detailed requirements for the most important stories (a handful, if that), and you elaborate and converse on those with engineering. If a story is lower in rank it doesn’t get any attention from me until it rises in importance. So instead of spreading my attention across a whole release’s requirements at the beginning, my attention is always on the most important stuff I could be working on. It also means my work is never stale.
There might be reasons when we try to cover more and more agile methodologies with relevent efforts. Here is one more concept at http://www.miraclegroup.com/blogs that covers the intense debate between lean and agile.