Thursday, 17 August 2017

Learning from Re-Squadification

One of the things I love about the A&I Agile Release Train is their drive to learn. Following the Re-Squadification day the train held a focused retrospective in order to understand what had gone wrong and how they could avoid a reoccurrence of a long drawn out self-selection process in the future.  The insights were fascinating. There were three main drivers of the stalemate - a belief the teams of 6 or 7 would not be effective, “feature pitching” by Scrum Masters and Product Owners and people trying to do the right thing!

The frustration with team size I put down to a combination of decisions being made behind closed doors and lack of communication. Deciding the team numbers was perceived as a logical decision that didn’t require wide consultation. In hindsight I am embarrassed I didn’t think to suggest to the RTEs that they take the suggestion to the train before communicating it. Or even better involve the train in making the decision in the first place. It was naive of us to assume the teams would not have strong opinions regarding team size. I wonder if subconsciously we feared retaliation, as despite being three PIs in there were still fierce debate across the train regarding the need for component teams. In reality we just didn’t have holistic buy in to the feature team model.

The “feature pitching” was frustrating. Based on the learnings from the first self-selection event we had tried to remove the “work” from the decision but we probably had not been explicit enough in that respect. Teams were recruiting members based on the features they intended to pull. Again, I fear communication had been our downfall.

The third cause was more interesting and somewhat unexpected. In line with +Sandy and Dave’s guidance we briefed the train to consider the best interests of the company and the train in making the team selections. As the day went on, we came back to that message time and time again but it didn’t seem to make any difference. When the leadership dug into this post the event, we learnt that team members were staying put because they believed that their membership of a specific team was in the best interests of the company!

I also felt that “absentee voters” had been a challenge. In almost every case the person who was not present had given a specific instruction about what squad they wanted to be in and their proxy did not feel empowered to move them.

The opportunity to use these learning came around sooner rather than later, as the addition of some new delivery partners meant more teams on the train in PI5. Feedback from the last self-selection event indicated that the train valued the ability to do self-selection, however, they were not in a hurry to do it again! Wanting to empower the train, the leadership put it to a vote: Should the train self-select prior to PI5 or should the leadership team make the required changes and inform the teams of the outcome?

Thursday, 3 August 2017


Three PIs after the 6-Day Quick-Start it was time to “re-squadify”. We had promised the teams during the initial self-selection event that they were not making life long commitments and that they would again have the opportunity to self-select in two or three PIs time.

Over the preceding 6 months there had been a lot of change. The original 6 squads had been reduced to 5, as result of some parental leave and secondments. We had onboard two new squads based in China. The interns had moved on to their next rotation and there had been a few leavers and joiners, as is natural with any new Agile Release Train.

Re-squaditification presented the opportunity to revisit the constraints within which the teams would form. Specifically, we decided to look at team size and the approach to Scrum Masters and Product Ownership. The two squads in China had been through a small scale self-selection day just prior to the beginning of the last PI,  so we decided not to disrupt them and leave them out of the  “re-sqaudification” this time.

Friday, 21 April 2017

Thursday, 13 April 2017

SAFe PI Planning Quick-Start Style

The schedule for the two-day PI Planning event, days five and six of the 6-day quick-start, was pretty much textbook SAFe. Given I have blogged about PI Planning in the past, let’s skip the blow by blow description of PI Planning and focus on the highlights from this particular Agile Release Train's first PI Planning event.

Firstly the opening messages set the perfect tone for the 2-days. The RTE opened the event with: "It’s been an epic few days and we are here now. PI Planning.  We are here and we are doing it and it’s awesome!  Now it’s about the real work!" 

Their executive sponsor was equally as passionate: "I think it is great you guys are doing this and making the 6-day investment. I'm glad this team is embracing the change and wanting to do things differently. It’s going to be bumpy but that’s ok. I'm excited to see what all these blank boards are going to turn into."

Teams used foam boards for their plans instead of post-it pads
so nothing would need to be stuck  upon the walls.

Thursday, 16 February 2017

Just-in-time Training for an Agile Release Train Quick-Start

The three key ingredients in any ART launch are: teams, a well defined, force ranked feature level program backlog and the knowledge to execute in a lean and agile manner. In the case of the A&I ART, we now had teams and a backlog, we just needed the knowledge. This is where the SAFe for Teams training and the Scrum Master and Product Owner Orientation workshops came in.

Monday morning the teams returned to same venue we had used for the self-selection event, to commence two-days of SAFe for Teams training. I was thrilled that the organisation had taken our guidance and had gone all in for the event. Even the department head attended the entire two days.

There is something about all the teams on a train, including the leadership team, learning together, with their Scrum Masters and Product Owners that is just magical. Having spent many years convinced that training circa 100 people at once was nuts, then going through the process a number of times, I have to say I was wrong. If Harvard Professor J. Richard Hackman is to be believed, 30% of a team’s eventual performance is dependent on the initial launch of the team. Personally I cannot think of a better way to launch a team of teams than two days learning together.