As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!

Let’s explore this discussion further in the context of last month’s (April, 2010)  Phoenix Scrum User’s Group meeting.

PhxSUG Meeting

We announced the meeting would be a participatory simulation of a Scrum project. About half of the people in attendance had never been to one of our meetings before and many of them were very new to Scrum. We were gratified that some came specifically to experience a Scrum simulation!

We started with a brief discussion of the Scrum framework, with it’s roles, cerimonies and artifacts. With that foundation set, we dove into the activity. The project was five Sprints of the Ball Point Game (PDF)

(Here is a video of the game in action. If you have not tried this game, I highly recommend it. If you watch the video, don’t say too much when you play the game the first time. Don’t give away the secrets too soon!)

All of the meeting attendees are one team. The goal, or “product,” of the team is to transfer as many balls as possible in the two minutes of a Sprint. Between each sprint, the team reviewed performance and planed the next sprint. We had great fun and the team successfully transported all but two of the balls on the last sprint!  We then did a bonus sprint with some “cheat codes” from me, the coach, to optimize the process.  We succeeded in getting all the balls through in the time allotted!

Debriefing

In our discussion after the game, we found some interesting points:

• Changing even small things between sprints effected performance of the team in bad or good ways.
• High communication was paramount.
• Keeping a rhythm of movement in the whole team was important.

There were several other things learned, one of them was around leadership.  As the team was first getting organized for the first sprint, there was some chaos. Lots of people talking, pointing and throwing out ideas. Suddenly one of the participants spoke up and began speaking authoritatively about how the job should be done. The team followed, with some discussion, and the first sprint began. So, suddenly the team had a leader. Not by assignment but by personal energy and willingness to step up.

Dynamic Leadership

During the first planning period between sprints something interesting changed. Another participant pointed out a weakness and suggested a change to cover it. The team followed this suggestion as the previous “lead” blended into the team to make way for a new leader. This passing of leadership continued from sprint to sprint with different individuals teaching the team their ideas about how to improve and others volunteering into key roles. It was natural that the “Team Lead” changed as the needs of the team changed in the quest to improve.

This is dynamic changing of team leadership also happens in a Scrum team. Depending on the goals of a particular sprint, the team may look to the database administrator to lead or the user interface designer. Story to story, sprint to sprint the expertise needed by the “Team Lead” can alter. A team working well allows the currently needed leader to come to the front, and then fall back in favor of a new leader who has the talent or experience to handle the next focus.

When a team has an assigned Team Lead, this leadership adaptation is less likely to happen. Team members will not want to “attack” the assigned lead’s authority by stepping up. The team lead may not want to reveal “weakness” in a knowledge area and so will not allow another team member authority. Once a hierarchy is established, especially when established by higher authorities, it is very hard for those within the structure to alter their expectation of command and allow a better leadership pattern to emerge when needed.

In short, assigning a Team Lead and expecting that person to be appropriate in the role for the entire project is a form of “Big Design Up Front.” There are great Team Leads and managers that know how to foster leadership from team members. I am not denying that such excellence is possible. I am saying that such people are rare and anyone in that position must constantly push and pull against the cultural expectation that they are Lead and therefore must have the answers.

And The Team Shall Lead Themselves

Let the Team be the team lead. Then, the right leader will emerge at the right time as the team naturally strives to accomplish their work. I’ve seen it happen, just as it did the night we were throwing balls around, learning while laughing!

One team I’m coaching had members with varying degrees of concern about estimating in story points.  The team had difficulty embracing story points instead of units of time because units of time matched their past experience.  We defined “ideal days” for estimation purposes.  An Ideal Day for our team was defined as 6 productive hours in an 8-hour workday.  The team would define a task for a specific team member who would estimate its work in ideal days.  They could determine how many features to include in a sprint by adding up the estimated ideal days against the length of the sprint.

This approach was pretty good:  The team was able to start using Scrum, plan sprints, use a task board and make serious progress.  Those are big benefits!

Some sprints later we began to notice some negative effects to this approach:

• We were still using time as the basis for estimates even though humans are better at relative size estimates.
• We were writing each tasks with a single, specific person in mind.  This contributed to a perpetuation of engineers going off in a corner to do “their piece” alone.
• To some extent, the tasks, and the availability of specific people to do them, were driving the order of the features implemented, instead of value driving the priorities.

Last retrospective the team pointed out that we were not meeting our goals.  We determined that part of this was the desire to make sure all the ideal days were booked with tasks for every team member.  This caused the focus of our tasks to be far too broad.  We noted many times where someone in the Daily Scrum would report an impediment because some other person had not completed their task.  The words “tracking dependencies” and “critical path” even came up!

In the time between the retrospective and the sprint planning meeting, I conferred with a colleague ScrumMaster about the retrospective.  He drew a one sprint long, mini Gantt chart (Gasp!) on the board showing the separate tasks for one hypothetical feature.   We could see that many times integration of individual’s pieces does not happen till late in the sprint, sometimes too late to expect it to work.  We realized that the focus on tasks was completely de-emphasizing delivery of the stories by the whole team.

Thirty minutes later we began the sprint planning meeting with the following proposed shift in the team’s work agreement:

• Don’t explicitly estimate individual tasks except when needed to clarify them further.
• Don’t explicitly assign a person to individual tasks.
• Do use stories that can be completed within the sprint.
• Do estimate the stories by difficulty, size, risk, etc. relative to each other using story points.
• Do have team members self-assign to each story so they will work together to get that story done.
• Do continue to work on the assigned story even if “your part” is done.
• Do support other stories in the sprint if you have time available.
• Do add or remove tasks as needed to get the story complete by the end of the sprint.
• Do track sprint progress on the burndown chart using the story points of completed stories.

We originally started this team by focusing on estimated tasks.  This got us going in the right direction but, after several sprints, helped push us into old ways.  Separate people waiting on each other is not a team.  Now we have a story focus with the understanding that the tasks are only important as long as the story gets done.

Work the story, not the tasks!  We’ll see how it works for us.  If the team board looks like this at the end of the sprint, it’ll be a success.

http://www.flickr.com/photos/dinomite/ / CC BY-SA 2.0

(I have been looking around the web while thinking and writing about this blog post.  Seems some teams and well known agile leaders don’t agree about estimating only tasks or only stories or both.  For example, Mike Cohn recommends story points for release and backlog planning but time on tasks for sprint planning.  Well, inspect and adapt is the agile way.  We tried only estimating time on tasks for a while and think we don’t like it.  This switch to story points may be what we need.  Or we’ll adapt again later.)