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:
  • Day 1 - Self-Selection & Team Building
  • Day 2 & 3 - SAFe for Teams Training
  • Day 4 - SAFe Scrum Master and Product Owner Orientations
  • Day 5 & 6 - PI Planning


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!

Sunday, 30 October 2016

Tribal Unity - The Book

Some of you may have noticed my blog has been a little quiet this year.  One reason for this is that I have been busy writing my first book - Tribal Unity: Getting From Teams to Tribes by Creating a One Team Culture. Some time soon I will blog about my agile book writing experience. Today, however, it is time to celebrate. This week, on the 27th October to be exact, my book went live on Amazon and Agile Denver threw me a launch party!

Me introducing Tribal Unity to Agile Denver

The Agile Denver Tribe
Me unboxing the very first box of books.
Me making sure that the books aren't printed in white ink! 


It was an amazing night. I would like to give a huge shout out to  +Lynn Winterboer and +Chuck Durfee for arranging the event.

So far the book is selling well, toping the Amazon Hot New Release charts and I received my first 5 star review! :-)




Available now on Amazon, iBooks or order a personalised signed copy direct from me!





Thursday, 7 April 2016

Inside the Dragons' Den @ Agile Australia 2016

It is that time of year again, when the various big agile conferences send out the acceptance and rejections notifications to those who submitted proposals. In Australia, this is generally followed by some twitter chatter from those who didn’t make the cut.  This time last year I was one of the many who received a “thanks but no thanks” email from Agile Australia. To be frank, I was surprised. I had submitted two talks that had been accepted by the Agile 2015 conference but were rejected by Agile Australia. What was up with that?  After much soul searching I decided that the only course of action was to volunteer some of my time and get involved in the process next time around. So it was with the best of intentions and high hopes that I became an Advisor to Agile Australia 2016.



Tuesday, 19 January 2016

Video: The Magic Carpet Ride- A Business Perspective on DevOps



Thursday, 17 December 2015

Good PI Planning is the Enemy of Great PI Planning

When I first met +Dean Leffingwell, I had already launched the EDW Release Train - without doing PI Planning. I was attending one of the early SPC classes in Boulder, CO. It was day 3 before I built up the courage to ask Dean the question that had been on my mind since I decided to attend the class: What should I do about the fact we weren’t doing PI Planning?