It is a fairly common place to have developers telling the business and project managers that the process needs to be improved and the business dismissing the claim saying something in the lines of “Who cares? Our Velocity is ok.”.
The problem is that it is very easy for inexperienced Business Analysts and Project Managers to be Velocity-Driven. If you can’t understand what software development is about you get very happy to summarize the performance of a team in a single number; and you will fight to keep that number high.
The problem is that velocity represents only one dimension in software development metrics. Developers and testers are generally exposed to other metrics like internal and external quality, performance, flexibility, development sustainability and lots of others. An inexperienced person won’t realize that those other metrics will ultimately impact in their loved Velocity.
I remember some projects ago we had a team complaining that the build was taking 20 minutes. Business and management dismissed their cry for help, as the velocity was good. When the build reached 50 minutes management said they would do something about it, but instead of investing some time in the build they bought a better build box.
After some more months it was taking 90 minutes just to compile and run tests in your local box, you would be very lucky if you could check-in your code at least once a day. The result was that a team of extremely skilled and expensive developers had velocity zero for two iterations -four weeks. Nothing could be delivered, as nothing could be checked-in to be tested. Developers used to have 3 different workspaces in their computers as they would finish one card and wait for one or two days to be able to commit the changes.
To “solve” the problem a full-time pair was assigned to help in the build. If the developers were heard months before the situation became really traumatic how much money would that project actually save?
Another interesting effect of overrating Velocity is the devastating impact that this has in a good team. Imagine that a developer has been leaving the office at 9p.m. every single day so that, although they have that crappy database server that fails randomly, the team can deliver the points they committed to. When it comes to a retrospective meeting she raises the issue with the database and hears “Yeah, whatever. Our velocity is ok, I don’t think we should care about it right now”. What do you think the developer is going to do?
If the Business Analyst or Project Manager gives Velocity more attention than it should be given, if he or she is more worried in counting points than listening to the team, if anything that would impact in Velocity is a taboo… then a project has a huge problem. In this scenario it gets clear that his or her goal is not to deliver quality software in a timely manner, it’s just to deliver anything that sort of works. Now, is that Agile at all?
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.Continuous attention to technical excellence
and good design enhances agility.Simplicity–the art of maximizing the amount
of work not done–is essential.The best architectures, requirements, and designs
emerge from self-organizing teams.At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
There are certain activities that I believe the development team should own, tasks which do not get business approval. Tasks include worrying about software quality, refactoring to prevent future/current problems and maintaining their development tools. This maintenance includes controlling how long your build takes.
I agree with your sentiment that velocity is just one factor, but I disagree with needing to get business approval in order to constantly improve our processes.
Hi Sarah,
Good point. Actually I agree with you but I was describing situations in projects where technical debt was prioritised together with business stories and by business people. It would make more sense for me if the process had technical budget, prioritised by technical people, in the first place.
cheers
I believe that this kind of attitude is most common in companies wich tries to implement Agile practices but doesn´t got the “Agile Culture” yet. They usually show the results using numbers such Team Velocity in each iteraction to the company board looking for a good “status” instead of care about the real mature of the team and whole proccess.
Regards,
Tony.
Philip,
nice post.
I agree with you when you say that people give sometimes velocity too much importance. And that is kind of natural, when their performance is actually measured by the velocity. Like Goldratt said, “tell me how you’ll measure me, and I’ll tell you how I will behave”.
Despite agreeing, I still think that having just one measure is best than having many. The important part is that the team should just “accept” to deliver points if they come with the right quality, and this has to be a constant negotiation between business and technical people in my opinion, but I still think that the final word should belong to business.
As you said in one of your examples, the velocity eventually became 0 for two iterations. Well, that is the consequence of not listening to technical advices, and who is paying the price for it is the business.
But as you have these cases, I’ve seen also many where developers didn’t think about the business at all, and just wanted to make the perfect code. The problem here is that who is still paying the price is the business.
Cheers,
Francisco
Hi Francisco,
A lot of teams go too far into the tech pit and forget about business but for me these are separate issues. Having one measure for the whole project is not better, in my opinion, just because a metric will hardly apply to all dimensions in a project.
When you focus on one metric only you may get to the exact point that I was talking about in this post: optimising that metric in spite of the others and having trouble in the end.
The final word is from the business but they should not use only one extremely dumb and rough metric as their unique guide.
cheers
I think we are more agreeing than disagreeing
I also believe that nobody should use one dumb and rough metric as their unique guide. I see benefits in also having secondary measures as code coverage, build time, bugs found, etc.., but they should be secondary in my opinion.
The only point I wanted to make here is that if *sometimes* the business wants to take *reasonable* risk putting this secondary measures to the side and focus on delivery, it should be their call.
And I dont think that teams going too far into the tech pit is a separate issue, just because if we introduce technical measures we might have the same problem happening in the other side, with developers spending a lot of time trying to increase the code coverage from 98 to 100%, for example.
Cheers,
Francisco
I haven’t thought about this subject enough to form an opinion on the one vs. many metrics question. I can tell you that a single key metric (with supporting data, of course) is the standard practice in many statistics-oriented fields (economy: it all comes down to money; risk: as you know, VaR is just about the only “standard” measure out there, and it’s a single number).
At any rate, what I really find curious is that you would find velocity so problematic. I suppose the problem comes with using it in practice, since I can only theorize here. But I thought the whole idea behind Scrum is that the team gives an estimate of what they can accomplish at the beginning of each Sprint (and it’s JUST an estimate), and then they do their best to achieve that goal. If they can’t (due to, for example, technical debt), then the next time around, they revise their estimates.
If the team is really learning from their experiences, the “velocity” shouldn’t drop from V to zero from one sprint to the next; it should be a gradual decline that’s visible to the business end as estimates get revised upwards. Someone at some point has to ask why. Then it’s ok if technical projects enter into the Sprint Backlog, because the business owner can see the value in the project. That’s the point of an iterative, EMPIRICAL process like Scrum. Which is why, IMHO, the problem is in the practice and not the theory.
Also, as you note, part of the problem is the decline in the quality of work conditions for the developers, who are staying at work til 9pm to make their deadlines. If this is a common situation, then the developers are doing themselves a disservice by not admitting that they have a problem. If they have really bought into the responsibility of delivering on time, and would rather not reduce the scope, it’s up to them. But make a mental not to revise those estimates next time around. The Scrum Master should keep an eye out for declining work conditions, and help remind them.
Hi Tim,
Velocity is not comparable to VaR. At first, I don’t believe that just because one given field uses mostly one single metric (that is called ‘charlatanism’ by some) that this is true in software, they’re two different beasts.
But even if that was applicable, the metric chosen wouldn’t be Velocity, for sure. I’m not into economics but I guess velocity would be the same as “sum up all capital acquired this month” and if you ask a professional what can he do with this number I’m pretty sure he’ll say ‘not much’. Velocity is a dumb metric, based on summing up points that are already not exact, so although it is valuable shouldn’t be faced as the metric. Actually, when you adopt an agile method you give up on this kind of thing.
About the second part o your comment, the problem is that velocity won’t necessarily encompass tech debit. If the business focus on velocity and forget about the crescent amount of tech debit you will end up with low velocity very soon. One way to solve this problem is to create ‘refactoring buffers’ on estimates, but by doing that we face several other problems.
Yes, the velocity can drop to zero from any number, just let your build scripts without maintenance for a while, add a 80 minutes build that will fail randomly and a large team and you’ll know what I mean. Of course that was no surprise, tough. The dev team was alerting about this for months.
You’re right that velocity isn’t the end-all-be-all metric, and definitely right that it’s more or less meaningless from a business value perspective. That would have to be something like business value (aka money), which takes into account the ROI on what’s been developed.
So, what is velocity anyway? I assume it means “productivity” - how much stuff can we get done in a Sprint? For that, there must be some measure of “how big” is a piece of work (a story or spec or whatever). How are people measuring that? Functional points, or something else?
I guess my real question, though, is why isn’t velocity a good indicator? If it’s going down, it’s a sign to management that productivity is dropping. It should be reflecting a gradual decline, to which the business can react before it’s too late. Why isn’t that happening?
If that’s not the proper indicator, then what is? It’s the business end that has to decide what will bring the most value to the company Sprint after Sprint. Should “developer warnings” be always taken as priority one? Or is there a way to balance those concerns on the scale so business can make the right decisions?
Hi, Tim,
To me, Velocity is just a metric that can help you identify potential problems with a system (the project itself) but is not much valuable only by itself.
It’s like cardiac rhythm or body temperature: it can tell if you have problems if you are out of a given interval but even if they look good that doesn’t mean you are healthy.
And that’s the problem with velocity that the post states. Velocity is all right but developers are telling the business that the project is not healthy. Business ignore developers because velocity is good.
I didn’t get your last point. I never said that developers’ advice should be *the* priority, what I said is that dismissing them because velocity is good at this moment is silly.
(Sorry for the long intervals between responses - I don’t get email notifications on new posts)
Yeah, I get your point. The real problem here isn’t velocity per-se. It’
The real problem is discussion threads that don’t send notifications, and don’t let you edit when you accidentally hit “Submit”
But also it’s “managing by numbers”, whatever that number may be. Numbers are indicators, not the real thing. It’s a bit like driving using the speedometer and a GPS rather than looking out the window. Your velocity and direction may be good, but HEY! LOOK OUT FOR THAT BUS!
Numbers are valuable for helping you weigh the relative value of things (how can the process be empirical without some objective measure of how things are going?), but you’ll never have enough numbers to supplant communication and common sense.
Tim, you commented using two different mail addresses, check your sknt.com account AND gmail