Scrum Masters are commonly asked questions by management like, How can I measure team productivity? or How can I compare productivity between teams? and How can I tell if a team is improving its productivity?
What these questions are really trying to drive towards is the satisfaction of the very reasonable managerial motivation: I love velocity and I want more of it!
The problem, as most Scrum Masters well know, is that implied in these questions is the erroneous belief that meaningful comparative measurements of team productivity are even possible.
In fact, metrics to measure the productivity of software developers have been sought after almost as often as NP-Hard solutions, and have about the same success rate. We also know that when we embark down this road we often doom the organization to the repercussions of the observer effect, the streetlight effect and other unintended behavior modifications.
However, in trying to explain this to our management we may inadvertently be giving them the impression that in an Agile environment productivity cannot be influenced. This is not true.
In order to demonstrate this, we must pivot ourselves from explaining why we can’t measure and compare productivity to showing management how they can influence productivity and respond to their underlying motivation, ”How can I get me some more of that Velocity?!”
Let me use a rowing analogy to illustrate this point. The questions from above basically take the form of How hard is the team rowing? Compared to another team? Compared to itself last year?
The problem with trying to answer these questions is that in a software engineering environment teams are never rowing right next to each other in identical boats, in identical conditions and with identical milestones to mark their progress.
In fact, many times teams are in vastly different parts of the ocean, some in sunny weather, others in storms. Some are using high powered racing shells, others are in bulky rowboats. Some are marking their progress with frequent buoys, others by their positions relative to the land around them.
Instead of trying to identify false productivity equivalencies to measure against, managers should instead be driving productivity gains by influencing and measuring the rowing environment itself, asking and answering questions around the following aspects:
Is the team pointed in the right direction? Velocity is meaningless without direction. We need to understand how much business and customer value the team is delivering each iteration, and how happy the consumers of that delivery are. These aspects can be measured through tracking business value assigned at an epic or initiative level, and by taking customer and stakeholder satisfaction surveys through-out the release life-cycle.
Does the team know effective rowing and teamwork techniques? Teams need technique and practice scaffolding to model before learning to modify to suit their needs and finally elevating as a craft. One of the best ways to influence this aspect initially is to provide training on a set of Agile Best practices and then to measure adoption through an Agile practice assessment on a regular basis. After adoption provide the space for and to promote engineering communities of practice to encourage shared craftsmanship.
Does the team have the boat it needs? The boat in my metaphor is the organizational support structure in which the team operates. The organization supports the team by communicating clear achievable objectives that align with the team’s intrinsic motivations, as well as providing the enablement to accomplish those objectives, and space to focus on them. In order to know how it’s doing the organization should be soliciting teams periodically to see how well they are supported.
Are there any weather conditions slowing the team down? Nothing kills velocity faster than impediments. We must understand how affected teams are by impediments and how well the organization is doing in removing them by tracking things like mean time to resolution weighted by the priority of the impediment.
Once an organization has addressed the environmental aspects from above I do believe there are a couple team performance measurement that are worth tracking:
Reliability: Number of delivered story points / Number of committed story points
Predictability: Standard deviation of delivered story points over the last three iterations
While measuring these aspects won’t influence the “more velocity!” motivation it will help keep this pressure from derailing an organization’s ability to plan, by prioritizing for teams the ability to meet their commitments and to stay within a reasonable variation of velocity from iteration to iteration.
With the optimal environment and predictable and reliable teams in place, productivity gains should be smooth sailing… Er, rowing.
- How Agile Software Development Produces Positive Outcomes
- So You Want SSDLC? Why Security Won’t Just Happen…
- 20 Critical Security Controls: Control 6 – Application Software Security
- So You Want to SSDLC: Overcoming Obstacles
P.S. Have you met John Powers, supernatural CISO?
Title image courtesy of ShutterStock