Feb 23, 2008 5 min read

The Accidental Agilist

Over the last few months, we’ve repeatedly heard about product managers who come back from customer visits or vacations to discover that their engineering teams have “gone agile” without telling them. After which, the PMs scramble to figure out how their roles and deliverables are different under a new development model. They are either shut out of their organizations or abdicating a critical part of the product management mission.

What we see at Enthiosys, nearly every day, is that Agile delivers more and better software; that product managers are an irreplaceable part of that improvement; and the PM function needs to be a champion of business improvements. All of which requires PMs to be intimately involved in the daily activities of their development teams, helping them be more successful.

Where is the Push for Agile Coming From?

Software development works better under Agileand almost everything is software under the covers. Software arrives faster, with higher quality, and with fewer huge strategic gaffes than waterfall models. That translates directly into measurable savings in cost and time, higher predictability, and sometimes improved revenue. The chance to boost development throughput by 30-40% energizes CFOs and CIOs and CEOs, not just VPs of Engineering. This is no longer a “pick your poison” or religious discussion.

These are bold claims, so third party validation is important. Consider VeriSign, where the Managed Security Services team used Agile to largely replace traditional Marketing Requirements with roadmaps and backlogs, shaving an estimated 3 months from their development cycle. Or Israel Gat from BMC Software, who subjected his Agile process to intense public scrutiny, and demonstrated remarkable levels of quality and time-to-market for new releases. Key Bank and Capital One are some of the financial institutions sharing their successes with Agile, and our own work with Emerson Process Technology successfully applied Agile to development of extremely complex embedded systems.

(If your PM team isn’t considering and debating a shift to Agile, it will happen without your input. You could be the spouse who comes home from work, surprised to find that your key no longer opens the door to the house.)

Directors and VPs of product management represent all constituents in this opportunity. They speak for the customer, buffer Engineering from excessive meddling, and own revenue-based product planning. As arbiters of trade-offs and balanced release maps, PMs are often best situated to advocate for changes in development methodology. Promoting better-faster-smarter-cheaper is central to the PM role.

Engineering teams want to do their best, and are filled with smart, well-informed, tightly networked folks. You’re either helping them invent the future or reading about the results.

Is Agile PM Really Different?

From 100,000 feet, all product management, agile or traditional, looks the same. We size markets, understand customers, write requirements, solicit and interpret customer feedback, and work like mad to position products for Sales & Marketing. Just like getting from San Francisco to Boston is the same regardless of how you travel.

Even at 30,000 feet, though, you know the difference between flying and driving. Each may have indifferent food, movies for passengers, and ways to buy more expensive seats – but one gets you to Boston in 5 hours rather than 5 days.

Agile really is different from waterfall. Every day, almost every deliverable. You talk with Engineering differently, and (eventually) think about your products in a new way. Consider:

  • Customer Input. Your waterfall model was to gather input, then write requirements, then hope for good outcomes next year. Under Agile, customer input is actively solicited throughout the development cycle: reviewing wire frames, early features and usability. We’ve found that traditional PMs struggle under their old mental model of striving to “deliver it perfectly” before showing something to customers instead of “collaboratively shaping the final result”.
  • Development Team Collaboration. To take advantage of all of this powerful customer input, Agile PMs meet with their development teams much more frequently than traditional PMs. The result is a much richer calibration of what the actual product needs to be successful in the marketplace.
  • Backlogs. Your backlog is a dynamic, near-real-time set of deliverables for both Engineering and Product Management that you’re constantly reviewing to reflect internal conditions and external opportunities. A key member of the team becomes sick? Change the backlog to reflect capacity. A deal comes along that you want to close but requires just a few more features? Reshuffle the backlog and then ship the software, secure in your knowledge that good Agile teams create “release ready” software every iteration.
  • User stories. Back in the days of pocket protectors, PMs wrote complete (and lengthy) MRD/PRDs intended to tell Engineering precisely what to build. These were immediately out of date, and failed to anticipate the many trade-offs in a year-plus development cycle, so we patched and updated them along with one-off priority decisions.

Most Agile approaches create more documentation – not less – but timed to when the team needs it. Agilists prefer the consistent expression of user stories, which can be flexibly managed and developers easily understand. You may sketch out fifteen user stories and user experience guidelines, but initially complete only the first two stories in detail. The rest go onto your backlog. You will be expanding and editing user stories throughout the release cycle – just ahead of demand, when your customer knowledge is most complete.

  • Fewer unused features. Items further down in your backlog might not get built. That’s a good indicator that they weren’t really needed, versus the “do it all now” PRD model.
  • Credible, fact-based status reports. As your team gains some experience with Agile, they get better at estimation and judging their progress. More importantly, the focus on working software at the end of every iteration makes your traditional approach to assessing progress not only meaningless, but dangerous. You’ll never again ask “Is this feature 80% complete?” and instead learn to work in “whole and complete” deliverables. Engineering will love seeing how this boosts credibility with Sales and Marketing.

Your initial PM reaction may be “can I continue to do PM the way I’ve always done it, even though my engineering team is trying to be agile?” You’re driving, not flying, though until you rephrase this as “how do I harness Engineering’s added power?”

You Will Need More Help

As I noted in September’s Byte, there’s a lot more work for an Agile PM to do. Our most successful clients are forming product teams of (for instance) product managers, program managers plus business analyst/requirements experts. Teams provide the extra attention and bandwidth – the Agile PM magic – that Engineering needs to deliver measurable productivity improvements.

Directors and VPs of product management need to address this head-on. Part of the cost of Agile is more PM talent. Practice saying this in front of your mirror: “Nothing is free. In order to get the best out of Engineering, we’ll need a few more PM resources, plus Agile training for the entire Engineering-Product team.” Shifting a little of Engineering’s savings into PM is more than reasonable.

Sound Byte

If Agile hasn’t come to your software team, it will soon. The business benefits are irresistible. Product Management should be pushing for adoption and helping plan the transition, not waiting to be Accidental Agilists.

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Rich Mironov's Product Bytes.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.