This approach can easily result in what is commonly known as a “Feature Factory”. In a Feature Factory, the focus is on discovering and writing Features. Unempowered teams are handed Features to go off and build. This makes the Agile Team accountable for delivering Features (an output), instead of true business outcomes. It stifles innovation as Developers are rarely involved in solution discovery. It positions the Developer as a robotic order-taker verbalizing the incessant refrain of “Just tell me what to do”.

I had high hopes that I was wrong. I re-reviewed several SAFe knowledge base articles that potentially addressed my concern:

· Design Thinking

· Continuous Exploration

The SAFe Design Thinking article covers discovering and designing the right solution, measuring success, generating insights, and fast prototyping. But read the article carefully… All of this effort is described as a means to an end — to write desirable and useful Features and feed these Features into the ART Backlog for the Agile teams. A more efficient Feature Factory model. Slaves to Features.

The SAFe Continuous Exploration article covers Agile Teams involved in exploration of customer needs, customer visits, Gemba walks, and brainstorming solutions. But again, read the article carefully… Like the Design Thinking article, the end goal is to write the needed Features and get them into a backlog. A more efficient Feature Factory model. Slaves to Features.

Not good!

Comparatively, the Product Operating Model (POM) concept of “empowered teams” accountable for business outcomes is a clear winner. In POM, the focus is on solving customer problems and delivering business results.

Imagine a world where the significant time, effort, and cost of writing Features up-front is replaced with validated learning cycles. That’s right — instead of writing Features, let’s pair the Agile Team up with the Customer/Stakeholder, give them a problem-to-solve, and ask them to jointly discover a good solution that is valuable, viable for our business, usable, and technically feasible.

Once the solution is agreed to, the Agile Team can decide the Stories and Features needed in support of incremental delivery of value. In some cases, Features won’t even be needed! Then build and deliver the value.

Notice that Feature writing is relegated to the Agile Team and not required as an up-front activity. It becomes a natural activity after the solution is agreed to in support of planning the incremental delivery of value. It belongs within the Agile Team.

Product Operating Model for the win!

SAFe does a great job introducing us to the notion of a Development Value Stream (DVS). SAFe also does a great job describing the Agile Release Train (ART) as a virtual structure of 5–12 teams (50+ people), formed to deliver the value for the DVS.

Herein lies the problem: the ART approach is only one of several operating models used to satisfy a DVS within the enterprise. SAFe doesn’t speak to the other operating models, and a common confusion is that all teams will eventually join an ART.

Yes, SAFe is all about scaling, but its purposeful exclusion of enterprise operating model context was a big miss IMHO!

For example, it is entirely possible that a single team satisfies a DVS by independently building the system(s) involved in delivering value to the customer. SAFe alludes to this a few times in their online articles, but obviously doesn’t emphasize it since it is not a scaling scenario.

It is also entirely possible that a small number of 2–4 collaborating teams satisfy a DVS by working as a “team of teams”. SAFe doesn’t talk about this scenario at all.

Neither of these two situations require a heavy scaling model such as an ART. And, in some enterprises these two lean operating models can cover most of the need!

The key is to identify your Development Value Streams. Then talk about what Teams are involved to create and deliver value. Then go for the leanest operating model you can. Often times, it’s a single independent team or a small number of collaborating teams. #NoARTNeeded

I would love to hear your thoughts and experiences!

Empowered Agile Transformation — Beyond the Framework, by Alexandra Stokes, 2023

What a great book! Alexandra Stokes has written the book many of us Agilists wanted to write. Her approach to Agile transformation is logical, empathetic, and goal-oriented. She includes over 30 personal stories of her Agile transformation successes and failures.

One theme that resonated with me was to avoid relying on framework installation for your Agile transformation. Instead, use a more empathetic approach targeting the needs. Another impressive theme is called “sensemaking” — empathetic insights into how people are currently working, delays, and improvement opportunities.

Transformation Steps

If you are looking for a step-by-step guided approach for frameless Agile transformations, you may have to dig a bit as the wealth of information is spread throughout the entire book and not organized as neatly as you might expect. That said, late in the book the author does show a diagram of transformation themes. I will summarize it here, taking some liberties with verbiage and summarization:

• Transformation Vision
• Observe, collect current baseline data
• Build a change agents coalition
• Activate squads (Agile teams)
• Design the new system of work
• Activate tribes (team of teams)
• Coach and support
• Iterate while measuring progress towards the Transformation Vision

I found this very much aligned with the Simple Scaling approach championed by myself and others.

Great Quotes

Here are some of my favorite quotes from the book (emphasis mine), including some that may be considered controversial.

On Agile Transformation:

“To survive, companies must achieve continuous adaptation, train it as a muscle, adopt it as a habit, and practice it as a discipline.”

“It is critical that Transformation leaders make it clear that everyone in the system will need to change behaviors or leave for Transformation to occur.”

“Ultimately, we want Transformation work to pay for itself, either increased revenue and profit via delivery of value, or reduced operational waste, reducing costs.”

On “The Lean Startup” by Eric Ries: “Ries’ book was an inspiration to Agilists worldwide, who realized we had become efficient at building the wrong thing.”

“The truth is like a lion, you do not have to defend it, set it free, it will defend itself. Agile is like the truth, anyone who has had the pleasure of working this way does not return to the old way.”

On Leadership:

“Execs are perpetually in meetings, … Though it appears they are too busy to learn, decision-making has superseded investment in their own learning. We must make space for them to learn.”

“It seems no one in big corporations has the gumption to admit that business cases are largely fabricated, and therefore the Emperor continues to prance around in his new clothes.”

On traditional project management:

“Program and project managers engage in ‘busy work’ and communications to justify their role, rather than focus on value.”

“The longer you keep traditional project and program managers around, the more their old behaviors and ways of working will be pushed onto their Agile squads, likely hindering their performance.”

“A centralized PMO is not conducive to the Agile concept of small, self-organizing, autonomous teams.”

“The manager must understand that the best way of working is co-designed with the workers.”

“If the vendor refuses to change, that is perhaps an indication that they are not the best partner for your business.”

On the use of large consultancies:

“One of the problems of using a large, consultancy led or trademarked framework to install Agile is that both are a predefined model with no allowance for what makes you uniquely you or what is the identity of your organization.”

“Externalizing your Transformation to a consulting group is abdicating responsibility. Outsiders cannot change an organization. It will not sustain when the consultants leave.”

On the use of scaling frameworks:

“Any large, trademarked framework, or industrial strength consultancy led approach is the antithesisof the Agile manifesto, the 12 principles and 4 values.”

“The very implementation of the framework is anti-Agile.”

“Large Scaling Frameworks are generally unpopular in the community of Agile practitioners as they are marketed towards management, the same people who lack literacy in these ways of working. Often the result of such a framework is that good workers leave, and those who stay are beholden to it.”

“Organizations that are lured into this can be seen conducting elaborate rituals that lack substance, often rigid and dogmatic on how to go about doing a certain task for which there is no such thing as the one right way, and we observe them missing the point and missing the value.”

“Big bang (framework) is not the only way. A more organic empowered approach produces better change ‘stickability’.”

“Frameworks, by their nature, cannot diversify to fit any situation or context.”

“Framework salespeople are incentivized to implement overly prescriptive heavy frameworks, because their focus is on making money.”

“Did we bring the framework because we shied away from the hard problems? Did we believe in individuals and interactions OVER processes and tools? Or did we in fact just implement a big process tool?”

On dependencies: “Agile scaling frameworks tend to ‘manage’ this situation with increasing levels of large group ceremonies and dependency resolution meetings; however, they never truly give autonomy to the teams to manage their own work.”

On SAFe’s PI Planning event: “I remain unconvinced about the value of these events, it’s a lot to ask a team to plan out 6 iterations (12 weeks) in advance with any degree of confidence. … If you add up the cost of a tribe spending two days planning it can be upwards of $250K in attendance costs alone. Wouldn’t we want to get a lot of return on value for that investment?”

“Certification promotes a ‘one-size-fits-all’ approach and, by itself, certification is of no real value to teams or organizations.”

“… I had to conclude that SAFe was a giant compromise, a Framework Trojan horse to allow you to have Agile teams, but not to enable radical reform of how you generate value.”

On Agile mindset:

“It can help you interpret frameworks, take what you need, and discard the rest.”

“Mindsets will always beat frameworks when solving problems with Agile ways of working.”

“An Agile mindset is far more valuable than a purchased framework.”

Which of these quotes resonates with you and why?

Wrap

Don’t hire a large consultancy to execute your Agile transformation. You will spend millions of $$$ for questionable value associated with their checkbox-type approach. Don’t neglect the hard work of transforming by installing a framework. Frameworks by their very nature will solve problems you don’t even have (that’s called waste!).

For more Agile resources, visit us at Agile Authority.

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.

As Agilists, we preach “We want empowered teams!” But we turn right around and tell the teams to use the Scrum (or Kanban) framework. Why? Because we require corporate-wide Agile approach consistency, and we want to make it easier for when people transfer into a new team.

Stop for a moment and realize how utterly stifling this position is to team empowerment. In many ways, it is the antithesis of Agile. Putting process before people is distinctly an unAgile value as per the Agile Manifesto.

We have lost our way, forcing teams into a specific way of working (Scrum, Kanban) while sacrificing agility innovation at the altar of “corporate consistency”.

A Better Alternative

As leaders, it is our job to create an environment where innovation and productivity flourishes. One way to help create this environment is to develop a short list of high-level team expectations. This list of expectations is outcome-oriented, conveying what we as leaders hope to see our teams achieve via their hard work.

Then, TRUST each team to design their own Agile approach, specific to their context, to achieve the desired expectations. Whether we will admit it or not, each team is unique with their own people, situations, and work context.

Just imagine the innovative Agile practices that will emerge! These discoveries can then be shared to other teams and potentially leveraged for the greater good of the company.

An Example

Here is one example of a set of outcome-oriented leadership expectations for a team:

• Maintain a close relationship with the customer
• Improve business outcomes by delivering value early and often
• Adapt quickly to feedback received
• Reduce operating costs by always building with high quality
• Make your work visible, supportive of easily viewing current status
• Be able to roughly predict when new functionality will be ready
• Grow internal knowledge and understanding
• Experiment, fail fast, and learn as you go

Wrap

If leaders will provide a short list of outcome-oriented expectations, our teams will be empowered to design their own Agile approach. Allowing teams to design their own Agile approach leads to higher levels of team empowerment, greater agility innovation within the company, and better business outcomes.

So much better than a corporate-wide Agile approach consistency where “every team must follow the same Agile framework”.

Read more here. Read more about the Agile Manifesto here.

References

• Agile Manifesto, “We value individuals and interactions over processes and tools”
• Agile Software Development Ecosystems, Jim Highsmith, chapter 25 “Designing Your Agile Methodology”
• Agile for Non-Software Teams, Gil Broza, chapter 8 “Design Your Initial Way of Working”
• Creating Great Teams, Sandy Mamoli and David Mole, chapter 5 “After Self-Selection: Now What?”

Situation — the Abby Normal Brain

Dr. Frankenstein’s dimwitted assistant, Igor (pronounced Eye-Gore), is tasked with fetching the brain from the brain depository (after 5PM, slip brains through slot in door). The selected brain is to be installed into the beast, culminating in Dr. Frankenstein’s finest scientific achievement and oodles of fame.

Igor selects the designated brain (Hans Delbruck, Scientist & Saint), but a clap of thunder scares him, and he drops it rendering it a useless mess. He chooses the next brain, this one labelled “Abnormal”. Watch the scene here: https://www.youtube.com/watch?v=hw6xBdXl1Aw.

Later on, when confronted Igor admits to choosing a brain with the name “Abby. Abby Normal”. Watch the scene here: https://www.youtube.com/watch?v=Z7L3PcrhnEg.

Hilarity ensues, but the “transformation” not only doesn’t live up to expectations but goes awry. Watch the scene here: https://www.youtube.com/watch?v=ab7NyKw0VYQ.

Abby-Normal Agile Thinking

Some Agile transformations can feel like a beast with an abby-normal brain. They come to life through careful planning and good intentions, but then are sidetracked by disastrous decisions.

The abby-normal brain of an Agile transformation might say the following:

• “We need to install SAFe ‘as is’ to gain the benefits.”
• “We just paid millions to a big consultancy, so we need to follow their checklist approach to becoming Agile.”
• “We will install Water-Scrum-Fall because the iterative development phase will make us Agile.”
• “We have no idea what our agile transformation business objective is. We just want to go Agile.”
• “We are different. Our complex situation requires a complex solution. SAFe looks like a good fit!”
• And check this one out: “All teams must start with Scrum. There are no Kanban teams, even for ticket-driven support teams that have no concept of an iteration. Once these teams prove they can use Scrum, then and only then we will allow them to switch to Kanban!”

None of these are contrived, I have heard each of these before.

Normal Agile Thinking

Now on to the “good” brain. Poor Hans Delbruck (Scientist & Saint) — probably turning over in his grave as we speak. What would Hans say?

• “Start by defining our business objective for the Agile transformation. Make it measurable!”
• “Spend time understanding the local context before recommending any changes. There is a historical perspective.”
• “Pick & choose Lean-Agile principles and practices that influence towards the business objective.”
• “Keep the practices that work. Ditch the ones that don’t.”
• “Each team is unique. Let’s introduce them to proven Agile principles and trust them to devise their own improvement path.”

Wrap — the Abby Normal Brain

Don’t install an abby-normal brain into your Agile transformation. Test your decisions against the Agile Manifesto values and principles. Coach Leadership to not shoot themselves (and the beast) in the foot. Read more here: https://agilemanifesto.org.

Check out our Resources page with all kinds of other Agile-related goodies: https://agileauthority.com/resources/.