Tuesday, 29 November 2016

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:
  • In the weeks prior to the Quick-Start:
    • the feature 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 real features from the program 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 sprinting! 
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 blogs posts on the 6-day Quick-Start you will get 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. Saurav (the other coach I was working with) and I hated it

You see Saurav 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 by the team's identity was synonymous with the project they were working on. The business folks who owned the project felt that 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 replicating this mistake, the pattern was repeated with similar results. So when it came to this next 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. In fact, what we really wanted to do was let the teams pull the work they wanted to do from the program 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:


Stay tuned over the next few weeks and I will share with you our journey as we prepared for Squadification, facilitated the Self-Selection event and delivered just in in time training, before rolling immediately into the most amazing first PI Planning event I have been involved with!

Check out Part 2 in this blog series Preparing for SAFe Squadification & Structuring the Agile Release Train