Invitation-based SAFe Implementation
by Yuval Yeret, CTO, AgileSparkses
Implementing any kind of organizational change, such as adopting SAFe, is hard and raises several key concerns:
- How do we convince people to adopt the new ways of working?
- How do we get the organization moving in the new direction?
- How do we make decisions about how to implement SAFe in the enterprise?
SAFe recommends decentralizing control while providing vision and gaining alignment. It is also about respecting people and culture and maintaining effective flow. In this guidance article, we will discuss ways we can “Walk that talk” in the way we run a SAFe implementation.
The default approach for implementing organizational change is the “mandate” or “push” approach. This may appear to be the fast and easy way, where a central group of change agents decide when people will “board” the Agile Release Train (ART), as well as how the train should operate.
It may seem easy because the change is mandated and there is little or no discussion about whether the change should occur. It also appears to reduce the risk of a shallow SAFe adoption that doesn’t even cover the essentials, due to bad implementation decisions, by people who have limited or no experience. The problem with this classic approach is mainly that people don’t like to be changed. They like to be involved in making the decision to change as well as designing the change.
The Vision – Implementing SAFe using Invitations
Martin Fowler, one of the Agile Manifesto signatories, wrote an article in 2006 called “The Agile Imposition.” In the article, Fowler says, “Imposing an agile process from the outside, strips the team of the self-determination, which is at the heart of agile thinking.” But what if we can’t wait for people to self-determine that they should go agile? Should the organization wait? Even if it kills the business?
SAFe’s 9th principle – “Decentralize Decision Making” provides some guidance here. The decision whether to go agile and what approach to take is infrequent, long lasting, and provides a significant economy of scale. So it is a classic strategic decision to centralize.
But once that central decision to go SAFe has been made, The Agile Manifesto says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” And “The best architectures, requirements, and designs emerge from self-organizing teams.” If we apply these two principles to SAFe implementation this would mean the best plans for implementing SAFe will emerge from self-organizing teams (or teams of teams) of the people adopting SAFe. Implementing SAFe using a leaner and more agile approach will send a message about the strength of management’s commitment to the Lean-Agile mindset described in SAFe. Can you think of a better way to signal “respect for people and culture”?
In PI planning Business Owners and Product Management present the business context, the vision. The planning context and structure of PI Planning is a “container” in which the Agile Release Train self-organizes to figure out how and how much they can do to further the vision.
Similarly, Invitation-based SAFe implementation needs to set the context and provide the right structure for the group to figure out how much of SAFe they can achieve in their first implementation PI. A flow of an invitation-based implementation can be seen in figure 1, with the blue boxes showing the potential places to involve an invitation to leaders and practitioners.
Using the SAFe Implementation Workshop to invite the Enterprise to consider SAFe
“Leadership is charged with making these types of [strategic] decisions, supported by the input of those impacted by the decisions.” (SAFe Principle #9, Decentralize decision making)
One approach that my company, AgileSparks, has discovered works well when teaching Leading SAFe is to accompany pure training-mode with a “SAFe Implementation Workshop.” In this workshop, whose agenda you can see in figure 2, a group of leaders discuss:
- The reasons for considering SAFe
- How good of a fit SAFe seems to be
- Identifying value streams and designing ARTs
- Guidelines for determining how roles in SAFe are chosen or assigned to people
- Implementation risks and organizational impediments
Through this interactive, collaborative process members of this group will become the initial “guiding coalition,” a term popularized by Kotter. They consider options, make decisions, and commit to working together towards the shared vision.
As you can see in the “SAFe Invitations Implementation Approach Roadmap” above, this workshop format is useful when considering SAFe with a group of leaders across an enterprise/division as well as later on when preparing to launch a specific Value Stream or Agile Release Train. Another way to look at is as a different variant of how to run the SAFe Value Stream workshop that is frequently used following up an Implementing SAFe/Leading SAFe class to help identify Value Streams/Agile Release Trains for an actual implementation of SAFe in the organization.
Spreading SAFe through an invitation to Leaders
The outcome of the enterprise-level implementation workshop is an invitation to potential value streams and/or ARTs to consider what SAFe would mean in their context and figure out when/how to start their SAFe journey.
In most cases, the potential ART/VS leaders (think VP level leaders) participated in the initial Leading SAFe + Implementation workshop and are now ready to consider bringing SAFe to their group.
In larger enterprises, there might be a need for further Leading SAFe+Implementation Workshops to expose more potential ART/VS leaders. In the “Invitations” spirit you can invite leaders to participate in such a class or bring SAFe into their organization, not force/mandate them. The first leaders to accept the invitation are ideal “prospects” (innovators or early adopters) for starting the SAFe journey and should be where SPCs should initially spend most of their time.
Using the SAFe Implementation Workshop to launch a Program/Value Stream
Once a leader decides that the timing is right to consider SAFe in their area, they should again repeat the same pattern – Leading SAFe combined with a SAFe Implementation Workshop to figure out how to go SAFe. This time the audience is Lean/Agile leaders for the ART/VS as well as ART/VS roles such as RTE, Product Management, System Architect.
Typically the Product Owners and Scrum Masters don’t participate in this workshop—in many cases, it is in this workshop where the leadership team figures out what is the mapping between the PO/SM/PM roles and the roles and people in the group.
As the POs, SMs, PMs, are identified they get trained in PO/PM and SAFe Scrum Master workshops. When using the “SAFe Invitations” implementation approach these workshops should include vignettes from the implementation workshop such as starting with a pains/why session and gauging confidence level and ROAMing implementation risks towards the end of the training.
This will help SMs/POs/PMs connect to the vision and feeling more involved in designing the implementation approach. This will rally them to join the “guiding coalition” of the group.
Invitation-based ART Launch
Once leaders of a certain area are on board and have identified an Agile Release Train/Value Stream to focus on and the ART stakeholders/roles have been trained and brought on board as well, it is time get the team-of-teams rolling.
The combination of training everybody using “SAFe for Teams” at the same time with planning the initial PI and getting a real feel for how SAFe will look like works better than just sticking to theory, training exercises, and games.
Bringing an invitation approach into the ART Launch means decentralizing some decisions around how to operate SAFe to the people on the ART themselves. Aspects like program board structure, Definition of Done (DoD) policies, ready policies, engineering practices, agile testing strategies, and some other aspects are great candidates for having the breakout and integrate discussions as part of the SAFe for Teams training. Additionally, you may want to allow teams to make other local decisions about how they use SAFe, as long as they’re aligned with the SAFe principles and it does not cause problems for the other teams on the train, or the ART as a whole, as can be seen in figure 3.
As a blueprint for how the ART will work starts to emerge, it’s time to gauge people’s level of confidence for how the implementation of SAFe will work and surface risks. You can use a “fist of five” confidence vote, similar to what we do in PI planning to gather this feedback, as well as proactively inviting people to share their concerns.
Follow up with questions like, ‘Based upon what we just learned so far, are there any significant concerns that would prevent us from starting to use SAFe?’ The responses from the teams can be used to seed topics for a brief problem-solving workshop or ‘open space’ session, where people can raise their concerns, and then join or lead a breakout session to identify solutions.
Another approach is to ROAM each risk/issue like we do in PI Planning. The use of the facilitation techniques, like ROAMing risks, confidence vote, and open space all demonstrate a “servant leadership” style. As leaders, we are not just telling people what to do, we are involving them in figuring out the ‘how’ and serving them by owning a resolution of key systemic risks to the change. This same technique can be applied during PI Planning confidence vote and “ROAMing” of the risks.
Another interesting practice that invites people on the ART to participate in figuring out implementation details is team self-selection. In this practice, the ART leaders provide guidelines/constraints and let the people on the ART figure out what at the actual teams should look like.   
Caution: Be careful when allowing customization at this point. There’s a two-fold risk, either removing too much from the SAFe model, as well as adding too much overhead with additional process. There’s tremendous value to trying out the SAFe framework, more or less “as is,” or with careful configuration/customization with the help of a seasoned SAFe program consultant, and only then continuing to remove/add/change practices. For a view on the essentials that shouldn’t be changed, please see the Essential SAFe guidance article.
Summary – Evolving SAFe’s Implementation Approach with SAFe’s Lean-Agile Principles
In essence, the approach described above uses Lean-Agile practices and principles to drive the adoption of SAFe. Using SAFe to adopt SAFe. We’re asking leaders to set the vision/direction for implementing SAFe and inviting their people to come on board and participate in designing this change that will have so much positive impact on how work will be performed in the future.
Decentralizing control and engaging as many people as possible in figuring out how to use SAFe tends to improve the quality of SAFe implementation because of ‘Wisdom of the Crowds’ and the higher motivation people have when they’re invited to be involved. This applies to leaders at various levels using the SAFe Implementation Workshop that complements Leading SAFe training and to teams and ART stakeholders using vignettes like pains/vision mapping, implementation confidence votes, and risk ROAMing in each and every SAFe training used to prepare and launch SAFe in ARTs/VSs.
 John Kotter. Leading Change. Harvard Business Press, Dec 30, 2013