OK. At this point, we've laid out some basic product management definitions, talked about some important product management skills, and highlighted a few key differences between project and product management. Now let's address a popular topic: How does this relate to all this Agile stuff I keep hearing about?
As with most things, the answer depends. It
can relate but doesn't always. A lot depends on whether your organization just has the trappings or ceremonies of Agile or actually has absorbed its spirit. (If you're the former, you're not alone; that describes any organization that practices Scrumfall or Wagile.)
First though, some real talk about Agile -- and I use the capital "A" on purpose. In this context, we're talking about the Agile movement that has spawned numerous companies, consultancies, and a cottage industry of experts to help companies improve their software development efforts. They even have their own conference -- Agile20XX.
To really understand the Agile movement, and businesspeople's corresponding frustration with many Agile practitioners, you have to go back to one basic principle:
- The advent of Agile shifted development risk from the developer to the employer/business.
Prior to Agile, if a piece of technology (code) turned out to be too complex to develop within the agreed-upon timeframe, the developer took it on the chin because they would miss their deadline. It was assumed that developers -- as the technical experts -- knew enough to be able to properly estimate the work involved, so they bore the brunt of blame for dealing with problems that turned out to be more complicated than originally expected. Now to be fair, this old way was unrealistic. If you're doing something truly unique or different, there's going to be a learning curve and/or discovery period during which new information becomes available and allows your technical estimates to end up being far more accurate.
The challenge for many organizations, however, is that the pendulum has now swung too far in the other direction. Under some Agile purists' model, the risk of complexity transfers
entirely from the developer to the employer. Developers have the option to continue to work out complexity in development cycle after development cycle. Ideally, there will be incremental deliveries along the way that show progress toward the end goal, but this methodology argues that the lengthening of time necessary for a developer to educate themselves and solve complex problems should fall on the employer's shoulders. This leads to situations where businesspeople complain that their agile teams "never deliver anything" or "can't commit to dates".
In practical terms, the risk of complexity should be shared between the two sides:
- Developers deserve some protection against having to commit to something they don’t know enough about.
- Past a certain point of learning, however, they should expect to commit to delivery by a specific date.
The bottom line is that there is a common myth promoted by some irresponsible agilists out there that aspiring product managers should be very mindful of:
- MYTH: Accountability needs be to thrown out the window to keep our skilled talent (developers) happy.
This is absolutely not true, but to hear some (not all) agilists tell it, we need to allow our developers the
freedom to be agile - defined as doing what they want when they want without any (or very superficial) commitments or governance. The tradeoff these folks need to accept is that developers need to have the business'
trust in order to get that freedom. Otherwise, the whole enterprise is doomed to failure.
Product managers play a critical role in holding agile teams accountable to business goals and objectives -- which is why this topic is so important. You should know that there are most likely elements in your organization actively working against accountability in the name of "greater agility." You should watch out for those elements and have a strategy to address them.