Relay Race Team practice to improve performance

An agile team’s velocity is based on how the team sizes stories and how many stories and story points they commit to each sprint. Agile’s self organizing principals empower teams to make these decisions in exchange for their commitment to complete the stories and having “shippable code” at the end of every sprint.

But what happens when management needs the team to accelerate its delivery? What happens if there is a significant opportunity or critical deadline and management wants the team to take on more stories or story points in a sprint?

Here are a number of ways management can either help, or influence its teams when this is needed:

• Leverage Retrospectives – Retrospectives are part of most agile practices and give teams time to reflect on what worked well and what can be improved in the development practices or processes. I’d recommend management ask the team to consider a higher velocity as a discussion point during the retrospective. I’d also make it clear that the team should recommend steps that is under their control so that the exercise doesn’t dissolve to a list of out-of-team improvements.
• Increase Planning – I tell teams that they should target to have a backlog of two sprints of full defined stories, and an additional four sprints of story stubs estimated. If the product owner feels strong about the prioritization and definition of the backlog, it may help teams to dedicate blocks of time to get ahead of planning and target as much as four sprints of defined stories and an additional eight estimated. The added visibility gives teams the “big picture”, helps them see dependencies, and gives them more time to find easier solutions.
• Analyze Causes of Rework – All agile practices have a certain amount of rework in the form of changed requirements, poorly defined requirements, technical debt, defects, performance considerations and other sources. Teams should consider labeling stories (or tasks) based on the source of the rework, then consider measures that might reduce this work.
• Learn the Customer – The Product Owner has got the tough job of aggregating many inputs from different user segments, sales teams, customer care feedback, research, and usage data. Development teams can play a role by insuring Product Owners have better data and more technical insight to make smarter decisions on what capabilities (stories) are required and what priority to fulfill the customer need. It can also lead to better technical design. So for example, if a feature is required by top customers but is not heavily used, perhaps the performance criteria can be relaxed and lead to an easier to implement design. 
• Implement Smarter Solutions – Are teams leveraging existing code? Should a capability be developed as a service because it will have short term reuse, or should other capabilities take on deliberate technical debt? Are features too big, and will breaking them down, labeling them, and discussing with the Product Owner lead to lowering the priority on some of them? Are estimates challenged to help find better, more efficient solutions? In my experience, these disciplines can be overlooked by teams yet they can lead to better more efficient solutions.

You might argue that some of these steps don’t directly improve velocity but are in fact measures to consider multiple solutions or reduce scope. This is technically true, so if you take on some of these approaches you might not see a direct percent increase in team velocity, but you might see the team deliver more capabilities in the same time frame.