Don't let sustainable pace stop you from further improvements

The classical XP/Agile view of velocity relies on a graph which indicates that the velocity of a team stabilizes over Iterations as the team goes through the cycle of Forming,Storming,Norming and Performing It is also an indicator of team achieving sustainable pace.

A lot of Agile project managers/coaches/leads fall into the trap of sustainable pace, and stop thinking about ways to improve efficiency, one the velocity graph shows signs of stabilization. This also gets complemented by the fact that customers are reasonably happy with the velocity the team is currently achieving.

This often stops Agile practitioners from innovating and coming up with even better means to increase throughput of the team.

As an example, imagine a team merrily churning 20 points of stories in an Iteration on an average and the customers are quite happy with the progress. The team probably has an average build time of 20 mins with SVN as a source control, and most often, if this team is in this happy rhythm , it wont bother about the build time, even though there is scope for improvement there. In my previous project, we moved from SVN to GIT as a source control and it reduced our build time by 70% approx. If someone started doing this in the imaginary team with a velocity of 20 points, they can surely speedup by 5 points atleast, considering the huge number of continuous builds in a day.

Another example which I see quite often is teams getting stuck on to sweet release schedules and not striving to improve further. Sometimes a team starts of with a 6 month release cycle, takes a lot of pain and then moves to a 3 month release cycle. When moving to a 3 month cycle this team, tries to improve their processes quite a bit which can involve things like bumping up the functional test suite coverage to 80%, reducing build times etc... But very soon, the 3 month cycle becomes a sweet spot, if the customer is not demanding any further. The point here is not to reduce the release cycle even further, but do more of the optimizations you did to the build times and functional tests and maybe even more things, which will continue to cut down waste. Unfortunately once the sustainable pace is achieved, inherently the motivation to think out of the box to reduce waste goes away.

There is always scope for improvement in a team. Agile practitioners/leads should always have the hunger to make their team better. Think of building teams iteratively. The Forming, Storming, Norming model itself is an iteration at each stage where the team is getting better. But dont stop at performing. Always be hungry for more and don't stop yourself at sustainable pace.