This post originated from an RSS feed registered with Agile Buzz
by Marty Andrews.
Original Post: I can drive pretty fast, but am I going in the right direction?
Feed Title: Ramblings of the Wry Tradesman
Feed URL: http://www.wrytradesman.com/blog/index.rdf
Feed Description: Marty Andrews talks about the day to day issues he faces as an agile coach on large enterprise applications in Australia.
Speed tells us how much distance we cover over time, and velocity adds to this by giving us a direction as well. If we don't arrive at our destination on time, that can be for a few different reasons. We might not be driving fast enough, we might have spent some time going in the wrong direction, or we might have spent some time just parked by the road and not driving at all. Jason Yip helped me clarify some ideas around useful measurements on an agile software project with this example...
So my mate Con the courier didn't last long in his job. His boss asked him to drive a package from Melbourne to Adelaide, a trip which takes about 8 hours (if you go straight there). Three days later, he turned up with his delivery, and the boss was fuming.
"My Grandma can drive faster than that! What happened!"
Of course, Con had a different story. He showed his boss the trip meter in the car, which distinctly showed an average speed of 110kmh, 10kmh faster than the average of the best courier drivers. However, the boss also noticed that the total distance was about 2000km (its only 800km between Melbourne and Adelaide).
"2000km! Bloody hell - did you come via Timbuctoo?!"
Con explained to his boss at this point that he had in fact come via Sydney, not Timbuctoo as first thought (silly boss), and whilst he was there he had worked with a specialist to build a steel framework in the car that would enable it to carry loads of up to one tonne, should the courier company ever need it. The boss obviously had no argument for this logic, but was still confused about the timing.
"Even if you did come via Sydney and soup up the car, it still should've only taken two days. What happened to the other day?".
The boss had obviously forgotten about the regular meetings that had been instated by the parent company. Con pointed out to his boss that he had to stop driving twice a day to attend a couple of one hour phone conferences about car maintenance and planning for new courier routes.
Cons boss seemed somewhat flustered by all of this, and was actually quite annoyed by Con's arrogance. He said nothing more at the time, but a few months later, Cons contract wasn't renewed...
I see examples of these scenarios every day on agile software development projects.
The programmers are inevitably pretty good at what they do. They work hard, and can produce working code quite fast. The amount of time they spend at work is the Project Speed, but the time they spend actually cutting code is their Programming Speed. The difference between these two figures is the Non-Programming Time, and if it's large could mean that, like Con, the developers had to stop driving to spend time in meetings or other activities.
Most of the time, the developers are producing code that actually works toward some feature that the customer has asked for. This is their Velocity. The difference between Programming Speed and Velocity is the Non-Velocity Programming Time. Some of this is legitimate (like producing spikes for example), but developers can also be tempted to build unecessary things too (like Con did with his stell framework in the car).
All of these metrics can tell you something useful about a project, and they can be quite easily measured as well. Metrics also provide you with great power in influencing (appropriate) change, and can help prevent against knee-jerk reactions like "the programmers aren't working hard enough" when in fact they are actually just spending their time in meetings.
Perhaps if Con had measured his facts and just shown the log book to his boss, instead of using his "I know better than you" attitude, he would still have his job today...
Previous Topic
