The other category I planned to start almost two weeks ago was this one—it’s high time that I started writing more systematically about product management. And what better place to start than with the latest craze, agile software development?
As Steve Johnson at the Product Management blog at Pragmatic Marketing is fond of pointing out, Agile (as it’s usually capitalized) isn’t exactly new, having appeared on the horizon back in 2001 with the Agile Manifesto. But it has taken a long time to achieve anything like industry momentum. Why? In my experience, it’s because Agile requires a culture change throughout the whole company, not just in engineering and product management but also support, product marketing, and (most importantly) sales.
So why should the impact on all these other groups make it harder to adopt agile development processes? Well, let’s look at some of the top level statements of the Agile Manifesto:
- Individuals and interactions over processes and tools: If your software development process depends on ongoing communication with the key members, what about organizations like sales who aren’t part of the ongoing conversation?
- Responding to change over following a plan: Often in agile, this translates into much less complete planning artifacts. What happens when sales starts to fill in the blanks in the plans themselves—say, when talking to a customer?
The reality, of course, is that going Agile doesn’t lessen the requirement to communicate frequently with sales and other external stakeholders. If anything, it increases the importance of doing so. If the point of Agile is to deliver frequent software releases that add real value to the customer, then including the customer and the parts of the organization who talk with current and potential customers every day is absolutely critical to success.
In fact, Agile as a philosophy shares a lot with another manifesto of similar vintage, the Cluetrain Manifesto, which states that markets are conversations too. See a theme? There is a definite evolution in both Agile and Cluetrain away from central planning and delivery of work products (internal deliverables or actual products) as fiats, made more palatable with heavy doses of promotion and/or process, and toward ongoing conversation, collaboration, and cooperation with the other stakeholders in the process of creating value.
So at some level these two types of conversations—developers with product managers, marketers with the market—really need to become one. And that has profound implications on organizational structures, marketing plans, and nearly everything else that companies do. Is it any wonder that Agile took so long to take off?
I’ll be writing a little more about Agile from time to time, as I reflect on the lessons I learned from adopting an agile development process at iET Solutions and those that I learn at my new gig, Veracode.