Faster. Faster, faster, faster! as David Byrne sings manically in “Air”.
In previous entries we saw how an XP team is doomed to be on a mad treadmill that spins ever faster: the team commits to delivering as much work as the previous release (the team’s velocity). They try to improve their velocity to deliver a little more than promised. If they succeed, their velocity has gone up and they commit to delivering that much in the next release. And they try to improve their velocity again… And on and on.
Does it ever stop? If they fail to deliver all the promised stories by the end of the release, their velocity is lowered: only finished and accepted stories are counted. Next iteration they commit to a little less work, which should give them some time to analyze what happened and try some improvements. If they planned by business value only the lowest value stories are not delivered; the value of the release will still be near the expected value.
In my experience, working faster or working more hours does not increase the number of stories that get accepted. On the contrary, it is the surest way to reduce your velocity.
Use Velocity to evaluate investments
How yo you increase velocity? By investing in working better:
- Writing unit tests to design better and to guard against regressions
- Refactoring code to make the design better and the code easier to change
- Pairing to spread knowledge, techniques and conventions
- Regular reflection in “Retrospectives” or “Kaizen events to review and improve the process, tools and techniques
- Holding reviews, either formally or by pairing to improve code quality and spread knowledge
- Writing automated acceptance and performance tests
- Involving customers in defining and testing the software
- Buying better tools (but only reliable, thoroughly tested technology, that serves your people and process)
- Harvesting usable code
- Go get some training, go to a seminar, go to a conference
- Do something fun, relax
- Perform an experiment, try out a wacky idea
- …
And how do you know you investment worked? Your velocity goes up. That’s one more reason to have short releases: you get quick feedback on whether your investment. If it doesn’t work, stop and try something else.
Micro-investements
Typical for agile methods is that they use micro-investments: make a small investment, see what the effect is, decide on your next investment. Unit testing, pairing, refactoring, acceptance testing… require some daily effort, some discipline. Regular retrospectives evaluate the results of the investements and decide where to invest next. Thus, if you make a “wrong” investment, you haven’t lost much effort and you at least gain some knowledge.
Another advantage of micro-investements is that they can be taken at a much lower level than major investments: many of the decisions above can be taken by individuals or the team itself, without having to go through formal investment procedures.
Of course, the danger with micro-investments and local improvements is that local optimizations worsen global performance unless you use a “whole system” approach like Systems Thinking, the Theory of Constraints or Lean Thinking.
Big investments
“Classical” approaches tend to go for larger investments, in more upfront (analysis, design, architecture) work, frameworks, product lines… in an effort to look at the whole system and to avoid rework. In my experience, as long as you don’t get it completely wrong at the start, you will get where you need to be, in a timely and cost-effective way by building in and using regular feedback.
There is one area where it’s not wise to invest too little: in determining the real needs of the users/customers. What is the real problem? What is the best way of solving the problem? Software typically is only a small part of the solution, if it’s part of the solution at all. What else do you need? Is there value to created? Does the expected value exceed the expected cost? What is the required investement? Is the return justified? These questions should be asked before the project starts, and throughout the project. That’s what the “Find high value/low cost stories” in the systems diagram is all about.
Remember:
- A system that is not used has no value
- The cheapest system is the one not built
The wish to improve Velocity must be motivated by a drive internal to the team. It can’t be mandated from the outside. If you try to push velocity up, you might achieve that at the expense of your real goal: creating more value.
Who’s satisfied by achieving a ‘repeatable’ process? The only process worth having is an optimizing one. We need people who always want to do better. Because better is more fun
