From Product to Project

This is a cautionary tale. There is no happy ending here. It is a story of woe. It is a story of heartache. It is a story that has been told before, forgotten, and told again. What follows is a story told to me by several people who were part of an organizational transformation. They were part of an organization that had embraced Agile principles, had a Product mindset, and had impassioned leadership. And then came the whimper.

(note: this is also posted to Medium for better readability)

Several years ago, my friends were part of a major new initiative that set out to be different. You see this was a company that had done everything in a very plan-driven waterfall model. It didn’t matter that the majority of projects failed to deliver on time, on budget, on quality, or on scope, the projects were managed and therefore predictable (yes that’s a clear paradox given what I just wrote). They were predictable because senior management felt that they were in control because they approved budgets and timelines (which were often missed), scope was defined up front (but always grew), and they knew what they’d be getting (despite years of experience telling them the opposite). You see the appearance of planned management is all that mattered. And then came this new initiative.

Years before this new initiative, Engineering had dabbled in Agile practices but to limited success. There was not business support for this model of uncertainty. The result was increased tension and blame-game between technology and business teams. This new initiative began differently, rather than IT driving the Agile change, the business team was in the driver’s seat. Some business leaders were paying attention to the years of failed plan-driven assumptions and decided that instead a focus on incremental delivery and evolution would provide more concrete value to the organization. The business leadership created a new Product function and bound the Product team tightly with the IT/Engineering teams. They secured consistent funding for the program to last a year at a time. They partnered with new engineering leadership to instill a new, collaborative, agile way of working and the commitment and morale of all team members skyrocketed. There was a singular view coming from the leadership, joining all of the scrum teams into a concerted whole. They had a vision together, a passion that could not be undone.

As this new initiative took off the teams were able to deliver faster and more frequently than before. They were able to incorporate changes to plan, increased scope, changes in personnel, stresses of delivering expectations while not always knowing what that would be. The leadership team was engrossed in the mission, understood the perils of where they were and the challenges of the path ahead. The leadership team took their vision of what could be and passion of the mission and mixed it with an understanding of the user-base and became a force outsized for the company. The teams outperformed their peers, delivered on massive scope, succeeded despite obstacles, delivered value first, and became a paragon for the organization.

And then came the shift. The program delivered into production and was live for over a year when new management replaced the leaders who developed the product. The new management was the management of old, envisioning predictability through waterfall and budget planning. The walls between business and IT were forged anew. The product mindset evaporated. The value to the end-user was not important, meeting numbers is what mattered the most. Scope became a secondary citizen, billable hours is what mattered. The innovation, performance, and technical debt sprint disappeared in favor of more billable work. The result was increased production defects (and the first-ever Sev 1 production outage) but that was an accepted consequence of increased volume. The appearance of output is what mattered.

The team was split up and distributed to multiple managers. There was no longer a singular vision guiding the organization. The passion of old was quenched. This was the new norm, where people did not matter, where execution against reality did not matter, but perception against plans and budgets was all that mattered. Defects rose, but that was an accepted consequence. Productivity suffered. Morale plunged. Relationships with business and IT dissolved. But the old plan-driven model won. It won yet everyone lost.

Team velocity diminished. Morale collapsed. Productivity disappeared. Quality evaporated. But the appearance of predictability reigned supreme. And this is the end of the tale of a team that departed from Agile, that departed from Product, and instead found themselves in the mire of the orthodoxy.

But finding yourselves in such a situation you need not surrender; you can continue the good fight. Emphasize the value of the investments in technical debt and innovation initiatives. Emphasize the value gleaned from dynamic planning and execution. Show how plans and dynamism can support each other, and the values emphasized in the Dora project can lead us to the motherland. Use facts like deployment frequency, lead time to implement changes, team velocity, defect leakage, and MTTR to give empirical proofs to the quality of agile investments. Use team engagement surveys to emphasize morale and investment impacts. And if all arguments fail and your resolve falters, well then you can add to our story of woe and join the Great Resignation (or whatever it’s called now).