Agile Product Manager in the Enterprise (1): Phases of Disillusionment in Pre-Agile, Waterfall Development.

Note: this is the first post in a series on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a follow on series to the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Owner/Product Manager category as well as in a series published recently in the Agile Journal. (See the resource page for a mapping to the Agile Journal article series).

In this first post, we’ll set the context for need for the transition, and try to shed some light on the Product Manager’s likely perspective on their view of the software development organization prior to the change.

—————————————

Prior to agile, many enterprises have followed a sequential, stage-gated, waterfall development model.  In these cases, it’s likely that the Product Manager’s mindset has moved through a series of increasingly foreboding attitudes, as the figure below shows.

 

Phases of Product Management Disillusionment in Waterfall Development

 

 

 

Phase 1 – Unbridled Enthusiasm

In this phase, the Product Manager spends their time with customers, interviewing, running workshops, and using whatever other tools they have at their disposal to define and document the requirements for the prospective new system.  These requirements are typically captured in a MRD (Marketing Requirements Document (MRD) or PRD (Product Requirements document). After that, the development team typically response with a Software Requirements Specification, or (SDS) System Design Specification, which further refines and documents the intent of the PRD.

At the end of this phase, which may take from 3-6 months to document and gain the requisite approvals, the development effort is launched and there is a hand off to engineering.

Phase 2 – False Sense of Security

This initial, upbeat phase is followed by a period of relative calm. I call this the period of a false sense of security. During this phase, development proceeds apace. The product manager may be uninvolved, or may attend milestone reviews where models, documents  and project plans are reviewed and inspected. Towards the end of this period, which lasts typically from 6-12 months, the software is declared to be 90% complete and launch plans are put into place. Customers are notified that the release is impending and external and internal commitments are solidified.

Phase 3 – Rude Awakening

Of course as we’ve discussed in the book and blog, the next phase is a painful one indeed. During system integration, many defects are discovered, some design related (think – uh oh, lots of rework…) , and the dreaded defect triage process begins.

 Now it is obvious that the schedule will not be met and communication of that prospect begins. Worse, in the early period, the defect “find rate” exceeds the “fix rate” and the schedule becomes less and less certain and product delivery looks further and further out. Even worse, the customer typically now has their first opportunity to see the actual software and they discover that it is not what they currently need. This is because either a) they didn’t know what they wanted back then, or b) their needs have changed in the last year. No matter the cause, substantive, additional rework will be required before it can be deployed.

 This a period of substantial pain for the Product Manager and for all key stakeholders in the process.

Phase 4 – Resetting Expectations

Fortunately, we didn’t get this far in the tech industry without most program teams eventually figuring out how to deliver software, so a period of rework and recovery begins. During this period, the scope is typically slashed dramatically, and commitments for schedule and functionality are renegotiated.  Of course, credibility has now been lost throughout the enterprise – the development team to its stakeholders – as well as the product managers to their external stakeholders.

Phase 5 – Persistent Mistrust

What follows is a long, persistent period of mistrust between the development and product management organizations, which is often characterized by cross-department hostility, reduced communication and even complete dysfunction.

Worse, as the Product Mangers have learned that they only get about half what they ask for, they often resolve to ask for twice as much next time, to assure that they get something meaningful delivered. And we all know how well that works out. So the vicious cycle continues.  

I describe all this, not to further  belabor the pain, but simply to point out this may well be the environment when the agile transformation is initiated. 

Clearly, this waterfall development model has not served the needs of the Product mangers or other stakeholders particularly well, so at some point, the lucky enterprise commits to a new, agile development paradigm. Often times, the development teams themselves sponsors the agile initiative and delivers a couple of messages to the Product Management organization:

•  Message 1 “ We are heading down a new path, and this type of thing won’t happen again”
• Message 2 – “but in order for us to be successful, you’ll need to change many of your behaviors, too”.
•  And finally, message 3- “with our new agile model, we are going to stop predicting what will be delivered and when and we don’t really need those Marketing Requirements Documents any more, and we also won’t be creating those software design specs either.”

And now finally, for those developers and managers leading an agile transformation, and in the context of the Phase of Persistent Mistrust, I ask you to perform the following thought experiment.

If you were a Product Manager operating in this environment, how would you react to such a message?

Clearly, we are going to have to approach this change with a more mature thought process and a credible strategy to get these key stakeholders on board with our new model.

Summary

Well, that’s a statement of the problem and that is it for this post. In the next post, I’ll move on to describing a more helpful and enlightened approached to the transition, and to the changing role of the Product Manager in the increasingly agile enterprise. But in this post, I wanted to set the context so we will at least recognize the hole we have likely dug for ourselves in the meantime.