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

Em Campbell-Pretty

Nov 29, 2016

Category:

Updated 6 February 2024 to reflect SAFe 6.0 terminology

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:

In the weeks prior to the Quick-Start:
- the ART backlog is refined and prioritised (using WSJF), and;
- the people who will be doing the work are grouped in teams of 7+/- 2 with a Scrum Master and a Product Owner
Day 1 and 2 of the Quick-Start, all the teams attend the 2-day SAFe for Teams training, sitting at team tables with their product owners. During the training, they work with their real features from the ART backlog.
Day 3 and 4, the train holds its first PI Planning event.
Day 5, the Scrum Master and Product Owners attend role-specific orientation training.
And then you start iterating!

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.

The very next week, fate intervened, and the entire ART launch plan was rendered null and void by the announcement of an impending organisational change. We couldn't form teams and launch the ART if we didn't know who would be in the department in eight weeks' time! So, we rescheduled the Quick-Start. Never one to be discouraged, I again put forward the idea of using self-selection to form teams. This time, my approach was to suggest self-selection as a way to boost morale, given the changing organisational landscape. I am fairly sure the department head thought I was completely delusional when I was adamant that we could trust people to make the right choices, but in the end, he agreed. There was just one catch: based on my existing commitments, we would need to hold the self-selection event the day before the Quick-Start. And yep, you guessed it, at that moment, the six-day QuickStart was born!

Our plan was as follows: