Agile Practice: How to Set Sustainable Pace in Agile Initiatives

What's far more important is having consistent, stable velocity while maintaining the quality of work.

With Agile gaining momentum, the techniques upon how to make it more successful also become a hot topic. For example, how to set a sustainable pace in Agile initiatives? Is Agile velocity more about business values (features) or line of code? Is it more about project effectiveness (doing the right thing) or  

more about team productivity? And how to continue improving the team’s capacity and capability?

Agile is about continuous improvement: You really don't want the teams to produce same results when they are capable of innovating and improving continuously in their work. In the initial sprints, teams tend to over-estimate and commit more than their capacity and under-deliver. After a couple of sprints, they become careful and start underestimating and over deliver - this gives a sense of feel good! And then, the teams start to stabilize and settle down with their outcome. This will start to vary when the team tries to bring in some kind of disruption to their work and try new things. Is is pretty healthy. If the team / developer could go fast at the beginning delivering values without the proper initiative of analyzing and planning, they will go slow and slower over time, and even need overtime works which might destroy overall productivity later.  

The team improves productivity via automation and stabilization: At initial stages of engagement, productivity is lower (even with overtime) because the team is getting familiar with the environment, knowing each other, and other foundational work. As time passes, team’s productivity increases and settles in a band. With further automation in manual tasks, team’s productivity increases. So instead of spending the overtime on doing more work, spend it on improving the way you work. If Scrum is a good fit and the people committed to it, a Scrum team should be clearly more productive one month after starting, and then teams will be more productive and stabilize to deliver maximum velocity (business value). To reach that state teams may spend a couple of sprints that are called as their sustainable pace.

Overtime increases velocity very little if at all. If any extra work needs doing then it's to discover why you think you need over time and change so you don't. Limited, short-term over time can result in limited, short-term velocity increase. Significant long-term over time can result in significantly increased velocity (delivered stories/points), with a corresponding reduction in quality, an increase in defects etc.Overtime is an indicator that the team is running over capacity and the target velocity needs to be reduced. Overtime and long hours by the team had an increase in defects. Overtime working is not suggestible for the long run to any team because the quality might degrade and teams won’t be happy. Teams want to be 'helpful' and will push themselves into an unsustainable pace, and unless this is addressed they will suffer burn-out, and become demoralized and lose confidence in their abilities. They will grow back again, but the time lost due to burnout and recovery is always greater than any time gained. The real purpose ofAgile velocity is not to measure productivity but to be able to have a number which signifies the CURRENT capability and capacity of the team so that near future releases can be planned or visualized.

In reality, the team’s productivity and effectiveness depend on the team maturity, technology, product knowledge/functionality, etc. A stable velocity can be created by a team committing under their predicted capacity as is commonly recommended and working only to that commitment. What's far more important is having consistent, stable velocity while maintaining the quality of work. Then you can establish a level of trust between yourself and stakeholders that you can deliver on what your promise.

Posted in: Agile