Agile Team Velocity

team velocity shall not be the goal, the real business goal is how to improve project quality, manageability via well-tuning team capability & capacity, effectiveness & efficiency.  

With Agile gaining momentum, the techniques upon how to make it more successful also become hot topic.Velocity is an indicator where you may need to do something; the options like adding people, team building or to take other actions. So does a high performing agile team always have high velocity?

Team effectiveness: The focus is handling unavoidable distractions that affect the team velocity. First, the assumption is these "distractions" are important to the company, that is, addressing them has value. In that case, they should count towards the team's velocity. If they are not important to the company, they don't add value, why is the team spending time on these distractions? Try to push back if the time spent by the team is not adding value to the company. Otherwise, it is perhaps useful to dedicate a particular part for the day or a particular day of the week towards addressing these "distractions". If the time spent can be planned, the distraction will be minimized.  Focus on measuring team effectiveness, as there is some power in individuals but there is HUGE power in teams.Creating the focus on measuring individuals is counter productive to creating a team that want to share knowledge, want to pair program and want to bend over backwards to help their peer come up to speed.

Team capability & capacity: The real purpose of velocity is not to measure productivity but to be able to have a number which signify the CURRENT capability and capacity of team so that near future releases can be planned or visualized. The velocity of the team will not remain same forever and may go up and down which may not help visualize farther releases. The point is how to improve team capability & capacity:

-Have a team with all the required skills for the project.
-Manage and resolve external dependencies in an organized way.
-Resolve impediments in an efficient way.
-Avoid any tasks that hinder the team to perform sprint tasks.
-Retrospective is an important ceremony to understand what is stopping the team from doing the tasks.

Eliminate Waste. Waste is basically anything that doesn't directly contribute to user value. The activities aren't absolutely necessary to decide an implementation issue, that include team members who can't contribute, time wasted on waiting for somebody else to finish something; time wasted on waiting for an approval, time wasted on coming up to speed on an overly-complex technology when a simpler one would do, time wasted on doing up-front design that will have to change, time wasted on writing reports that could be delivered verbally, time wasted on meetings which are not running effectively, time wasted on waiting for input from the customer because there is no one on site.

Quality: What's far more important is having consistent, stable velocity while maintaining quality of work. Then you can establish a level of trust between yourself and stakeholders that you can deliver on what your promise. In fact, velocity should not be a goal at all. As a team improves their practices, some will cause velocity to go up and some will cause velocity to go down. Improved engineering practices will cause it to go up as the team spends less time on rework and less time on the debugger. Improved story skills may cause it to go down or seem to stabilize as the team creates smaller stories and do a better job of isolating their uncertainty. A stable velocity can also be created by a team committing under their predicted capacity as is commonly recommended and working only to that commitment.

 

Well alignment of skills, tools and processes. Avoid the situation where the business only wants to increase velocity, and people just put more stories in, have their team "push harder" and work overtime. This may at least temporarily increase velocity. Long term however, people will get burned out. People will rush to finish things, sacrificing quality. This will hurt your velocity due to bugs, missed requirements, poorly written code and unhappy, stressed developers. It is more important to well align the skills, tools and process to achieve Agile team effectiveness:

1). Keep the scrum team same. Avoid attrition.
2). Have a good mix of the technologies that you need for getting the work done, among the team members.
3). Ensure team estimates right and makes right and realistic commitments..
4). You can catch stories with impediments right at the beginning and move them away or not take them into the sprint at all.
5). Choose the 'right' user stories for the sprint backlog 

Therefore, team velocity shall not be the goal, the real business goal is how to improve project quality, manageability via well-tuning team capability & capacity, effectiveness & efficiency.

Posted in: Agile