Who is watching after your agile money? Part III

Part III: A recommendation on how to manage agile investments

Going agile at scale is a complex undertaking for enterprises with a rich tradition of running waterfall programs. And arguably the journey is no less significant in size and scope than the transformation of the global automotive companies in the ’80s with the introduction of lean manufacturing, the inspiration behind agile development.

When traditional mass-producers like General Motors, Ford and Chrysler decided to replace their century-old assembly lines with lean factories, they realized that the change was revolutionary, and that everything — e.g., the factory floor, operations, the supplier ecosystem, the culture — had to be redesigned. However,  going agile hasn’t triggered a similar change anywhere yet. Instead, most enterprises are following an evolutionary path by retrofitting their traditional operating models — organization, governance, processes and tools — to run their enterprise-scale agile programs. This seems to be an oversight, because valuable resources and time are being wasted along the way. In Part II of this series, we discussed how enterprise-scale agile programs may cause unintended waste, and therefore pain — like strained business-IT relationships, reduced functionality, delayed deployments, team moral problems and attrition.

Based on my hands-on client work and industry research, I am convinced that the best approach to managing agile programs starts with replacing the outdated management controls, which are vestige of the traditional program and project management theory, with controls specific to agile. This may sound obvious, but the devil is in the details. Traditional controls produce misinformation and waste resources. When my team discovered that an agile program was costing twice its original estimate, the program leadership couldn’t believe it, and the program teams strongly argued against it. It took many more months to for the leaders to validate our assertions and to act on them when the pain became unbearable. Existing reports were giving the management a false assurance on progress via a rearview mirror perspective, while offering no visibility into how much work is left. Furthermore, when we asked for resources to help create forward-looking perspectives, no one was available; never mind that 9% of the program FTEs were classified as program and project managers.

Technology for Alpha LLC

In my view, there are four fundamental dimensions of controls that are pertinent to enterprise-scale agile programs. First, the raison d’être of these programs is to deliver what is committed to the customer. Second, the financial commitments to the enterprise must be met to make sure that scarce investment monies are prudently spent. Third, all parts of the program must strive for excellence in operations to maximize program throughput. Fourth, the definition of success should be based on doing better than yourself every time.

It is important to emphasize that these four dimensions need to work in unison. Weakness in one would severely diminish the chance of success as a whole. For example, excessive focus on financials may stall innovation; inability to manage customer commitments may cause severe pressures on agile teams and create a bias for short-term wins at the expense of long-term losses.

In each dimension, there should be a handful of control points clearly assigned to a single executive role — e.g. business leader, capability owner, product manager, program lead — with a clear line-of-sight to distribution of responsibility down to the individual agile and enabling teams. A well-defined control model shouldn’t have more than 20 control points at the highest level. Any management reports or metrics that don’t support these control points should be removed from official distribution to keep everyone’s focus on controls that matter most. Underlying metrics should provide perspectives of what has been achieved as well as what lies ahead. An executive balanced scorecard should aggregate program performance at all control points, guide the structure of executive performance discussions and provide the official fact base.

I previously asserted that enterprise-scale agile programs don’t blow up in the same way their waterfall cousins do, but they bleed insidiously. The above agile program balanced scorecard is designed to stop bleeding by providing program leaders and stakeholders with an objective yardstick and integrated controls to monitor performance, identify improvement needs and pursue them decisively, systematically and continuously.