Measuring agile team performance: a management perspective

How many sprints do you need to measure team performance?

Effective process refinement is the key aspect of any agile project. Process refinement makes requirements clear to the whole development team and allows their complexity to be estimated. However, before you can measure team velocity, you need to run a certain number of sprints to get your first performance results. More often than not, describing your team as effective after just one sprint may turn out to be a complete miss.

So, how many sprints do you actually need? Usually, three or four are enough, as long as you work with a full team. Based on a dataset of this size, you can extract the average number of tasks that your team is able to pull off over a given period, barring, of course, any emergencies or external circumstances (such as the holiday season or any unplanned absences) or situations when, apart from software development, you have also planned for deployment and stabilisation periods.

Of course, you need to remember that if you make large changes to the structure of your development team, you’ll also have to recalibrate everything else.

Measuring agile team performance: threats and opportunities

Thanks to the agile framework, your teams can work at a fast pace and promptly react to any changes as they arise. “Fast pace”, however, is a relative term; measurements are there to help you get a concrete insight into how effective your team really is. It is a valuable tool that lets you plan out the entire software development process much better. As a result, our team will get a better idea of how much time it needs to deliver the product in the pipeline. Let me emphasise: collecting metrics is not meant to be a measure targeted against anyone and it shouldn’t be repressive.

Another advantage of performance measurement is that it allows you to better manage your development team potential and ensure a comfortable work environment. Thanks to measurement, you can plan out the optimal workload that won’t put too much strain on your team which, in the long run, could have negative effects on team morale.

The role of manager vs the need for control

One of the hardest (and the thorniest) challenges faced by leaders in any organisation where results are based on knowledge is their own need to sustain the illusion of control. This can take on such advanced forms that managers will start to ignore any actual scientific evidence on motivation, engagement or work performance.

In Capital in the Twenty-First Century, Thomas Piketty warns that the share of individual input in business outcomes is difficult to measure objectively. This is because tasks are becoming increasingly complex and require the cooperation of many specialists from different disciplines in a joint effort to achieve the final outcome.

It may seem obvious, but to get things done, many managers still choose methods that may have worked well back in the day when the conveyor belt was first introduced (where you could, for instance, directly measure the number of bolts screwed on per unit of time). Today, unfortunately, all these methods do is cause confusion, if not contribute to different organisational pathologies. 

Performance measurement: basic ideas

In the context of intellectual work, performance and its measurement require a change of paradigm; You need to accept a few basic ideas. Firstly, the personal performance of an individual is not linear and may be influenced by a great number of factors. Importantly, most are completely beyond your control.

Data that employee A has completed X tasks over the past quarter cannot be used to predict their performance in the next quarter. All it takes is that they welcome a child into their family, or a parent comes down with a chronic illness and your predictions will go out the window. And even if you can predict such situations, you still can’t determine their exact impact on performance. The same event can cause performance to drop for employee A and increase for employee B.

Performance as team effort

Another fact is that, today, intellectual work is a synergy of individual efforts within a team and (as we said before) there is no clear-cut way to estimate their share in the outcome.

In the end, the team will complete the task effectively or will ineffectively fail to do so. As the project is wrapped up, the client won’t be interested in how effectively the team worked on a task that ended in failure. From their perspective, what matters is whether their business needs were met and whether they can start using the software as planned. If the answer is no, they won’t get the expected financial outcomes and will consider the whole project as undelivered.

As such, performance measurement should focus on team performance but also (and above all) cover factors such as:

• client satisfaction;
• margins;
• employee satisfaction (yes, it has an immense impact on performance).

Team performance: to measure or not to measure?

With the above in mind, perhaps you would do better to scrap performance measurement completely?

Absolutely not! Performance measurement provides very important information, especially for the development team. When the team learns their potential, they have a clear point of reference for any self-improvement efforts. Then, the role of the manager is to stimulate their drive to become a better team every day.

Also, such data also matters for teams responsible for product management. While individual performance is highly chaotic, teamwork tends to largely level out any unpredictable deviations and allows reliable predictions for the future to be made (and team velocity is a relatively good predictor). For this to be possible, however, the management need to make a lot of (often deep-reaching) changes in the way they look at the production process and change from controllers to leaders and inspirers.

Taking care of the performance of teams, or individual roles within the team, is a key aspect of project management. And even though effectiveness should be our goal, we shouldn’t try to exceed it every time and at any cost. This can deal a serious blow to product quality and exhaust your team.