- SAFe Training
- Choose a Course
- Public Training Schedule
- SAFe Certifications
- Advanced Scrum Master
- SAFe for Hardware - Limited Release
- Implementing SAFe 6.0
- Leading SAFe 6.0
- SAFe 6.0 Lean Portfolio Management
- SAFe 6.0 Release Train Engineer
- SAFe 6.0 Agile Product Management
- SAFe 6.0 for Architects
- SAFe 6.0 Scrum Master
- SAFe 6.0 DevOps
- SAFe 6.0 Product Owner/Product Manager
- SAFe 6.0 for Teams
- SAFe 5.1 Advanced Scrum Master
- Agile Marketing with SAFe
- SAFe 5 for Government
- SAFe 5 Agile Software Engineering
- SAFe Micro-credentials
- Leading in the Digital Age
- Agile HR Training
How to Grow an Agile Release Train
The EDW Agile Release Train was established as a fixed capacity model of five permanent feature teams. As our ability to deliver has improved over the last year, the demand for our services has increased. This led us to contemplate our options - do nothing, add another team. extend the capacity of the existing teams - and decide 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, and 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 Brooks was right; nine women can't make a baby in 1 month! Having long been an advocate of Brooks' law, it was fascinating to see it materialise in front of me.
Wayne took the data to the Scrum Masters and asked them what they had observed since adding 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 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.
Order on Amazon Now!
Get the book from Amazon now!
Categories
Popular Posts
