How to Grow an Agile Release Train

The EDW Agile Release Train was established as a fixed capacity model consisting of five permanent feature teams. As our ability to deliver has improved over the last year, the demand for our services has increased. This lead to us to contemplating our options - do nothing, add another team. extend the capacity of the existing teams - and deciding to run an experiment.

The train teams were all 8 person feature teams consisting of 1 Scrum Master, 1 Technical Lead, 1 Quality Lead and 5 Developers. Given, the optimal size of an Agile team is considered to be 7 ± 2, in theory we could add another developer to each team and increase throughput. The idea was appealing, it seemed logical. Worst case, should our experiment fail we could always go back to teams of eight by launching a sixth team.

Development Manager, Wayne Palmer, discussed the concept with the Scrum Masters and everyone agreed it seemed like a great idea. So we went about recruiting five new developers After a few iterations all the teams had an additional developer and we watched and waited to see what would happen.

Four iterations (8 weeks) went by and we were surprised to find that nothing happened! Throughput did not increase, nor did it decline, it essentially remained constant. It appears Brook's was right, nine women can't make a baby in 1 month! Having long been an advocate of Brook's law, it was fascinating to see it materialise in front of me.

Source: https://www.stellman-greene.com/2007/05/15/late-projects-man-months-and-the-software-crisis/

Wayne took the data to the Scrum Masters and asked them what they had observed since the addition of an extra developer to their teams. Their observations were consistent, team members had become more focused on their areas of specialisation and the team had started to lose the cross-skilling that had been central to our early agile success. The consensus was we should return to eight person teams and consider experimenting with even smaller teams in the future!

It was time to execute "Plan B", and move from five teams of nine to six teams of eight.  Again we watched with interest to see what happened and this time the throughput of the Release Train went up!

While we did not get the result we hoped for, our experiment did provide a solid approach for growing an Agile Release Train. By adding an extra person to each team in the first instance, new developers were immediately immersed in our culture and ways of working, quickly acclimatising. When we finally made the call to create an additional team, we weren't adding a new team from scratch, avoiding much of the teething pain that a brand new team of brand new developers was anticipated to cause us.

The lost opportunity in all of this was the opportunity to experiment with team self selection. We had always said that if we ever went to a sixth team we would look to the train to self organise, and decide for themselves which team members would form the sixth team. But somewhere in all the shuffling we lost sight of this. If we ever go to seven teams, I will definitely be considering self selection as an approach.