The 6-Day SAFe Quick-Start with Self-Selecting Teams

For those not familiar with the SAFe, “Quick-Start" (also known as the one-week launch) is a proven pattern for launching an Agile Release Train. A textbook Quick-Start goes something like this:

I realise this sounds all fine and dandy if you are working with an organisation that is already Agile, but what if they are new to Agile? Can you still Quick-Start? Absolutely, you can. At this point, you may be thinking I have completely lost the plot. This sounds like utter madness, I know. I thought it was madness, too, until I tried it and realised it was truly amazing. It is my hope that as you make your way through this series of blog posts on the 6-day Quick-Start, you will gain some insights as to why this approach is such a powerful way to launch an Agile Release Train.

Getting back to the point, you may have noticed the textbook Quick-Start is only five days. So, where did this sixth day come from? Well, it all started with the need to form teams.  I was working with an organisation that was structured in functional teams. Advanced Analytics, Campaign Innovation, Capability Development, Engagement, Strategy & Innovation, Operations, and Information Leadership. As part of reinventing themselves as an Agile Release Train, they knew they needed to form cross-functional teams. Over the months leading up to the ART launch, they floated various models past me. The first few versions reminded me of little project teams. There was a theme that described the type of work that the team would do, and each team had been handcrafted to have the exact right number of people with each skill set required to deliver on its theme. My colleague and I hated it

You see, my colleague and I had worked together on both the EDW Agile Release Train and StAART. In both instances, the train had initially been formed by merging a set of Agile projects and Agile project teams into an ART. At EDW, we had learnt that this model tended to create a scenario where the team's identity was synonymous with the project they were working on. The business folks who owned the project felt they "owned" the team. While there was something nice about the close relationship between the teams and their business sponsors, it started to become awkward when priorities dictated that “their" team work on a feature that didn't come from "their" project's backlog! Despite our best efforts to prevent StAART from replicating this mistake, the pattern was repeated with similar results. So when it came to this train, we were determined to fight for more generic feature teams from the outset. Teams that could and would work on the agreed priorities, regardless of which "project" or business person was sponsoring the work. What we really wanted to do was let the teams pull the work they wanted to do from the ART backlog.

When I facilitated Leading SAFe training for the department’s leadership team, I took the liberty of highlighting the opportunity to form interchangeable feature teams, leveraging the Spotify communities of practice model to maintain communication and collaboration within specialisations. While I was at it, I threw into the mix the concept of using  Sandy Mamoli's self-selection approach to create the teams. This is something I had always wanted to try, but to date, I had been unable to find a willing victim. In my view, letting the people who actually do the work decide how best to organise themselves to deliver was the ultimate application of "those who do the work know the most about it". A handful of the leaders in the training group expressed an interest in this rather radical approach in which people decide for themselves which team they should be a part of, but overall, the consensus was that it would not work in this organisation.