Spotifying SAFe with Guilds, Chapters and Squads

Last month’s Agile Australia conference played host to both Dean Leffingwell, the creator of the Scaled Agile Framework and Anders Ivarsson, Spotify Agile Coach and co-author of the Scaling Agile @ Spotify paper. Those who were able to drag themselves (and their hangovers) out of bed early enough on day 2 of the conference were treated to an “Ask the Experts” panel featuring both Dean and Anders, along with Linda Rising and James Shore.  I’m sure you won't be surprised to learn that it was not long before an audience member asked what might seem like the obvious question - SAFe vs. “the Spotify model”.

 

 

After the mandatory cringe from Anders (the Spotify folk really wish the rest of us would stop calling what they do the "Spotify Model”), both Anders and Dean were quick to agree that it was not an either-or question. To quote Dean Leffingwell, "We had Henrik Kniberg in class last week and I think it would be fair to say we learned a ton from him and I think they will learn a ton from us." As someone who has been using ideas from Henrik Kniberg’s books and the Spotify folk since very early in my SAFe journey, I must say I agree with the sentiment.

 

 

First let me give you some context. The EDW Release Train had been born in a world where the delivery team had a strong track record of failure to deliver on business outcomes. An endless parade of consultants had passed through the domain declaring the delivery problems to be the product of poor technical practices that had resulted in a lack of technical integrity in the platform. Prior to the restructure that had enabled the launch of the EDW Release Train, the existing management had created a new group called “Technical Governance”, to define standards and oversee the technical integrity of the delivery. The restructure that landed me at the helm of the EDW Delivery organisation also saw the Technical Governance function move away from delivery, so as to provide an external “control” over solution design and build.

 

It was following this restructure that the EDW Release Train was launched. This marked significant change in how we delivered, as we exited the outsourced, offshore, outcome-based contract approach to development in favour of a co-located, co-sourced, onshore agile release train. In my view, this change in the delivery model meant that the Technical Governance function established to provide quality assurance over the outsourced delivery had no place in the new world. However, this was not the view held by other parties in the organisation.

 

After about 9 months of watching me argue with the powers that be that “You cannot inspect quality in”, Wayne pitched the idea of “Guilds” to me and my leadership team. His self-appointed mission was for the train to take ownership of the quality of what it delivered and more specifically to “put the control and responsibility for core specialisations into the hands of the people who are doing the work, in order to restore a sense of pride and satisfaction within their work.” This mission was premised on the deeply held belief that “to achieve true continuous improvement, the value stream needs to be owned, understood and improved upon by the people closest to it.” It was his hope that people with expertise in specific skill sets would meet regularly, as a Guild, in order to:

 

 

It has always puzzled me why Wayne chose to start a discussion about Guilds rather than Chapters. For those who have not read the Scaling Agile @ Spotify paper the definitions are as follows:

 

To me, a Tribe is not unlike an Agile Release Train - a long-lived team of agile teams. So for me, given we only had one train, it made sense that what we needed was Chapters. I’m not sure whether Wayne agreed with this logic, or was just happy that I was bought in enough to argue the point, but in the end, we decide to form “Chapters”.

 

For each specialisation, a pair of Chapter Leads were nominated and the cadence of regular Chapter meetings commenced. Every team on the train was represented by at least one person in each chapter. The Chapters quickly evolved to become a core part of how we operated at EDW, fully integrated into our end-of-sprint Bubble-ups, taking ownership of train-wide challenges, and setting the standards for the way we worked.

 

In my more recent travels as a consultant, I have also found the concept of Chapters to be useful when launching a new release train. In the case of StAART, there was a large program team already in place when we started talking about launching a train. The existing structure essentially consisted of functionally aligned teams. There was a Business Analyst team, a Functional Analyst team, a Development team, a Test team and an Infrastructure team. The leaders of each of these teams made up the membership of the Program Manager's leadership team. So the first order of business in shaping this release train was going to be helping the Program Manager, shift her organisation from being made up of functional teams to cross-functional teams.

 

Given the Program Manager was also going to be the Release Train Engineer her world was about to change dramatically. In the new world, her lieutenants would likely be the ScrumMasters, which at that point of time didn't even exist. Given their leadership and knowledge of the existing workforce, these functional team leads were going to be key to helping us get to well-balanced, cross-functional teams. I think it was the memory of Anders Ivarsson and Joakim Sundén's talk at Agile 2013 that made me think of Chapters and in particular Chapter Leads as a mechanism to help with this shift. You see, at Spotify unlike with EDW, the Chapter Leads were the line managers of the chapters.

 

We went on to work with the newly appointed chapter leads, to shape the agile teams, which we called Squads. ScrumMasters were appointed and joined the Chapter Leads on the train’s leadership team. The Chapter leads facilitated regular chapter meetings and the ScrumMasters facilitated the sprints. StAART celebrated its first birthday last month and the model is still evolving. As we found at EDW, it is not as simple as slapping a “chapter” badge on a group of people, these things take time. Next PI, StAART is introducing Hackdays (inspired by Anders talk at Agile Australia) as a way to “step up” the role of the chapters in the “relentless improvement” of the train.

 

At Pretty Agile, we have gone on to reuse the chapter concept in other Agile Release Trains, some more so than others, My favourite chapter, which we tend to use with almost every new Release Train is the ScrumMaster chapter. One colleague is a huge fan of getting a newly minted group of ScrumMasters to bond in their chapter meetings by arming them with copies of Lyssa Adkins' Coaching Agile Teams and suggesting they run a book club. As for SAFe and Spotify, SAFe has communities of practice but the concept does not seem to have been fleshed out as well as the Chapters and Guilds approach used by Spotify. I don’t know if we'll ever see Chapters in SAFe but I did notice that the SAFe 4.0 preview includes a Communities of Practice icon on the big picture and for me, that is a step in the right direction.