Posted by Tom Grant on April 16, 2010
Agile adoption requires a change in values, not just a change in process. That's the message of the Agile Manifesto, and everything we've learned in the year since the Manifesto's publication has only expanded and emphasized it. We might not have all the specifics on how that relationship works (for example, does an "Agile culture" automatically dictate Agile practices?), but the correlation is definitely there.
In technology companies, these values are critically important, since technology does not just improve the business, it is the business. Agile changes how teams develop and deliver technology. In a technology company, delivery includes practically everyone outside the development team—marketing, sales, support, consulting, partners, you name it. Beyond the janitorial staff, it's hard to think of someone who won't be effected when a tech company goes Agile.
Consequently, product managers and product marketers, sitting on the border between the development team and everyone else, are simultaneously the agents and targets of Agile transformation. For example, when monolithic releases crumble into many smaller iterations, people throughout the rest of the company have obvious questions, such as, When can I tell a customer to expect the enhancement they've wanted for the last two years? When is the next time we're going to have to do sales training? When will we have delivered enough new value to merit a product launch? PMs facing this situation will have to make adjustments to their own work, such as building and communicating the product roadmap.
At the same time, they'll also bear some responsibility for explaining the value of the changes that Agile has wrought. (A typical statement: "I know that, as salespeople, big releases made it easy to stay on top of the state of the product. But which would you rather have, smaller releases with more predictable release schedules, or humongous releases with ship dates that no one believes?") PMs will also have to take the initiative on many fronts where Agile isn't working very well at a company level. (Another typical statement: "There's no point in making all the same design mistakes faster. We really need to take this Voice of the Customer thing seriously.")
Here's some hard evidence of what I'm describing. Participants in a recent survey about Agile adoption in the technology industry answered the question, "How has your relationship with the development team changed since Agile adoption?" As shown in the diagram, the short version of their replies was, Better, overall. However, you'll also notice that the improvements are not uniform. (Executive management is pretty happy. Sales, less so.)
Thrust into this situation, PMs need guidance that addresses the changes in both values and process. Advice that deals with one, and not the other, might be worse than useless. Looking at only one half of the Agile equation, PMs might do or say some very counterproductive things. Here are a few examples of how process-exclusive advice can lead PMs astray:
Burning down the house. Your efforts to create a backlog have stalled, because no one is willing to strictly prioritize anything. How do you convince people to adopt more discipline? Here's an argument that's sure to fail: "So that we can build a proper burndown chart." People need to understand the bad business ramifications if they continue to play fast and loose with prioritization. For example, can't really move at an Agile clip if you're constantly arguing over and revising the list of projects. Also, it might be important for PM to point out the reasons why the team can't prioritize, such as constant interrupts from the salespeople claiming that a multi-million dollar deal is in jeopardy without some feature added to the product right nooowwwww!
Failing to recycle. Here's an easy way to dispel any confusion about the actual state of the product: describe how people would use it. User stories are a great medium for communicating what features are in the product, and what they do. In fact, they're a lot better than the typical one-liner that leaves people wondering what an ion flux regulator is, let alone the value of having one. However, it takes work to recycle user stories for other audiences, such as the marketing people designing demos, or the training people building courseware. You can't just hand over a lot of information in an unfamiliar medium and expect people to make sense of it.
Leaning into the punch. Agile and Lean complement each other naturally, correct? While that may be true, injecting Lean into an early discussion about Agile adoption might cause people's heads, or tempers, to explode. In a situation of uncertainty and anxiety, added complexity is definitely not welcome.
Owning the product means the product owns you. Should the product manager be the product owner? The glib answer is, "Why not?" After all, many companies have a half-formed image of the the PM as a mini-CEO, advocate, champion, evangelist, commissar, whatever. These are the sort of fuzzy job descriptions that obscure the panoply of tasks for which PMs are responsible. Make the PM the product owner, and suddenly tasks not directly related to the development process are going to get a lot less attention. Backlash from affected groups will be soon to follow.
Want to give PMs useful advice about Agile? Skip the obvious process-related issues, such as how a daily standup meeting works. Not only is this information already widely available, but it's not terribly helpful. Instead, focus on answering these questions:
- If we're adopting Agile, how will my job change? What's my responsibility for making the Agile experiment successful?
- If I'm joining an already-Agile team, and I'm not used to Agile, what the hell am I getting myself into?
- If we're all used to Agile, how can I help keep our work on track? And how do I make sure that, at a company level, we reap the benefits of Agile?