The Agile coach training programme at my company has reached its second half. One of the training objectives was to teach the Agile coaches about unit testing and code refactoring. Naturally, the coaching programme expects the trainees to subsequently coach their teams on the same topics.
As a mentor to two new Agile coach trainees working in different teams, I often allow them to choose their approach and evaluate it later on. Both teams had no prior knowledge of unit testing and code refactoring. After learning the basic techniques, Trainee A decided to ask everyone to try writing unit tests themselves simultaneously. They would then share and discuss their work during Code Review. On the other hand, Trainee B dedicated all his time to working with a single developer, allowing others to continue working as they had been. Once that developer had grasped everything Trainee B knew, they would split up and work in pairs with the other two developers.
During our weekly meetings, we answer questions, address challenges, and introduce new techniques. Some of their teammates are also invited to join these workshops. I noticed that the teammates of Trainee B quickly mastered the basics and asked advanced questions, while the teammates of Trainee A struggled and asked basic questions. It seemed that the teammates of Trainee A had not practised outside the workshops.
Teaching a group of people a new skill requires time and effort. It’s similar to working on a product. We consider enabling a single developer to write unit tests and refactor code as a work item. A developer who is learning the technique becomes a work in progress (WIP). What Trainee A did was pull all the work items out of their backlog, resulting in a multitude of WIPs. As a result, Trainee A couldn’t focus on any one of them. In the end, he could only convey his message through daily Code Reviews. He struggled to make the developers remember the things discussed during the code reviews. On the other hand, Trainee B only pulled out one work item from the backlog at a time. This allowed him to focus on addressing the questions from a single person. Eventually, Trainee B could “complete” a work item and move on to the next one.
Limiting WIP improves the working process significantly. It eliminates unnecessary context switching, which wastes time and effort. By focusing on a single work item, we also improve the quality as we temporarily set aside those in the backlog. The cycle time can also be reduced, regardless of the complexity of the work item. The above case, of course, is a simplified version that ignores other factors, such as the capability and attitude of the two teams. However, unless these factors in the two teams are extremely different, the effectiveness and efficiency of Trainee B should always be much higher than that of Trainee A.
Finally, we evaluated the two approaches and suggested to Trainee A to focus on one developer first. We hoped to see his improved progress.