Wouldn’t it be great if there was guidance on how to know if your Agile transformation is doomed to failure? Perhaps a short set of leading indicators or “red alerts” that give us an early warning signal? If we have this, we could react and potentially turn the ship around before it hits the iceberg. It could save millions in cost, time, and effort.
Caveat – I have experienced each of these in one form or another. Guilty as charged!
Red Alert #1: Using a Checklist Approach
Many Agile transformations use a checklist approach – do this, then that, then that, etc. Check the boxes and when completed claim, “We are now Agile!”. Time to party! Well, not exactly…
An example checklist to install a portfolio level might be:
Large consultancy companies (names withheld, but easy to guess) are notorious for creating sets of checklists full of activities to execute to become Agile. They generally cover all levels needed for a holistic Agile transformation – team, program, portfolio, leadership, shared services, etc. These consultancies pass checklists off as a disciplined list of steps based on their deep expertise in using Agile. If you blindly follow the checklist, the result is that you will somehow magically become Agile!
Even smaller companies can fall into the trap of focusing on an internally built list of output-oriented activities. Unfortunately, this flawed approach can be seen in companies of all sizes contributing significantly to failed Agile transformations and costly waste. Your Agile transformation is doomed.
Perhaps your situation is similar?
Instead
Start by defining the measurable business goals (speed, quality, customer satisfaction, etc.) we want to achieve through an Agile transformation. Next determine the “agile outcomes” that will most likely influence those business goals. Example agile outcomes might be short feedback loops, predictable delivery cadence, teams aligned to value, etc. Then install the agile practices needed to achieve the agile outcomes.
Agile Velocity has a great example of this approach here.
This streamlined outcome-oriented approach will help ensure that your business goals associated with the Agile transformation are achieved. Compare this approach to focusing on output-oriented checklists. Which has a better chance of success?
Red Alert #2: Measuring the Wrong Thing
In Project to Product, Mik Kersten describes several failed Agile transformations at notable companies such as Nokia and a “large unnamed bank”. A common theme in these failures was the use of “proxy metrics” to measure their Agile transformation.
“In every way that it was being measured, the transformation was on track – all of the right activities were happening, right down to the adoption of the Agile tool. But the developers were suffering from major friction, both in what it took to build code and in what it took to deploy it. Even more consequential was how difficult adding features had become due to the size and architecture …”
Classic proxy metrics to avoid include:
- Teams trained in Agile
- Number of sub-organizations where Agile has been rolled out
- Percentage of teams using the official Agile tool
- Number of teams using a 2-week iteration
- Percentage of Scrum teams with Product Owner and Scrum Master roles assigned
- Etc.
Proxy metrics are those that might appear interesting, but in reality, they say nothing about the desired business outcomes. Generally, you will see proxy metrics when no measurable business goals have been identified. Like Kersten, I personally have witnessed a Fortune 50 company manage an entire Agile transformation using proxy metrics, specifically “number of Teams trained”. The company is now on its 5th Agile transformation.
Instead
Start by defining the key performance indicators (KPI) that relate to the desired business goals associated with the Agile transformation. These KPIs become your outcome-oriented metrics. Example KPIs might include current customer satisfaction score, average time-to-market, number of post-release defects, business value rating, and the like.
Defining meaningful KPIs aligned to business goals will help ensure that we are measuring what truly matters. Monitoring these KPIs also present us an opportunity to pivot and make some changes. Compare this approach to focusing on proxy metrics – which has a better chance of success?
Red Alert #3: Focus is on Installing SAFe
Many large-scale Agile transformations bring in a scaling framework such as SAFe for enterprise agility. Reasons vary, but mostly it is about installing a consistent cadenced-based product development approach across all teams and “team of teams”. Millions of dollars are spent on SAFe training, coaching, and transformation activities for the entire company or organization.
Unfortunately for many companies installing SAFe becomes the goal. These companies can lose focus on the real end – achieving the business goals for the Agile transformation.
Instead
Install the Lean-Agile principles and practices that are directly related to achieving your business goals. For example, if your primary business goal is “reduce time-to-market average by 30%”, then you may want to install principles and practices such as incremental build, fast learning cycles, WIP limits, and alignment to value.
SAFe has a great list of 10 Lean-Agile principles here. A summary of Lean principles is here.
Treat SAFe as a guidance framework consisting of principles, practices, roles, events, and artifacts. Pick and choose the ones that make sense for your specific situation as derived from your business goal. This helps to ensure a more streamlined lightweight approach to transformation versus a massive full-on framework implementation resulting in unnecessary overhead, roles, and time-sucking events. Which has a better chance of success?
Red Alert #4: We Skipped the Part About “Alignment to Value”
How many of you have been involved in an Agile transformation that totally ignored alignment to value? Me too – guilty as charged. We shifted teams over to Scrum or Kanban, trained them, and claimed success. While each team may have achieved a 5 – 10% productivity increase, the overall business impact was negligible. As a company or organization, we were still slow to market, delivered with bugs, dealt with massive dependencies, and had no time to address the ever-growing technical debt. Sound familiar?
The bottom line is that this type of Agile transformation approach is a local optimization at best. And we now know from systems thinking that local optimizations are useless overall unless they specifically address the bottleneck.
Alignment to value is at the heart of every Agile transformation! Skip it at your peril. Shame on SAFe for waiting 8 years to add it to their list of Lean-Agile principles. Shame on all of us for not emphasizing this crucial aspect in every Agile transformation.
Instead
Identify the value streams early on in the Agile transformation. Encourage creative ways of forming “teams of teams” to ensure that all teams involved in delivering value across the value stream are aligned into a common work structure. Convert existing component-based teams into cross-functional teams. These strategies will significantly reduce dependencies and delays associated with wait times.
Go big or go home. Alignment to value is a go-big play. If you are desiring substantial business improvement, then alignment to value is a tablestakes practice. When considering an Agile transformation based on alignment to value versus one that is not – which has a better chance of significant long-lasting success?
Red Alert #5: We Still Use Projects
The project paradigm leads to all sorts of lean anti-patterns. In a project-based world, project teams are formed and brought to the work. It invariably results in each person working multiple projects.
True story: Talking with a large corporate client, I once asked him, “How may projects would you say each developer works simultaneously?” He proudly answered, “About 7 or 8 on average. We only hire the BEST – developers that can handle a big workload and bounce back & forth across multiple projects!” After a few additional weeks of coaching and data share, he finally saw the light. We concluded that each of his developers were 10 – 20% productive due to the massive cost of context switching. He swallowed his pride and was now ready for lasting change!
The project-oriented approach of bringing people to the work is not suited at all for complex knowledge work such as product development. Your Agile transformation is doomed.
Instead
Shift to product mindset. Treat projects as just another type of incoming work into the portfolio kanban. Decompose the work into features in the program kanban and stories in the team kanban. Prioritize the work accordingly, mirroring the level above. Keep teams persistent and “bring the work to the team”.
BONUS Red Alert: Leadership Has Delegated the Transformation
Delegating the Agile transformation to others sends the signal that the transformation is not important. An Agile transformation is about leading the change, not supporting the change! If leadership is not engaged, your Agile transformation is doomed.
Instead
Stay at the forefront of the transformation. Lead by example. Communicate, communicate, communicate. Establish the business goals of the Agile transformation. Ask for everyone’s help to accomplish the business goals.
Wrap
It’s never too late to get your Agile transformation back on track. If you are seeing any of these red alerts, your Agile transformation is doomed to failure. Step up, point out the inadequacies, and paint a better picture. Ignore the sunk costs and pivot to a better world, focusing on business goals, agile outcomes, and selective use of portions of proven frameworks.
For more on SAFe, visit here. For more on what all is typically involved in an Agile transformation, visit here.