Top 10 Blogs of 2015 : Measuring performance in Scrum teams is an act of sabotage!

Dec 28, 2015

Sogeti Labs

Here’s this years Blog No. 3!

This blog was originally published on 19th March 2015.

Lately, I’ve been asked a lot of questions by managers and teams alike about the organizational need to measure performance of Scrum teams. Of course, most people refer to the Development team within the Scrum team… but that is where Scrum creates confusion.

The Product Owner and the Scrum Master, together with the Development team, form the Scrum team. The idea is to include all the roles in a nice package called Scrum. The Development team, however, is often called the ‘Team,’ because that is how the Product Owner and the Scrum Master address people who create the product.

Many of us realize that we don’t measure the time spent on the individual tasks within the Development team. We work with fancy units such as feature points, or complexity points, or story points (when using User Stories). The unit, however, does not matter as long as you realize it’s not the time spent. It is a relative value obtained by comparing the effort and complexity or a chunk of work with that of the rest of the work to be done.

What many do not realize is that these points we use are NOT productivity metrics. In fact, they are there only to aid the Product Owner and the Development team in their work. Reporting to the management about the amount of points burned down in a Sprint, only serves as an effort to ensure transparency (with the management), which is characteristic of Scrum.

The expectation that these points are metrics for productivity and that we can use them to push the team to a higher performance level is like measuring a company’s performance using the amount of people working for them. Why would we measure performance of a Development team based on velocity increase, function point analysis or the amount of coffee they drink, when (in reality) a company’s performance (usually) gets measured on the basis of the Return of Capital Employed, profit, turnover, etc.?

The main goal of a Scrum team is to increase the Return on Investment (ROI); the people who make this possible are the Scrum team’s developers. Pushing developers to the edge, by demanding a higher volume of output, leads to the following undesirable outcomes:

1. The team gets demotivated and/or overworked and the productivity decreases.
2. The number of errors the team makes increases; more bugs in the system results in more problems in operation.
3. The team cuts corners to get more work done under pressure and, consequently, technical debt increases, which in turn bogs the team down over time, while they refactor the code bit by bit.
4. It creates a rift between the Product Owner and the Development team. The Scrum team, as a whole, works to create value and increase ROI, but the Product Owner is responsible for the ROI; the Development team is responsible for the work done.
5. This anti-Agile behavior reduces the effectiveness of the Scrum framework, which is best when the Development team is empowered. In fact, self governing can achieve a sustainable pace.

The job of a Scrum Master is to help the team become better by facilitating their work and removing anything that keeps the team from going at the pace they want to. I personally believe that people in the Scrum team and the Development team WANT to work at a cutting-edge pace while creating the best possible product. Interfering with this will sabotage their dynamics and will achieve the opposite of what you force them to do.

Focus on measuring ROI of the product and you will be happier.

About the author

Sogeti Labs

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments