Warning: include(/home/wp_tgasp3/codegenesys.com/wp-content/plugins/ultimate-social-media-icons/libs/sfsi_Init_JqueryCss.php): failed to open stream: Permission denied in /home/wp_tgasp3/codegenesys.com/wp-content/plugins/ultimate-social-media-icons/ultimate_social_media_icons.php on line 23

Warning: include(): Failed opening '/home/wp_tgasp3/codegenesys.com/wp-content/plugins/ultimate-social-media-icons/libs/sfsi_Init_JqueryCss.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/wp_tgasp3/codegenesys.com/wp-content/plugins/ultimate-social-media-icons/ultimate_social_media_icons.php on line 23
SAFE (SCALED AGILE FRAMEWORK(TM)) INVITATIONS - GUEST POST - CodeGenesys SAFE (SCALED AGILE FRAMEWORK(TM)) INVITATIONS - GUEST POST - CodeGenesys

SAFE (SCALED AGILE FRAMEWORK(TM)) INVITATIONS – GUEST POST

Guest post by Yuval Yeret, Enterprise Lean/Agile Consultant and head of AgileSparks USA

This article was originally published as a series of posts at Yuval Yeret on Lean/Agile, a blog post and email featuring thoughts, experiences, tools and best practices. Read more at http://YuvalYeret.com and connect with him and the CodeGenesys team at the upcoming “Leading the Scaled Agile Framework (SAFe) 4.0 Workshop”, July 12 – 13, Boston, MA. 

As I wrote before, there’s a lot to like about SAFe™(The Scaled Agile Framework™). One of those things is the way some pro-level facilitation techniques are weaved into ceremonies such as the PI Planning and Inspect and Adapt workshops. SAFe™also leverages one of my favorite change management patterns which is starting with leaders.

Two areas for potential improvement based on my experience with enterprise-level agile transformations are:

  • How to go about convincing people in the organization to start using SAFe.
  • How to go about deciding about the details for what aspects of SAFe to use and how.

For both of these aspects there is a pretty strong default approach in the market today – The Mandate/Push approach:

  • This is the “Easy” way where a central group decides for people both when they will “Board” the SAFe train as well as exactly how their train should look like.
  • “Easy” because it might seem to be faster, require less of those “softer” discussions with people, and come up with a better solution because you as the SAFe Program Consultant (internal or external in this case) took the longer class and know best what to do.

I don’t think SAFe™advocates this approach explicitly but it is simply the common way most agile transformations (or change initiatives in general for that matter) happen. See here and here for some more details about my issues with this common approach and my suggestions for alternatives.

I’m just one voice in a growing community of concerned agilists that have seen too many of those mandated agile transformations fail to deliver real agility over the long run. Daniel Sloan wrote recently: “Any organizational transformation must be fueled by a collective sense of urgency for change”. Or go to one of the fathers of agile, Martin Fowler, who wrote in 2006 in an article called The Agile Imposition “…Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”. Or Mike Cottemeyer on the topic of Can you mandate an agile transformation:

If you view agile as a set of practices, or as a way of performing your day-to-day activities, or as a set of ceremonies and artifacts and roles that people are required to perform… I’d suggest that, while probably not impossible to mandate, at best you’ll get malicious compliance if you try. (Note: If you’ll read Mike’s post you’ll see he actually believes the overall transformation CAN and SHOULD be mandated but that the PRACTICES should not. I agree. Wait for parts 2 and 3…)

I use a different approach in most of my enterprise scaled agile engagements. In this first part of a 3-part blog series I will focus on the “When” decision where I prefer Pull over Push. Or Invitation over Mandate. What does it mean exactly?

  • Based on some trigger like successful pilots, conviction, mandate from a client, Organizational leadership together with probably a central change agents group decide upon Scaled Agile as a strategic transformation direction. We can say they are Mandating the Direction or providing a “Commander’s Intent” to use Maneuvering Warfare terms.
  • They DON’T specify who should transform when and they don’t specify nitty gritty details of the how. They mandate the direction AND invite people to choose that direction and find their way there.
  • Some of the leaders in charge of what can become Agile Release Trains  then accept the invitation and pull the change (rather than be pushed or forced to run through a mandated change at a mandated time that fits the “Gantt” for the overall transformation)
  • Note this doesn’t mean the central agent is passive. It means she is pro-actively marketing/selling the change but not forcing it.
  • The timing for the “buy/pull” should be the group’s timing not the change agent’s timing.
  • Marketing/Selling can involve things the SAFe implementation best practices already recommend like running SPC/Leading SAFe classes internally or providing the opportunity for possible candidates to join a public class sponsored by the change champion’s budget.
  • It can mean publishing internal case studies/success stories from early adopters.

Local leaders Mandating the Direction once they’re convinced of it

  • Once a leader decides that it is the right timing to consider SAFe for his group I typically recommend she run a “management workshop” where she basically invites leadership team to learn more about SAFe together (using the “Leading SAFe” as the content).
  • They then decide if/how to actually go about implementing it rather than mandating SAFe based on his decision. This is her involving her leadership team in the decision whether to mandate the direction or in other words create a Commander’s Intent around SAFe for the group. They discuss implementation details but but leave lots of them open. They’re avoiding mandating the practices to their people.
  • In other cases where a leader wants to start using agile or scale it and is not sure about the approach I would still recommend she go through a “management workshop” but in this case that workshop would look at the various alternatives/options and help the leadership team choose the best fit for their context whether it is one framework or a mix of practices from a couple of frameworks or case studies.

Inviting people to decide on Practices

The next level of Invitation over Mandate would involve the actual people in the Agile Release Train (ART):

  • The ART QuickStart is a great way to get a group of teams rolling. I love the combination of training everybody at the same time while also running the initial release planning and getting a real feel for how SAFe will look like rather than sticking to theory or sterile exercises/games.
  • I love it so much that I use a similar approach even in a non-SAFe context. One thing I do that is not explicitly mentioned in the ART QuickStart agenda is involve some invitation there as well.
  • I try to leave some of the decisions around HOW to the ART participants. Aspects like board structure, Definition of Done policies, Ready policies, engineering practices, agile testing strategies and some other aspects are great candidates for having scatter/gather discussions as part of the ART QuickStart or even for letting teams make local decisions as long as they’re aligned to some wider vision about the use of SAFe in the group/organization (that should of course leave some degrees of freedom for this to work… not be a detailed McDonalds style instruction manual…).
  • Another thing I find very useful is inspired by SAFe’s own “vote of confidence” for the release plan. I like to run a “vote of confidence” for the implementation plan.
  • Then I use this question of “What is worrying us about starting to use SAFe as we just discussed so far” (I use it the same way regardless of whether it is SAFe or any other agile implementation approach the group chose) to provide the theme question for a mini-open space where people raise their concerns as possible session agendas and then people swarm to the issues which interest/bother them the most and try to decide what to do about it.
  • I haven’t tried it yet but asking people to ROAM (Resolve/Own/Accept/Mitigate) each risk/issue like we do in PI Planning seems like a great experiment I should try soon…
  • And since we talk about PI Planning maybe the same Open Space approach to discussing risks and what to do about them should be used as part of PI Planning not just the QuickStart?

In summary

To sum up this post – In essence the leaders of the group are mandating the DIRECTION towards SAFe but inviting people to be involved in deciding the exact PRACTICES rather than mandating them. These leaders are leading their group effectively. Showing the DIRECTION is expected from leaders (They can and should consult with their team/people first of course on many issues). Forcing/Mandating PRACTICES is micro-management. It doesn’t fare too well in real life, especially if you take the long term view…

Next is an even more Invitational style using an approach called Open Space Agility. Consider this an experimental suggestion that combines two field-proven practices into one mashup that is just looking for the first opportunity to get its field test (If you’re interested to go for it, let me know…)

In this approach the leader would say something like “We decided to use SAFe in order to XXX insert Commander’s intent here XXX. We know this is the direction we want to take but we need your help figuring out how this would work here in our group. Scaling Agile is a complex thing and while we the leadership team believe SAFe is a good starting point we also believe there are many open questions and risks and we want your help figuring this out. We also want to do this in a true agile fashion – Trying something and inspect and adapting along the way. In this week we will both learn about SAFe and experience running some of its key aspects and also open the space for discussion around how it might work here in practice, what might be the risks and what to do about them. This is your chance to influence this important journey. You don’t have to engage but we would love it if you do. We the leaders promise to listen and try to address whatever comes up”. This Invitation language is taken from Open Space Agility. An agile change management approach created by Daniel Mezick based on the Open Space Technology spirit.

The Invitation and Open Space will be followed up by running the first PI as a set of experiments in how SAFe can be used for this ART group. The Inspect and Adapt workshop at the end of the PI fits very well into the mold of the second open space described in Open Space Agility as a way to solidify the learning, gather a group of people interested in continuing to focus on improving the way SAFe is used in the group  (inviting people rather than forcing everybody to attend – typically ending with more engagement than typical and in my experience the same or even higher attendance rate…).

To sum up: I believe choosing a Pull/Invitation approach to change management is key to transformational success with any scaled agile approach, especially with a comprehensive approach such as SAFe that lends itself too easily to Mandates at the wrong/naive hands. I also believe that the Open Space Agility model can fit pretty nicely into the ART QuickStart/first PI cycle as well as ongoing PI Inspect and Adapt workshops thereafter. If you’re an SPC or RTE at the minimum I recommend you familiarize yourself with the language of Invitation and the Open Space Agility approach and use it to inform your thinking of how to run the different SAFe activities.

About the author

Yuval is a senior enterprise agility coach at AgileSparks, an international lean agile consulting company with offices in Boston, Israel, India. He is leading several strategic long-term scaled lean/agile initiatives in large enterprises such as Siemens, HP, Amdocs, Informatica, Intel, CyberArk among others. Yuval is a big believer in pragmatic, best-of-breed solution design, taking the best from each approach. He is a recipient of the Brickell Key Award for Lean Kanban community excellence. He is the author of “Holy Land Kanban” based on his thinking and writing at yuvalyeret.com.