When converting to Scrum or other Agile techniques, managers often wonder whether it will really improve productivity. The whole process seems chaotic, so how can teams be more productive than traditional project management and development practices?
This is the story of three teams in the same department and how we were able to measure their productivity during their first year of using Scrum. The data came from the teams’ burn-down charts with work and capacity estimates using Ideal Days. The charts use 3-month rolling averages to more clearly show the trends. 80% productivity would be the ideal target.
Balancing Development and Support
The first team had to balance both development and support. Approximately every six weeks, their main client had to deliver milestone builds to the end client and the crunch on that project often meant even more support. At the start of their first sprint, the team was skeptical, but they committed to giving Scrum a try. They noticed the improvement immediately and never looked back. Of the three teams, they were the most diligent in applying the practices of Scrum, but it was still very difficult to predict their support work. As you can see from the chart, there was still a big gap between the work they initially committed and what they delivered. They kept track of their support work, did thorough retrospectives after each sprint, partnered closely with their clients and put in a lot of effort to stabilize and improve their product. After about three months, the work paid off and their productivity started to climb. Soon they were consistently meeting or exceeding their commitments and their clients were happier with the product and support service. The drop-off at the end was due to the team being restructured as their client entered a different phase of development. If they had continued, I think they would have improved their productivity to more than 70%.
Blue Sky Goals
The second team was the most enthusiastic from the start. They still had to do support, but their product was more stable and their main client was a smaller team, so it was easier to predict and budget support work. In addition, 2 of the 5 programmers were expecting babies in August and would be taking six weeks of paternity leave at the same time the others were planning short vacations. Nothing like the impending arrival of babies to motivate a team to improve their productivity. It also helped motivate the client to set priorities. Vacations can be negotiated, but babies were coming whether we liked it or not. Like with the first team, this team also tracked their support work, did thorough retrospectives and partnered closely with their client, resulting in steadily climbing productivity. As they started meeting their commitments, they started challenging themselves by committing a little more each sprint. I insisted they not commit more than 80% of their capacity, so they started setting “Blue Sky” goals. These goals were tackled only if their regularly committed work got done. Once they started reaching their Blue Sky goals, I let them commit more than 80% of their capacity. After their paternity leaves, though, the new dads were tired, so they stabilized back at around 80%.
The Pressure To Commit More
The last team to adopt Scrum was under tremendous pressure to make up for lost time. The team was formed in January after the previous team responsible for the product had either quit or moved to one of the other teams. Their product was way behind schedule and it was having a major effect on their client. It took about three more months for the team to ramp up, get familiar with the technology and each other. They were committed to applying Scrum practices, learned from the other two teams and had a lot of early success. However, their client continued to pressure them to deliver even more. Although, I insisted it was better they stay conservative and over deliver, they started committing more and more of their capacity, even committing more than 100% for three sprints. As a result, they started missing commitments. Between the pressure and their inability to predictably deliver, the team’s morale started to drop, affecting their productivity. In the end, we split the team, with half seated in an isolated location, focusing on the new features and the other half supporting and evolving what already worked.
Scrum can improve your team’s productivity. They need to take the time to think about what they need to do, pay attention to how their time is spent, learn from their successes and failures and be realistic about their commitments. Also, having a couple of babies on the way doesn’t hurt either!