By Yuval Yeret, SPCT, Chief Technology Officer, AgileSparks
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 also emphasizes respecting people and culture and maintaining effective flow. In this guidance chapter, we discuss ways to ‘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 decides 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; that is, instead of being passive targets of change, they prefer to be involved in making the decision to change as well as in designing the change.
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 … 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 Principle #9: Decentralize decision-making provides some guidance here. The decision whether to go Agile and which approach to take is infrequent, is long lasting, and provides a significant economy of scale. Based on these characteristics, 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.” Also, “The best architectures, requirements, and designs emerge from self-organizing teams.” If we apply these two principles to SAFe implementation, it 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’?
During the Program Increment (PI) Planning event, Business Owners and Product Management present the business context—that is, the vision. The planning context and structure of PI Planning is a ‘container’ in which the ART self-organizes to figure out how and how much the train members 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 places where invitations might be extended to leaders and practitioners.
Leadership is charged with making these types of [strategic] decisions, supported by the input of those impacted by the decisions.
—SAFe Principle #9
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 is shown in Figure 2, a group of leaders discuss the following topics:
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 work together toward the shared vision.
As shown in Figure 1, this workshop format is useful when considering SAFe with a group of leaders across an enterprise (or division) as well as later on when preparing to launch a specific value stream or ART. Another way to look at it is as a different variant of how to run the SAFe value stream workshop, which is frequently used following up an Implementing SAFe/Leading SAFe class to help identify value streams and ARTs for actual implementation of SAFe in the organization.
The outcome of the enterprise-level implementation workshop is an invitation to potential value streams and ARTs to consider what SAFe would mean in their context and to figure out when and how to start their SAFe journey.
In most cases, the potential ART and value stream leaders (think vice president–level leaders) will have participated in the initial Leading SAFe + Implementation workshop and are now ready to consider bringing SAFe to their group. By comparison, in larger enterprises, there might be a need for further Leading SAFe and Implementation workshops to expose more potential ART/value stream leaders to SAFe. In the ‘invitations’ spirit, you can invite leaders to participate in such a class or bring SAFe into their organization, rather than force or mandate these actions. The first leaders to accept the invitation are ideal ‘prospects’ (innovators or early adopters) for starting the SAFe journey and should be where SAFe Program Consultants (SPCs) should initially spend most of their time.
Once leaders decide that the timing is right to consider SAFe in their area, they should again repeat the same pattern—that is, 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 and value stream, as well as ART and value stream roles such as the Release Train Engineer (RTE), Product Management, and System Architect.
Typically the Product Owners and Scrum Masters don’t participate in this workshop. Instead, this workshop is often where the leadership team figures out the mapping between the Product Owner (PO), Scrum Master, and Product Management roles and determines which roles and people will be included in the group.
As the POs, Scrum Masters, and Product Management are identified, they get trained in PO/Product Management 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 then gauging confidence level and ROAMing implementation risks toward the end of the training. This approach will help POs, Scrum Masters, and Product Management connect to the vision and feel more involved in designing the implementation approach and will rally them to join the ‘guiding coalition’ of the group.
Once leaders of a certain area are on board and have identified an ART or value stream on which to focus, and after the ART stakeholders and roles have been trained and brought on board, it is time get the team-of-teams rolling. A combination approach—training everyone using ‘SAFe for Teams’ at the same time, plus 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 about how to operate SAFe to the people on the ART themselves. Program board structure, Definition of Done (DoD) policies, ready policies, engineering practices, Agile testing strategies, and some other aspects are great candidates for having breakout sessions, followed by integration 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 (Figure 3).
As a blueprint of 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 to 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 invite people to share their concerns.
Follow up with pertinent questions: ‘Based on 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 as 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 to that problem.
Another approach is to ROAM each risk and issue, like we do in PI planning. The use of the facilitation techniques, such as ROAMing risks, confidence votes, and open space, all demonstrate a ‘servant leadership’ style. As leaders, we are not just telling people what to do, but rather engaging them in figuring out the ‘how’ and serving them by owning resolution of key systemic risks to the change. This same technique can be applied during the 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 and constraints and let the people on the ART figure out what at the actual teams should look like [8–10].
Be careful when allowing customization at this point. There’s a risk of either removing too much from the SAFe model or adding too much overhead with additional process. There’s tremendous value in trying out the SAFe framework more or less ‘as is,’ or with careful configuration (or customization) with the help of a seasoned SAFe program consultant, and only then seeking to remove, add, or change practices. For a view on the essentials that shouldn’t be changed, see the Essential SAFe chapter.
In essence, the approach described in this chapter uses Lean-Agile practices and principles to drive the adoption of SAFe. In essence, it’s using SAFe to adopt SAFe. We’re asking leaders to set the vision and direction for implementing SAFe and inviting their people to come on board and to 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 the ‘wisdom of the crowd’ effect and the higher motivation that 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 as well as to teams and ART stakeholders using vignettes such as identifying pain points and vision mapping, implementation confidence votes, and risk ROAMing in each and every SAFe training used to prepare and launch SAFe in ARTs and value streams.
LEARN MORE
[1] https://www.linkedin.com/pulse/openspace-agility-right-you-daniel-sloan.
[2] Kotter, John. Leading Change. Harvard Business Press, December 30, 2013.
[3] http://openspaceagility.com/big-picture/.
[5] http://www.infoq.com/news/2014/10/kickstart-agile-kanban.
[6] http://www.infoq.com/interviews/lkfr14-yeret-kanban-agile.
[7] https://management30.com/practice/delegation-board/.
[8] https://www.linkedin.com/pulse/large-scale-self-selection-australia-post-interview-andy-sandy-mamoli.
[9] https://www.amazon.com/Creating-Great-Teams-Self-Selection-People-ebook/dp/B019EKWG6M/.
[10] https://www.scrumalliance.org/community/articles/2013/2013-april/how-to-form-teams-in-large-scale-scrum-a-story-of.
[11] http://www.agilesparks.com/safe-implementation-strategy-leadership-focusing-workshop/.
