Tuesday, March 16, 2010

Are Velocity Goals Really a Good Thing?

So, some feedback from a colleague of mine (thanks DocOnDev!) got me thinking about whether or not establishing a velocity goal for your team is really a good thing. Seems like an honest enough goal for your team - you have a deadline and specific features to meet and you set an iterative velocity goal as such to meet said deadline and features to be delivered, being careful not to have the velocity goal exceed what your team can deliver.

But, in setting that velocity goal up for your team, are you really communicating to your team (even if you don't mean to) that ALL you care about is getting to that velocity goal? Perhaps your team is then taking short cuts or avoiding large refactoring efforts so that they can complete stories as quickly as possible, compromising quality?

Perhaps the answer to this question really lies within each member of the team you're working with. I know developers who would never compromise quality to meet a date, but then you have the opposite spectrum of developers who may hard code unit tests to always pass! DOH!

I guess the lesson here is to make sure that it's clear to your team that even though we have a velocity goal set, it's important to never compromise the quality of the code base or our own personal integrity to meet said velocity goal.

Perhaps it also depends on your specific project - maybe the most important thing for the organization you're working for IS the deadline and a velocity goal becomes an effective means of ensuring that the team meets that deadline.

What's your take on having velocity goals for your team? Is this a good or bad thing?

----

See comments to this posting for additional thoughts on this issue!

7 comments:

  1. Do not forget the original goal:
    Please the stakeholders -> provide value.

    Do they benefit from having velocity as a goal?
    Could velocity even be a goal?
    Velocity is never introduced as goal. The only thing velocity is good for is to help plan the scope of your next sprint. The goal of the sprint is of course providing the value that’s described in it’s (sprint)backlog.

    You should not communicate velocity as a goal and get rid of this idea as soon as humanly possible. Your hole team should want to provide your stakeholders with value, so they should want to implement the stories. You should allow your team to help spot hidden value, like important refactorings. Etc etc…

    Never manage by using measurements. It will backfire: http://www.joelonsoftware.com/news/20020715.html

    ** removed and reposted -> typo

    ReplyDelete
  2. Thanks for the comment Daniel - I remember reading that posting by Joel and know very well about the fallacies that can come with bonuses. After all, I'm currently working for ThoughtWorks - no bonuses here!

    Velocity CAN be a "goal" if you know ahead of time what the average velocity you need to hit to complete all the work by a certain date. And - that goal is achievable since it matches the average velocity that had been obtained by the team in previous releases.

    Did it help? The project has been a success by all accounts! But I attribute the success to many improvements we've made from what we have learned from our prior releases and during the course of the project - go KAIZEN! Of course - having a stellar team to back it up always helps!

    Our team had a great discussion on this topic - and in the end, while no harm may have been done by calling it a velocity "goal," the team stated they felt pressured to hit the "goal" every iteration. But, is a little pressure a bad thing?? After all, I know people who work better in a high pressure environment.

    An interesting alternative is to simply show the burn down chart along with the trend line so that the team knows if they are on target to hit our release date or not. With no specific velocity "goal" number to share this way - perhaps it would be viewed differently. But I can honestly say as a past developer, I would have calculated the average velocity the team needed to hit myself!

    Perhaps by calling it a "velocity average" instead of a "velocity goal" - this would not have been a topic of discussion.

    Teams that use the commitment method in determining velocities for each iteration seem like they are also subject to pressuring themselves into hitting their velocity "goal/commitment" as well. Arguably, the pressure is worse since it's a commitment! Does this mean we should never use the commitment method?

    In the end, each team/project is its own beast. As a software development/project manager, it's our duty to adopt solutions specific to the needs of the team/project - even if it wouldn't possibly work on another project!

    ReplyDelete
  3. If the target is impossible, it's useless to have it. If we understand the nature of demand and waste in how we're meeting it, then the target is limiting. Why worry about what velocity is required to meet the date? Worry about how to improve. Adjust what is built or the delivery date if the measured capability isn't sufficient.

    ReplyDelete
  4. Further relevant discussions at dzone:

    http://agile.dzone.com/news/velocity-goal#comment-28623

    ReplyDelete
  5. Good discussion. Something close to my current project. Why just have one metric? I think velocity goals and quality targets are trade-offs to quite a large extent.My take:
    1. Avg velocity goals combined with average defects/story
    2. Communicating these 2 metrics across the entire team (stakeholders included) is extremely imp

    I'm thinking what is a good visual to show this trade-off?

    ReplyDelete
  6. Velocity has served as a good tracking metric for us in our project but other than that it is just a mere number. It does not depict what value your team has added for the client every iteration.

    Having it as a goal it may backfire as dev's never like velocity to be a goal and over a period of time the client also gets sucked into it and starts to get jittery if we dont hit the target no.

    Its a good tracking metric apart from that nothing else

    ReplyDelete
  7. It is important to note that velocity is never a performance measure - missing 'target' velocity does not mean the team is underperforming.

    As Jason also said, I believe the best use of velocity is to use the previous progress to predict whether all the desired scope is going to be complete by the deadline. If not, use the measurement as evidence (alongside other measurements and priorities) to decide what to do: Reduce scope, move the deadline, add (remove?) team members, work more hours per week; whatever the evidence suggests is the best solution for the specific project.

    By introducing the idea of targets, one is assuming the team will underperfom if not cajoled into hitting them. If that assumption is true, there are better ways of encouraging them to improve performance than giving them a number. If false, it implies a lack of trust in a team that's working well and sets impossible expectations, which results in poor morale and their reciprocal lack of trust of leadership.

    The under-appreciated long-term result of making a team commit to velocity goals is a much more painful estimation session in the next kick-off, because of the implication that people will be held to task later if initial estimates are too low.

    ReplyDelete