Our Training Sprint

I suppose there's never a good way to start an agile project. On the project I was put on, almost everyone was new to the codebase, new to the project, and new to each other. So I called the first sprint Sprint 0 - our training sprint.

The difficulty was to ramp up with learning the existing product, learning the business rules, and learning to work with the tools and processes provided. With this sprint complete, here are some of the lessons I came away with:

• Being on the project doesn't mean buy-in - The standard way to illustrate commitment in agile is the fable of the chicken and the pig. As a development team, the ideal is to get collective commitment, where all individuals work together to get the product over the line. It was clear when individuals were merely involved rather than committed, be it some or most of the time.
• The daily scrum is important - Perhaps the daily stand-up felt too much like a status meeting, but it was really useful for the team to know what was going on with the project as a whole. When information was shared outside of this, it didn't always get to everyone.
• Intervention should be done early - We had one member who only ever turned up for some of the meetings, and missed a lot of the daily stand-ups. Intervention about what was expected as a team member came too late in the sprint to rectify the problem. And even then, it did little to change things.
• Business As Usual consumes time and energy - We had two issues with BAU. First, when production issues arose, it took time out of the sprint to deal with them. Second, there were non-sprint activities for nearly all members dealing with that took focus away from making progress.
• It's easy to revert into a management-like demeanour - The ideal of the scrum master being a servant-leader is really difficult to achieve in practice. At times, it felt like I was driving the process too much, rather than simply guiding a self-organising team.
• The day-to-day can obfuscate accumulated achievement - At times, it felt like the sprint moved really slow. Yet when I added up what we had built by the end of the sprint, we had made quite a number of improvements. And that wasn't including some of the background tasks we did, like setting up automated deployments or getting better code coverage tools.