Is Velocity All There Is? – What are Your Agile Objectives?
We’ve given many workshops and webinars on Agile Metrics and how to connect your agile objectives to measure and improve the agile process. In Rex Black’s talk on “Stupid Metrics Tricks” in 2016 at the Pacific Northwest Software Quality Conference, he discussed some of the ways people manipulate and use metrics for their own personal gain, how to that, and how to use them in a productive way.
We’ve written several papers on what metrics can be used for the agile process, many of them not defect focused. The important thing to remember is that when developing your agile objectives, velocity can be one objective but needs to be balanced with others. And we all need to recognize that it is a derived or downstream objective. This means that meeting other objectives will lead either to higher or lower velocity. Thinking about velocity by itself is like only getting on the weight scale once every two weeks for your sprint without measuring and thinking about all the other things you must do to have a good weigh-in. What other things must you think about and measure before you get on the scale at the end of the 2-week sprint. Here are a few things.
- Manual Testing: Some think that manual testing will go away, but humans will always be needed. It’s just a matter of where and when. Too much manual testing can only occur if you’re testing the wrong things and not focusing on the right things. That begs the question of what is right and what is wrong. Things that can be automated, automate. If it can’t be, think about why and what can be done to augment rather than substitute. It’s not a perfect world, maybe you can use automation for part of a manual process. In the end, you may want to measure how much time is spent testing new features, functions and stories versus all other work. A simple ratio.
- Test Environment – Test Lab: When your test environment is not ready, obviously this blocks or slows down testing. What measurements can you use to depict your lab readiness? Or your ability to switch or bring up certain environments or versions of your software with certain data to verify a defect or replicate a situation?
- Feedback: When you don’t get feedback or get feedback late from the product owner, this obviously holds you back and you could possibly make mistakes (unknowingly) because you don’t understand some feature clearly. What measurement can you use to measure the timing on getting a feature clarified?
- Non Functional Testing: Performance and security testing are often an afterthought. But when you roll out your final version, and these types of tests take up an inordinate amount of time, obviously this holds you back and decreases velocity. Performance testing and security testing not done is a component of technical debt that in the end slows you down.
- Defects: Finding them takes time, but wasting time on duplicating them and not being able to reproduce for some reason or another is a terrible time waster and obviously detracts from velocity.
As you can see, matching your agile objectives with activities that have metrics leading to improvement is all you really need. Don’t focus on velocity by itself. Focus on your stride length and cadence, and you’ll run faster naturally. Or you can focus on minimizing negative attributes that implicitly will cause you to fun more efficiently and faster.