The number of individuals practicing SAFe®, the world's leading framework for business agility, has grown exponentially since its launch 10 years ago. It took 7 years to reach half a million trained, but only two years to double that number to 1 million, announced in 2021 SAFe summit.
The framework is practiced globally across all industries from government and healthcare to aerospace, automotive, and financial services. Over 20,000 enterprises have people trained in SAFe, and since 2017, multiple sources, including Gartner and Digital AI's State of Agile, report SAFe holding a commanding lead over any other scaling frameworks. In 2022, SAFe makes 53% of the response globally, while DIY framework has been dropping.
BUT, the market share doesn't mean neither SAFe is well received nor it is easy to do, actually the biggest competitor is bad implementation.
Here're common mistakes
- lack of collaborative leadership and ownership result in lack of commitment & lack of understanding
there's a common trap when people see SAFe PI Planning, it feels so simple and right thing to do: "why not do the planning together? Go for it!
Guess what, it is not that simple because the magic of PI Planning is crystal clear alignment between strategy and execution, create predictability and trust, instead of looking into hoping magic will happen when you through money and people to a problem, that is not properly understood in the first place. The attendance of business owner is non-negotiable.
Some may say, I have some other priorities and meetings and can't attend PI, just think that for a second:
"are you telling the teams that the company is spending the effort of 50 to 125 people for 8-12 weeks work, and you don't even bother to join?! What happens if there is change of scope or important decision to make during PI Planning"?
The important question is:
What are the most important priority and expected business outcome? How to measure if it is successful?
It shouldn't be IT or transformation who gives order, but rather real business owner(s) themselves, leaders who are accountable for the results, and he or she needs to be there either virtually or physically.
According to the book "extreme ownership", as a leader, you must fully understand and believe in a mission, before you can convince others to embrace it and lead them to do what’s needed to succeed. A true leader takes 100% ownership in his/her domain, including the outcome and everything that affects it.
Great leaders ensure there’s a sound planning process that includesmission clarity, evaluation of options and risks, engagement of all levels, post-action debrief, and systematization of the planning process.
Great leaders prioritize the wider mission over their personal ego. They’re willing to learn, accept good ideas from others, and own up to their mistakes. They also of manage their team members’ egos to keep everyone focused on the team mission.
2. skip value stream resulting in lack of alignment & clarity on expected business outcome
One of the core value of SAFe is alignment, naturally in large organization different departments have different goals, incentives and challenges wish how to solve them. your organization needs to make sure everyone involved to the ART is working together, engaged in synchronized work and active collaboration, and not working at cross-purposes. There're many reasons of misalignment such as lack of psychological safety, lack of clarity.
Therefore before launching the train, it is critical to spend the time and go through value stream workshop with involved stakeholders, to visualize and align clear expectations from each other, how value flow through the departments and how people contribute to the flow of value.
3. Agile Release Train not organized around value without common goal
Still today many organizations believe by introducing agile processes, roles and events will make agility magically appear, but rather, leaders that create holding environment and incentives to organize around value, ensure aligned autonomy with vision to drive problem solving through decentralized decision making with knowledge workers, rapidly inspect and adapt.
Senior executives don't care which agile framework to use but their language is: result, result, result with speed. Well, you can not force people to work more, or work faster, instead, organize around value to identify waste, reduce hand-overs and accelerate flow of value by forming cross functional agile release trains, as shown below.
4. map SAFe roles and responsibilities to hierarchy
There is a common critic that SAFe is using hierarchy to organize work rather than self-organized teams, well, things are not always what they seem to appear.
It is not uncommon that "true agilest" are critical to SAFe. They complain about the framework as being just another hierarchy, far from what they think is Agile. And, of course, many implementations of SAFe do follow traditional decision patterns, where Agile teams are merely executing on predefined solutions instead of being creative value creators.
However, SAFe should not be viewed as a traditional hierarchy. It is all about synchronizing and aligning a large organization based on how knowledge, value, competence and organizational decision making approach, where work on different levels is required to guide and facilitate many teams.
Dean Leffingwell. In this original definition, he says, "The Agile Release Train largely manages itself; we don't ‘program manage’ it. However, we do have to facilitate and manage the process effectively".
There's no ART leadership, or ART management team, but rather a group of people who work as servant leader to the agile release train to encourage collaboration and ensure flow of information, manage by exception.
5. Taking shortcuts on change management
The brain likes what it already knows. If you've never had the chance to watchThe Backwards Brain Bicycle, then please watch it now before reading on.
It amazed me to see when people thinking transformation is about changing people, well, how often have you tried to convince your partner or family member about changing themselves? Does it work? Ok, it might work few times, but imagine to multiply that question to a whole organization with thousands of people who have diversified background, can you really change each one of them? By the way, clock is ticking there's not much time while you are trying to change everyone.
So the point is not trying to change people, but rather change the context to encourage collaboration and see the bigger picture with change of behavior incremental, so that the habit of collaboration grows
In SAFe, the implementation plan is deeply embedded into the work that a SPC or change agent is suppose to do, don't overload people but rather help them on the journey (more details here) and understand where they are. Every transformation in enterprise, if not treated with care, can fail miserably, change management plays an important role. So follow the book here.
6. blindly follow the book
wait a second, "did you just say that we need to follow the implementation roadmap, and now you say 'don't follow the book', isn't this contradicting?"
Not ready, because there're "context dependent" or "context free" cases, in the context free case, do as the book says, such as implementation, in the "context dependent" cases, you need to adjust based on the situation of an organization, rather than copy paste from another company, which might have entirely different services, corporate culture, decision making approach, products and services, which will not work by blindly following the book.
Especially keep the agile principle of Simplicity in mind and not create over-complicated solution, events or roles that have no meeting to be there in the first place. Don't force people to provide status updates if there're no problem to solve, as long as they should regular iteration review with customers and users.
In many occasions SAFe actually doesn’t tell you precisely what to do, this may sound crazy but true: sometimes it is not comprehensive enough, this is when you always keep the value and principles in mind, which sets some guidelines to think about as you figure out what makes sensein your context.
7. wishful thinking that skills and competence is available
While agile gave teams control over their way of working, many people did not have a basic understanding of Agile values & principles, events & practices. This resulted in teams iterating through process tweaks in blind hope of finding the combination that would help them improve their delivery. People lacked a common language to effectively discuss the process problems, the education to solve them, and the experience to evaluate performance.
Adding events, processes and artifacts without looking into existing as-is, can easily overload leaders and participants of the ART, getting confused about what we are trying to achieve, and lose self-motivation due to lack of direction and help.
8. forcing people into agile release train or solution trains
Recently a friend from a Switzerland based company contacted me: "do I need to attend the full PI planning for 2 days, even I have nothing to do with other teams, isn't this waste of time?"
My response was, did you coach or trainer "explain to you the idea of development value stream and team topologies?" He said no. unfortunately it's not uncommon that teams, who are perfectly capable of managing their own backlogs and deliverables, are dragged to PI Planning.
well, everyone who have attended "Leading SAFe" or "SAFe for Teams" would know, that there're 4 types of teams, and 3 interaction modes, depending on the way how they are organized, visualize the value stream and understand how demand flows through so that the interaction is most effective and not blindly follow every single SAFe events, even 90% might be irrelevant. As a matter of fact, the more deployment team can do themselves, the better it is to keep it that way.
9. manage dependencies rather than creating conditions to eliminate them
The more dependencies, the less chances the feature/stories will be done by the end of an iteration. Thus, the more time it takes for the feature on average to go from Program Backlog queue to the market (cycle time).As a result, agility is reduced because the organization is challenged to deliver potential value to the market quickly.This causes organizational stress. While it is easy to say "don't manage dependencies, eliminate dependencies", or "upskill people to T-shaped" or "improve decoupling of application design", in practice, until a team can change, deploy, run and maintain applications in a loosely decoupled environment, pragmatic approaches are required to solve the problems around dependencies, therefore it's important to continuously improve Business/Technical strategy on architectural design, know-how / expertise sharing of people, invest in DevOps and release management, they can all contribute to need of managing dependencies.
first principle of SAFe is "take an economic view", eliminate your dependency, descale whenever possible, however if there's a large endeavor SAFe can help, especially in large complex organizations, but when you are implementing it, be aware this is a change management journey:
change is hard, but nothing worth doing is ever easy. Changing an organization's habits and culture is like moving mountains, a lot of them. Leaders and people resist change, they won't begin to change until you really see there's benefit to continue, When things go wrong, quickly understand why, inspect and adapt, acknowledge it's part of the journey but be sure getting better next time, step by step, stay laser focus on satisfying the customer through early and continuous delivery of valuable software/solutions, because at the end of the day, SAFe is not the goal, rather business outcome.
- Extreme Ownership: How U.S. Navy SEALs Lead and Win (New Edition)
- Scaled Agile Framework
- Digital AI's 16th State of Agile Report
- Henrik Kniberg: Spotify Engineer Culture
- Digital Tango