In Appearance, but Not in Practice – Why SAFe falls short for the agile enterprise

Many CIOs today have chosen the SAFe framework as their first step in delivering software faster or becoming “agile.”

SAFe is the “scaled agile framework” for enterprise, and as the name suggests, it is used to help IT organizations move faster, and deliver software in smaller releases. Many of these companies have spent millions of dollars on consultants and staff to implement this, and it was a characteristically very hard first step.

While SAFe may be the first step to enabling the full benefits of agile, it should not in almost any case be the last step.

I believe three fundamental practices of agile are missing from SAFe, which prohibit enterprises from truly becoming agile and undergoing a wide digital transformation across the organization. The missing elements under SAFe may exist, but not as intended under agile methods. They include: slow or late digital feedback loops (customer feedback, and analytics), true autonomy and decision-making of product teams is absent, and the proliferation of siloed handoffs between groups still exist.

In my innovation classes at MIT, it was always preached that in order to innovate in your industry, it is best to start looking at other industries that have had to do this well for a long time. In that vein, when I look at speed to market with acceptable risk, and minimal repairs, the global automaker Toyota comes to mind. Toyota’s growth mindset and focus on one mission of continuous improvement by empowering decision-making at all levels, is a  crucial early step in the evolution of software development.

Toyota has practiced this for decades for automobile production, and its approach of continuous improvement and a product mindset when applied to software development is also the big step needed to move beyond SAFe.

Many will agree that SAFe is good at getting developers to deliver in small increments from an existing IT infrastructure. But that falls rather short of the full value gained by implementing the continuous improvement, and bringing an agile mindset to products development.

Empowering cross-functional teams beyond IT who can solve problems autonomously, and driving growth continuously, is the Toyota-like way needed as the next step. In order to truly digitally transform a company, the three areas mentioned above should be addressed, or else as MIT research scientist George Westerman said, in effect, that when digital transformation is done right, it’s like a caterpillar turning into a butterfly, but when done wrong, all you have is a really fast caterpillar.

Slow Digital Feedback Loops

Typically, in enterprises, technology delivery teams are too far removed from the actual customers. Yet they are on the hook for delivering functionality on predefined dates, while not actually working together with the business to react to customer data in digital products—uptick in usage, or increases in sign-ups, etc.

In SAFe, the product owner goes through the product manager, business owner, and release train coordinator to measure the value of the intended delivery with the customer. The engineer has to go through the system architect and solution architect to then get to the customer. Once all of these layers have been extracted, customer feedback is diluted, or not received at all. This lack of ability to measure and react is a drag on time-to-value, and means not just teams slow to react to ever-changing conditions, but ones that risk eroding the value of what they will eventually deliver.

This eye-opening lesson came to me when I worked with a recently acquired startup. I found myself immersed in their process. The whole team established metrics before a sprint, and used their results to plan the next sprint. Anyone who was not involved, and was not working towards those metrics, was considered a constraint or drag.

In order for enterprises to move on from the first step using SAFe, they must embed the business and business strategy in each sprint, with minimal layers.

No Autonomy for Teams

In SAFe, product features are still handled by “Business Owners,” and the ability to pivot based upon direct customer feedback is limited. It seems as if the majority of value realized in SAFe is breaking a long project into smaller chunks of the same, long-planned delivery cycle. The full value of agile includes the ability to adjust delivery based on the data received during each sprint. If the pieces are just smaller chunks of a large release, then the ability to pivot is more one of appearances. The ability to produce the desired outcome, and customer value through speed-to-market, is lost or delayed.  

Teams should be able to make autonomous decisions to obtain value without the overhead of multiple layers for multiple goals. In order to scale in agile, enterprises have to trust the decision makers at lower levels.

The SAFe framework below more or less displays this problem.

The Stubborn Silos

Teams that look to maximize their individual competencies do not actually maximize a combined value for a collective solution. Agile is all about going after a problem holistically, together, with shared accountability for the outcomes, for all involved.

Under the SAFe method, teams try to master their own craft in their part of the delivery cycle, which encourages extra layers of scrum masters, project managers, and release train coordinators to keep everyone aligned. This is not needed if everyone aligned with the mission and the same outcomes. In a true agile practice, teams have have all the tools they need, and the decision-making power at the line of code, on a balanced team to deliver the product. This includes being accountable and have having responsibility to ensure ancillary functions such as QA, product support, and operations for day two are covered.

My favorite simple example is from Eric Ries’s Lean Startup, where he talks about teams stuffing envelopes with letters. The teams that focus on completing each individual task such as folding all the letters, and then stuffing all the envelopes, as opposed to teams that complete this process all at once always tend to lose, as they don’t account for all the time that is lost between switching between tasks. This is true in siloed functions for delivering software.

To sum it up, SAFe is a big first step for enterprises to becoming true agile organizations. The hope is that from there, this will help them realize that there are harder, more transformative next steps, including changing the structure and dynamic of the work culture (it could be the hardest) to come.  

This kind of metamorphosis takes time, but to be a butterfly in a digital world, it is worth the time and effort. I would love to hear experiences of all who are in the middle of their transformation.

(*NOTE: Feel free to like, comment, tweet and/or share if you think this article would be of interest to others in your network.  Feel free to follow Jesse Bean on Linkedin and Twitter, etc.)