While there might not be a single correct formula for fitting product management into an Agile setting, there's one inescapable rule: Prepare to have your PM skills put to the test.
Recently, I was speaking with Barry Paquet of Quantum Whisper, a small firm that has a tool designed to help PMs with these Agile-related challenges. To the right, you'll see one of the slides from Barry's presentation. The message is pretty self-evident: if your company is going to take the "voice of the customer" part of Agile seriously, PM must keep a lot of plates spinning. Feedback loops in Agile development don't run themselves—someone has to be on top of the collection, analysis, validation, communication, and review. With Agile, these activities are happening nearly constantly.
While any PM who has a passion for building good products should welcome this change, it also can be a little scary. In my own research and advisory work on Agile adoption in tech industry companies, I've heard some PMs express no small anxiety about this new model. In part, they're worried that the company might not support or even understand this process fully. However, they also experience some dark nights of the soul about whether the have the skills and experiences needed to play that sort of role. Here are a few common concerns:
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.
A couple of days ago, Texas Stadium was reduced to a pile of rubble. Wow. The former home of my Dallas Cowboys, the site of victories and record-setting performances — gone in a matter of minutes. Was I sad? Yeah. But also a bit relieved. The Cowboys have moved to their new, super-duper (and quite ostentatious) stadium, Texas Stadium memorabilia has been auctioned off, and the poor, neglected building had become quite an eyesore.
Sometimes destroying something unusable is the best way to move forward.
Run that statement past your approach to documenting software requirements. When was the last time you took a step back to evaluate how your organization represents requirements? If it’s been awhile and your business analysts are still delivering massive, text-heavy, all-encompassing business requirements documents (BRDs), it’s time for some demolition of your own.
Why? Compelling forces have converged, drastically changing the way application development teams author software requirements. Organizations are recognizing the connection between software failure and poor requirements, and authoring better requirements has become a major initiative in many firms. At the same time, Lean and Agile are front and center, so right-sizing requirements documentation is on everyone’s radar. Bottom line, you need to do more with less: author stronger requirements while minimizing waste and being as lean as possible.
One of the great things about researching Agile is, given the scope of both its applicability and effects, you'll never run out of interesting topics. Agile product management, Agile used outside development, contract details in Agile projects, Agile channel management, the effect of Agile on requirements—researchers like myself and Dave West, writing about Agile directly, will have plenty to do for years to come. So, too, will others, like Mary Gerush, exploring the effects of Agile on requirements and other aspects of development.
As Agile goes mainstream, video game developers like Bioware have taken the Agile plunge. This corner of the technology market is very interesting because of the high level of challenge. In some cases, video game developers face extreme versions of common problems, such as an unforgiving standard of product quality. (Ship a crappy product, and your dreams of making obscene wealth will be replaced with the nightmare of watching your game vanish from retail channels.) Other challenges are unique to the video game industry, such as managing all the creative talent—artists, musicians, and actors—critical to product success. (But heck, if you get to meet John Cleese, Claudia Black, or Gary Oldman, the work can't be all bad.)