Archive for April, 2011

Do you understand your “Velocity”?

April 23, 2011

Velocity is a metric that is used in agile projects to represent how fast a team is building the software.  Velocity is number of story points (or what ever the unit of estimation is) finished in an iteration.  I have seen some managers using this metric in ways that is not intended for. I am going to take a crack at explaining what it should be or shouldn’t be used for.

What does Velocity represent?

Before you know what velocity should be used for, you need to understand what exactly it is. I think it is lot more loaded than it appears to be. One should know deeper about velocity to use it properly.  Velocity in a single iteration doesn’t mean much, whereas an average velocity over several iterations could answer few questions. For example, if a team’s average velocity is 10, it means that the team is likely to finish rest of the development work of that release or project or chunk of work at that velocity.  The reason I said it is “likely” because there are several factors that could make this statement wrong. It is critical for the team to understand these factors so that they make right decisions.

Team’s knowledge of the domain

The team with the higher knowledge in the domain would build the software faster.  If the project is brand new and the team that is going to work on the project doesn’t have much knowledge about that domain, the velocity would be less. Velocity will improve as the team is learning more about the domain. On the other hand if the features are enhancement to the existing system, the team probably is more familiar with the system and will have higher velocity. In either way the average velocity could be established after few iterations.

Team’s technical skill level

Team’s technical expertise plays a vital role in how fast they can build the software. This is not only the knowledge about technology and tools being used, also the architecture of the system being worked on. This would have the similar effect as we discussed above.

Clarity of requirements for the stories

If the stories are well defined, the team will have less impediments and the work will be done faster. Lot of time requirements aren’t clear at the time of estimation as well as some times at the time of building also. Team needs to work through the unknowns and resolve them on a daily basis. This will slow down the process and will reduce the velocity.  It is important to solidify the requirements before the start of the iteration for the team to maintain the velocity.

Changes to team composition

This question arises very often that what happens to the velocity if we added a member to the team. Is it going to go up right away? I don’t think so. When a new member is added, it is likely that the velocity will go down first. This is because the current team members need to train the new member. It will eventually go up. It is hard to say how many points it will go up by. It depends several factors. This includes the experience level and attitude of the new member. Since agile teams are collaborative, each member would have an impact on the whole team. For example, the new member could be a leader and inspire every one in several ways. This will have a positive effect on the team. On the other hand the new member could be a whiner and cause head ache to the whole team in which case the velocity is likely to go down.

Support activities team performs.

If team is engaged with support activities like productions tickets and fixing bugs, their velocity of developing software will go down. If these supporting activities are not controlled, eventually the velocity will go down significantly.  As the team is building more code, it could increase the supporting activities also. This could be because of cutting corners while developing new features or improper implementation of the features themselves. It is critical to identify this (Technical Debt) and correct it as soon as possible. Read my blog post on Technical Debt.

Corporate culture

Corporate culture is a big factor in the team velocity. This includes the processes, policies etc. If the team has to work in a tightly controlled framework, the value added tasks would be less and hence the velocity will go down. So, the team’s velocity is the points per iteration in that corporate culture. Everything else being the same, if the same team is working in a different corporate culture could increase or decrease the velocity. The organization needs to understand this and change the culture such a way that it fosters agility across the organization.

The velocity of a team represents its productivity considering all the factors talked above.

What should you use velocity for?

In general, the team should watch and learn from the velocity.  Velocity should only be used for planning purposes. Completion of a project could be predicted if the team’s long-term average velocity is known. However , this prediction would be more accurate if the factors affecting the velocity stay relatively stable.

What shouldn’t you use velocity for?

Team member velocity shouldn’t be calculated from the team’s velocity.

In a true agile team, more than one member work on a story. A developer, tester, possibly a DBA and a SysAdmin spend their time to complete the story. It would be inaccurate to try to compute an individual member’s velocity.

Velocity shouldn’t be used for performance reviews.

If velocity is part of the performance evaluation process, that could lead to inflated estimates by the team. Team performance should be evaluated using some other means like peer review or 360 degrees review.

Don’t expect team to have the average velocity in every sprint.

Product owners need to understand that the average velocity is not guaranteed in each and every sprint. If the team’s average velocity is 10 points, they shouldn’t wait to plan mandatory 10 points in the iteration. Features should be planned well ahead of their required delivery date.

Past velocity can’t be used as basis if the context changed.

If the teams velocity can’t be used as basis if one of the factors discussed above changed. For example a team’s velocity in one project can’t be used as basis for a different project unless same team is working on the new project and they have same level of knowledge about the new project.


True Collaboration!

April 9, 2011

Last week we had an issue in production. One of the reports was hitting the servers pretty hard. Our “Production support monkey” (all developers rotate this job every sprint) mentioned the problem in the standup meeting.

“The problem is that this report could be run for any date range and taking lot of time. Mean while user is clicking on the submit button multiple time that caused several instance of the report running.”

Soon after the standup meeting was over, engineering manager sent out an email with details of his research on who requested the report and how many times it was requested etc. This email went to whole engineering department.

DBA did some performance tuning to database and sent out an email with the test results of his change.

System administrator sent an email offering a shell scripting solution to monitor multiple running instance of the report and alert if they are running for too long.

Developers already thinking of couple of simple fixes to avoid user clicking multiple times. Team has all the knowledge and working on a integrated solution.

Points to note:

1.     Every one knows about the problem. This was automatic since everyone comes to standup meeting as well as everyone gets the emails.

2.     No one assigned any task to anyone. Everyone shared the responsibility and offered a solution from their side.

That’s what I call “True Collaboration”!

Self-Organization makes ‘Agile teams’ more agile!

April 5, 2011

We talk about self-organization is one of the most important aspect of agile teams. But what is self-organization and how does that happen? Is it easy or hard to self-organize? I get lot of questions like this from teams.

What is self-organization?

A self-organizing system reorganizes itself based on the external stimulation. There could be several possible arrangements when they reorganize. Number of possibilities is limited by the constraints added to the system.  Some of the characteristics of a self-organizing team are:

  1. Team is conveyed what needs to be done. Team understands the vision for the work that needs to be done as a whole, not just the work associated with one member.
  2. Team is empowered to make decisions on how to best perform the task. However, the “Power comes with responsibility”. Team members understand the rules of the team and stick with it.
  3. Team quickly reacts to any unexpected events. This could be change in requirements or change in the team itself, like some one in the team leaving the company.
  4. Leader of the team adds or removes constraints to the team to stimulate it arrange in an optimal way.

Probably, a lot of people are wondering how to transform their team, which has been operating in a command-and-control mode, into a self-organizing team?


I did an exercise in one the local agile meet ups with around 25 people. I made everyone to stand in rows and columns at an arms length. This is the initial setup. I asked every one to chose two people from the group. They are not necessarily their neighbors.

When I say start, they have to move to a position, which is equidistant from the two people they chose. They have to keep moving since the two people they chose also keep moving. So, every one keeps moving until every one reach a position that satisfies the requirement of standing at the same distance from the two they chose. This depicts a self-organizing team, which reacted to a given requirement.


The result was not so perfect, but they got the idea. Every one who participated tried to adjust them to meet the requirement. I noticed couple of issues here. People got too close to each other and started step on each other’s toes and some people made sudden and big moves, which caused the whole group to reorganize again.

This tells me that we can’t just have a group of people together and expect them to self organize. The team members need to be mature enough to self-organize. They need to understand the whole team well.

What would happen if I assigned a manager to the group and ask him to give command to each and every person where to stand. That would take forever for the manager to finish the work. Also, the out come would depend on how good the manager is rather than how good the people in the team are. If we added more requirements, the complexity probably increases exponentially for the manager to finish the task.

Have a good leader:

Before you have a self-organizing team, you need to have a good leader to groom one. Managers need to develop good leadership skills and understand the dynamics of performing teams. Managers need to let the control go and spend the time in more value-added tasks. They need to trust the team members on what ever they are hired for.

Groom a team:

A leader needs to take the team through the classic team building phases of “Forming-Norming-Storming-Performing”.  As the team is in forming phase, the leader needs to encourage the team members on team dynamics like:


Communication between the members of a team is the most important aspect of self-organizing team. The leader of the team should encourage the practices that encourage communication. Some of the agile practices like planning poker for estimation, all planning activities, pair programming, daily stand up meetings help increase the communication among the team members.


Every member of the team needs to establish their credibility so that the rest of the team would have confidence in them. For example, if I know that my architect is credible with his designs, I won’t think twice to go ahead and implement them.

Understand and respect individual’s values:

Every member of the team would have some values. Team needs to identify those values and respect them. If my highest value is punctuality, I wouldn’t expect any one question if I am working 8 hours or not. One thing I did was that I asked every one on my team to identify their top two values. Then I published those to whole company. Now that every one known team members’ values, team members try to stick to it as well as others will think twice before they question the team members on those values.

What’s next? We got a self-organizing team. Do we need the managers anymore? I get this question all the time that if we have a self-organizing team, should we fire all our managers? It is a big misconception. Yes, we need leaders not only to groom a self-organizing team, also to sustain. Read Mike Cohn’s blog to know why a self-organizing teams need managers.

The team I work with is a highly matured and self-organizing team and requires very little supervision.  The team continued to perform normally when the manager was on vacation for a week as well as only DBA on the team left the company. In the later case, one of the members who had the most knowledge about the databases took over the charge. Things got slowed down little bit, but the team responded well for the situation. When one of the two testers was gone on vacation for half of the iteration, developers helped with testing.