Live from Agile 2013
Great session this morning from @DocOnDev, the Director of Engineering at Groupon.
Velocity is units/time with direction. Many teams struggle to obtain a stable velocity. Velocity is a lagging indicator like unemployment, or the weather forecast. You don’t fix unemployment by focusing on that, you fix unemployment by fixing the economy. Doc’s talk explored an approach to helping teams improve, without encouraging them to increase their velocity.
At the end of the iteration you have velocity. A simple measure of a complex system. Adjusting velocity doesn’t mean we are a healthier team or company. We could still achieve velocity with a bad outcome (technical debt). While velocity can be a good long term predictor, it can be negative in the short term if teams focus is simply on increasing velocity for velocity’s sake. Also, do not compare one teams velocity to another.
Two examples: 10,11,9,10 and 7,14,6,10 (same team over time). In both cases the “tomorrow’s weather” approach gives you an estimate of 10. Same result with a rolling average. Both are misleading. Once you add standard deviation, and a confidence interval, to the “yesterday’s weather” and rolling average you get more accuracy.
Perhaps though, consistency is key. Managers should not ask teams to hit a target velocity.
Three Laws that influenced Doc:
- Hawthorn Effect – that which is measured will improve, at a cost…
- Goodharts Law – when a measure becomes a target it ceases to be a good measure.
- Friedmans thermostat. – correlation is not causation.
In order to deliver more points to meet the target the team will sacrifice quality, slowing the team down in the long term with technical debt. Deming recommended businesses focus on the system and how people are working together.
Agile Metrics
Get a different perspective on the team by exploring the following reports. You can still look at the Velocity Chart, just remember that there are other – sometimes better – metrics to look at for specific team issues.
Scatter diagrams
Plot velocity by cyclomatic complexity. The more complex the code gets the less the team can deliver in a given iteration. If we optimise for the long term (minimise technical debt) the team will be faster – this is the business case for paying off technical debt.
Positive correlation – as we have more code coverage, velocity goes up. At the unit level you have to write code that is easily testable, and the by product is low coupled code with low cyclomatic complexity. Doesn’t have the problems inherent when writing tests after writing the code.
Control Chart
Look at the lead time and cycle time for a team. Where does the team spend their time?
Cumulative Flow Diagram
Quickly identify the growth of the backlog over time, whether the team could get more impact by focusing on improving quality, minimising WIP, working with the product owner to write better stories, etc.
Team Happiness
Team joy may be a leading indicator in team performance. Doc’s experience at Groupon may have been clouded by the sampling rate (more frequent than sprint velocity). How do they measure this? By allowing engineers to submit a health metric as part of their commit message.
Knowing how the team feels about things allows us to identify what’s going on. One option for this is MoodApp.
Takeaways – Agile Metrics
Remember, metrics are not for managers, they are for teams to learn and explore how they can improve themselves. Don’t simply use the Velocity Chart, take advantage of what is available and explore all options.
Look at the Control Chart in JIRA to see your teams lead and cycle time. Look at the Cumulative Flow Diagram in JIRA to see the WIP and where your team is spending most of their time. And remember:
- that which is measured will improve, at a cost.
- when a measure becomes a target it ceases to be a good measure.
- correlation is not causation.
One final thought Doc shared: if you measure the time spent on a project you have an opportunity for capitalisation.
Find Agile Metrics slides on Slideshare.
Like this stuff? Follow @DocOnDev and react on Twitter:
Agile Metrics – Velocity is not the Goal http://t.co/juyvUuSdqo
— Nicholas Muldoon (@njm) August 6, 2013