I was asked a couple of interesting and understandable questions by some colleagues today.
“How do you measure the productivity of your development team?”
and
“Can you benchmark them against other teams in the industry to measure how they are performing?”
The answer to the second question was quite easy. A comparison would offer little value or any meaningful data as you wouldn’t be comparing like for like. If somehow both teams were building exactly the same product, in the same environment, with the same Product Owner, you could compare the quality of their end product, the number of bugs, the release times etc.
The reality is, development teams, are usually building new things, in different environments with an ever-changing backlog of priorities.
You’d be comparing apples with oranges.
Measuring productivity
The second question was harder to answer when put on the spot and I have been reflecting on it.
Firstly let’s look at the definition of what being productive means:
Productive (noun) the state or quality of being productive.
“the long-term productivity of land” the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.
“workers have boosted productivity by 30 percent”
So by definition productivity can be described as the volume of output. Traditional industrial age thinking is based around “more = better”.
For example, in factory terms, the more widgets produced the more products you have to sell. So if we make the factory workers work harder (ie be more productive) they produce more output and we make more profit.
The problem with this thinking in the digital space is more doesn’t often equal better. Also, Developers aren’t factory line workers tasked with creating volume, they are tasked with solving problems.
The Red team and the Blue team
Take two Agile development teams working in two-week sprint cycles. We’ll call them the Red team and the Blue team. Each team are working on different e-commerce websites for the same company.
- The Red team have committed to taking on six new product features in this sprint.
- The Blue team have committed to taking on three, as the features are more complex than those being developed by the Red team.
At the end of the sprint, both teams launch the new features on their respective websites.
- The red team’s six new features result in a 10% increase in completed sales.
- However, the blue team’s three new features result in a 20% increase in completed sales.
Which team would you say has been the most productive?
- The red team because they created double the features (higher volume)?
or,
- the blue team that delivered half the output volume but resulted in double the business value?
You can see how measuring output in terms of volume is not an indicator of value to the business.
So how do I know they are productive?
OK so the question was asked to me as Product Owner, how do I know my team are as productive as they can be?
Here is the current situation with my team:
- The team have evolved from working individually on items, to working in pairs on items to working as a single mobbing team, one item at a time.
- As a result, the data we have over a 3 year period shows us the number of bugs we are adding to the backlog has gone from around 3-4 a fortnight to 1-2 every quarter. This means we have less “technical debt” to clean up, leaving more time free to produce features of value.
- Now we are mobbing on a single product, all team members are 100% familiar with what they are building which results in less discussion time and documentation being required, leaving more time free to produce features of value.
- The team are following best practices with test driven development, automating the deployment process and writing high-quality code, leaving more time free to produce features of value.
- They are working as one with 5 brains solving complex problems together, quicker than they could on their own, leaving more time free to produce features of value.
- As a result of the above, their morale is high, they are passionate about what they do and they come in every day with 100% focus on delivering features of value.
- They continually review progress each fortnight and discuss any things that would make them even more efficient, in order to ensure as much time as possible is free to produce features of value.
- The team have an ongoing log of all work completed which is written in a non-technical way, the log outlines in specific detail how value has been delivered.
Do you notice a theme here? (clue, it’s all about value, not volume)
What about team size?
Our team currently are made up of five developers. We used to have six. Does that mean the elusive productivity figure has dropped since reducing numbers? Could we drop down to four developers or three? What about doubling the team size, would that double productivity? All fair questions, but again this treats developers with the same industrial factory worker mindset.
Still not convinced? – how does the business know it is getting value for money?
The only thing effective Agile teams care about is delivering value to the customer and business. They also aim to do that every sprint cycle (in our case every fortnight).
How you measure that value (call it productivity if you like) is by looking at the outcomes of what they deliver e.g. customer’s satisfaction and increased sales, not how many widgets the team produced that fortnight.
What is getting in the way?
The other critical aspect to team productivity that deserves focus is what is getting in the way of the team being productive. By that, I mean what tasks and activities the team need to perform could be streamlined and automated and what blockers could be removed.
As described above, practices such as mobbing, test driven development and automating the deployment process, free as much of the development team’s time as possible to focus on producing features of value.
Don’t just take my word for it
For further reading on this subject, I highly recommend this great article that goes into this topic in more depth so you don’t just have to take my word for it. Interestingly it compares the problem of measuring the productivity of Doctors and Lawyers and explains how this presents similar challenges.
Posted in: Agile , Productivity