Facilitating Squadification for a SAFe Agile Release Train

Updated 6 February 2024 to reflect SAFe 6.0 terminology.

 

The squadification day had arrived! We had management buy-in to using self-selection to create teams and a structure for our new Agile Release Train (ART). I turned up with my Time Timer in tow ready to facilitate what I hoped would be a great beginning for this brand new ART.

 

Over the course of the week leading up to the self-selection, the thought of launching a new ART with no experienced Scrum Masters had been on my mind. How would we find the right people for those Scrum Master roles? I tend to choose what I read based on what is on my mind, so picked up my copy of Geoff Watts's Scrum Mastery and reread a few chapters on my flights to and from Sydney that week.

 

I took two bright ideas away from this: (1) we had to reinforce the message at self-selection that the Scrum Master role “holds no authority", and (2) when asked to nominate a Scrum Master, teams tend to know instinctively who will be the right fit. Inspired by this, my first task on the day of the self-selection event was to track down the Release Train Engineer (RTE) and suggest that rather than letting individuals self-select into the Scrum Master role, we let the teams nominate their Scrum Master after the squads had been formed. They were agreeable, so that became the new plan.

 

Now we had to get organised. Flip charts were drawn up for each squad, and a Product Owner’s photo was added to each. Everyone else's photos were laid out on a trestle table at the front of the room.  By 9:15 am, we almost had a full house, so we decided to kick off. I opened with a quick run-through of the agenda for the day, followed by the RTE, who set the scene for why they had chosen to use self-selection as the approach to forming teams. Then, it was back to me to run through the logistics for the morning.

First, everyone needed to collect their photo from the front of the room or have one taken if somehow they had managed to avoid being photographed during the week! Next, we heard from each Product Owner about their features and why people should choose their squad (aka Agile Team). One product owner was quick to offer up food and wine as an incentive to join his squad!

 

Then, it was time for the self-selection to begin. Some people moved quickly, almost running to the squad they wanted to join. Others were more cautious. At the end of the 10-minute time box for Round One, we were faced with a few unexpected outcomes. First, no one had remembered to brief the interns, so they formed their own team! Secondly, no one was without a home. Thirdly, adherence to the “rules” was sketchy at best.

 

One of the recommendations Sandy Mamoli and Dave Mole make in Creating Great Teams is to minimise the constraints. For this self-selection, we had come up with three rules: (1) do what is best for the company, (2) teams need to be made up of 8 or 9 people, and (3) each team should have a least one person from each of the functional groups. At the end of Round One, we had a number of teams of 9 and some teams of 5 or 6. We also had teams that were completely lacking in some skill sets.

 

Round Two was marginally better. There was some movement but also some very stubborn participants and the teams still varied greatly in size. Something just wasn’t quite right, but I couldn’t put my finger on it. Each team played back to the room, their overs and under, and then we took a morning tea break, during which we reminded everyone of the number one rule - do what is best for the company.

 

At the end of Round Three, we introduced confidence voting. Using a “fist of five”, we asked each team their confidence that their team could deliver on its mission. Where squads responded with a one or a two, we asked what they needed in order to increase their level of confidence.  This helped the teams get far more specific about what skill sets they were missing. We also asked the RTE and the department head to vote, which helped maintain focus on the big picture and doing what is best for the company. In the final round, a couple of people were nudged by management to move teams in the best interests of the company and the ART. I found this uncomfortable; however, with the clock ticking and the rest of the Quick-Start commencing Monday, it felt like the only way we were going to get to a viable outcome. Despite the management interference, when it came to the final confidence vote, all the squads voted for confidence of three or above. It was a wrap.

As much as I should have been thrilled at this point, I could not shake the feeling that something was not quite right. We ended up with six squads - two teams of nine, two teams of eight, one team of seven and one team of six. Not exactly evenly matched feature teams!

 

The three squads without dedicated Scrum Masters nominated Scrum Masters. That was also more difficult than anticipated. One squad essentially had a volunteer, so that was easy. One squad voted, and the nominee said, “I’m too busy!”. When they re-voted, the next nominee was quite rightly concerned that he also did not have the time! The third squad nominee was about to go on extended leave. Not exactly the magic answer I had been hoping for, but we had Scrum Masters.

 

We closed the morning with a lightweight retrospective. While there had clearly been some challenges with the process, I think it would be fair to call the event a success.

The creativity of the teams with both creating their product boxes and naming their teams was inspiring. And of course, it would not be a team naming ceremony it one or two names did not have to be vetoed by leadership. At the end of the hour, the teams introduced themselves to the train and showcased their product boxes. The energy in the room was nothing short of amazing.

 

The other kick-off activity for the afternoon was the creation of team charters. For this, we used a variation on Edwin Dando's  How to make a social contract and build better teams. While the teams were working on their charters, the “aha" moment I had been waiting for occurred. The four offshore developers that we had thought would be joining us for the quick start had been unable to arrange travel at short notice. This meant we were four people short, but we did not adjust the constraints for the team selection. The maximum size for a team should have been eight, not nine! That was why the teams were so unbalanced.  It was time to confess.

I pulled aside the RTE and filled him in on my thinking. I also expressed concerns about communication challenges the nine-person teams were likely to encounter.  I was keen to rebalance sooner rather than later, but when would be a good time?! After some debate about the pros and cons of making the change immediately, we decided to leave it be. Take the weekend to think it over and revisit the topic on Monday - day one of the QuickStart and SAFe for Teams training.

 

Once the teams finished up their team agreements, we did a quick walkthrough of the run sheet for next week's quick start and called it a day. One day down and five to go!

 

Time-Lapse Video from the Self-Selection Day

Reflecting on the self-selection event there were a few lessons learned:

One of the things I discovered after the self-selection event, was that there were not a lot of existing relationships between the functional teams. Given they were a co-located team of teams, I had just assumed they all knew each other. Seriously, I surprise myself sometimes! I have told the story of the beginnings of the EDW Agile Release Train countless times, always explaining that there were circa 100 people that had worked together for years mostly collocated over a couple of floors in the one building that did not know each other's names. Why did I think this team would be any different?!

In Creating Great Teams Sandy and David recommend minimising constraints. I completely agree with this - however, I would temper this advice by suggesting you also need to be clear about your expectations. If the constraints and your expectations aren't aligned you are sure to end up disappointed. In this case, we wanted even matched feature teams - ideally with two people from each competency, but we didn't tell anyone that!

 

This did end up being resolved after Day 1 of the SAFe for Teams training when the RTE shared our concerns regarding team size and balance with the ART. In an attempt to minimise disruption we asked the over and undersize teams to stay and work through a solution, with the goal being to reduce the nine-person teams to eight-person teams and add a person to the six and seven-person teams. We asked the smaller teams to nominate the skills they were short of and then asked them to work with the nine-person team that had the most people with that skills set. The intent was to find volunteers to move, which of course proved more challenging than anticipated.

 

It was interesting to observe the very active role the product owners who were also line managers played in this horse-trading. Their sense of "ownership" over their new teams made me nervous. While not something to solve for that day I noted this as something to watch for as we moved into execution mode. After about an hour of rather emotional and uncomfortable discussion, the moves were agreed upon. We had fairly evenly matched feature teams - at last - but I fear the cost of the last minute changes could take some time to surface.

 

It was this event that crystallised for me how much the features allocated to each team had influenced the team shape. At the end of each round of the self-selection process, we had asked the squads "Do you have all the skills to deliver on your mission?" What we should have asked is: "Do you have a balanced representation of all the A&I skillsets?"

As you already know we chose to follow Sandy and David's guidance and seed each team with a mission. We did this by pre-allocating features to product owners and using these features as a proxy for the team mission when seeding the teams. In an effort to avoid teams being too theme centric, when it came to providing the teams temporary names for the purpose of the self-selection event we went with Product Owner names, not themes. In hindsight, this was an abject failure.

 

First, it created the impression that the product owners owned the teams. This coupled with the fact that most of the product owners were the most senior person on their team. This created a strange power dynamic, that is taking some time to breakdown.

 

Secondly, people tended to choose teams based on the work anyway! This was different to the patterns that Sandy and David have observed where people tended to choose a team based on who they want to work with. The weird part of this was that teams were not going to be changed for at least 6 months but the features only represented 10 weeks worth of work. This choice set an expectation we would move people to the work instead of work to the people. This was contra to our goal of creating a world in which teams would "pull" in the work they wanted each PI.While not catastrophic this did mean we had to manage expectations as we moved into PI2.

 

I think if I had it over, I would try and structure the event so that the newly formed teams pulled down the features that they wanted after the self-selection event!

This was simply a miss. There were lots of good reasons why we did not communicate earlier but I do think it hurt us on the day. At a minimum, I would like to have communicated the problem we were trying to solve and the constraints before the event.  This provides an opportunity to flush out any flaws with the thought process and gives people more time to make considered choices.

The good news is none of these challenges had a catastrophic impact on the ART.  In fact, five months later, these challenges have paled into the background as the ART has hit the ground running, with a momentum that has the whole building talking about the marked changes in the department since the 6-day quick start!

 

Stay tuned over the next few weeks to learn about how we tackled just-in time training at scale and the ART's first PI Planning event.