The Four Pillars of Agile Adoption

them write better agile unit tests, that could improve velocity in a sustainable way. So could having a good team workspace. Each idea has to pass the sustainability test—if you could do it indefinitely then it's a valid way to influence velocity.

A very common mistake is to try to drive velocity directly, through pressure.

Diagnosis of Comet's Work Stream Problem
Comet team's velocity eventually started decreasing. When more coding is done on top of quick fixes, the code base quickly becomes brittle, and very hard to work with. Changes produce new bugs and they take time to fix, hence a slower speed. An increasing bug rate tempts people to do even more quick fixes leading to a downward spiral.

In frustration over the developing problems, Comet's managers reacted by pressuring the team to get more work done. Direct pressure cannot solve this–it intensifies the problems. The team responded by overly-optimistic "commitments", and by refusing to devote any time to helping each other with tasks. Undoubtedly, that further slowed their progress.

The team could not, in a short period of time, clean all bugs out of the legacy code. It was not within their control to do that; it was part of the landscape they had to cope with. They also could not quickly cover all the legacy code with agile unit tests. It had been agreed that this would be done incrementally along with creating new code. Deming said in his Fourteen Points for Management "the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force", and that applies perfectly here.

In this instance, managers needed to recognise that the velocity was slowing because the group had decided to go with using quick fixes, and they were not taking the time to clean these out of the code. The question technical managers needed to ask is "why are we using an unsustainable technique to keep code production going at this rate?" Was the team simply bowing to inappropriate pressure to keep velocity up? That's the surest way into trouble. Or did the team really believe the quick fixes would be harmless? If so then they should have seen that wasn't the case and reversed course. Retrospectives provide a good way for managers to gain early insight into issues like these before they are compounded.

Lessons Learned for Keeping Team's Work Stream Healthy
Agile teams should receive their priorities through the product owner, and no one else. Sometimes standards groups, regulatory representatives, or others expect to direct team activities. They are stakeholders in the team's outputs and should work through the product owner. When a team has too many bosses they are set up to fail. Note that the product owner does not assign tasks to other team members. The product owner collaborates with them and is an information resource for them.

Pressure on a team to make optimistic estimates is often non-verbal, and it may come from many sources. Teams want to deliver, and when they err it is always on the optimistic side. It doesn't take very much pressure to move them onto shaky ground. Learning to push back in an appropriate way is one of the last skills agile teams acquire, so new agile teams are especially vulnerable to this mistake.

Wise managers will watch for times when a team commits to do much more work than they usually accomplish, and they will ensure that the team know they'll be supported if they need to push back on demands made of them. A