One of the worst mistakes software executives make in product development is pushing to maximize velocity.
They equate minimizing time to value with going faster, when, in reality, going faster than the team is built to go tends to elongate time to value. (Minimizing time to value is more about releasing early and often).
Velocity is a measure of throughput – the amount of material passing through the system. When executives try to push more software development through the team than it was built to handle, they break the system. It’s similar to sprinting the second mile of a marathon. Your body breaks down and you’re not able to finish the race.
It’s also like putting too much garbage in the garbage disposal. You might clog the drain or overheat the engine. If you push the limits, bad things happen.
Optimal velocity is not maximum velocity. The measure of a healthy software development team is the ability to maintain a relatively consistent velocity each and every iteration. You may be able to push the team to get more done, but, it will be difficult to sustain the pace. Going too fast results in low quality and waste.
Shortcuts, escape defects, regression failures and security flaws are all introduced when a team tries to go too fast. Each of these cause waste – the need for rework. Ultimately, going too fast leads to missed deadlines, poor quality and frustrated executives.
Reaching optimal velocity tends to happen naturally. A well built, well meaning, agile team will reach optimal velocity on either it’s third or forth software development iteration.
If you truly suspect that your team is not reaching it’s full potential, look for inconsistent velocity. If you can not reasonably predict what your team will produce in a two week period of time, something is going wrong. Sometimes this is a sign of being pushed to produce too much. Other times there is a more fundamental flaw in the system. The most common culprits are (a) poor story writing, (b) an absence of process discipline (most commonly around the definition of done) and (c) a lack of test automation.
If your team produces consistent velocity but you suspect it should be able to produce more, begin dividing the story backlog for a single iteration into three categories – must have, should have and could have. Define enough must haves to equal 20% less than the team’s typical velocity, the should haves to equal 20% of the team’s typical velocity and the could have’s to equal another 20% of the team’s typical velocity. Without adding any pressure to do more or setting an expectation that all of the stories will be completed, watch the results and repeat for three iterations.
– As a general rule, a lazy or ill-managed team will underperform for all or 2 out of the 3 iterations. They will only reliably complete the must haves.
– A team already working at their optimal velocity will continue to hit their benchmark. They will reliably complete the must haves and the vast majority of should haves in each iteration. In one or two iterations they may complete a small percentage of could haves.
– An underperforming, but, well intentioned and well managed, team will either increase their velocity without an increase in escape defects or taking shortcuts or, you will begin to hear from team leaders (not necessarily the manager, but, the high performers and influencers on the team) about why they can not complete more.
If, after this experiment, you are not satisfied with your results, it’s possible that your team is simply not built to produce the output you expect. This may be due to its lack of experience, lack of competency, a fundamental flaw in execution, or, simply a mismatch of expectations.
But, regardless of the cause, simply demanding more is counter productive. Realize that pushing the team harder without fixing the root cause will slow you down and create waste. If you’re convinced the team is suboptimal, hire an expert to take a look and diagnose the problem. Don’t just pound your fist and hope for the best.