Consider the following scenario…
You are a test train engineer who has been honored to test the first ever high-speed maglev (magnetic levitation) train that will connect San Francisco and Los Angeles. With this new train, the 6-hour car drive will now be reduced to 3 hours…or hopefully less. And with the great advances in technology this should be a very cheap alternative to air travel - which takes about four hours now if you factor in the security check-in process at the airport.
The track has been laid out but not completely finished. However, on it’s first maiden voyage, you will be driving the train for 300 miles (basically, the amount of track finished at the moment). You enter the engineer’s car, and find that everything is sleek and minimal - you have a comfy seat that adjusts to a recliner, and your controls are basically two buttons - a start button, and a stop button. Nothing else.
Apparently, the scientists just want you to drive the train for 300 miles, see how the ride is, and hope that you get to the destination in 3 hours (they’re assuming that the technology doesn’t blow you up
). They don’t want you fiddling around with other controls such as speed or power - which explains just having the start and stop buttons. They tell you that the train moves at a specific speed that cannot be changed for this test.
Before you go, they tell you that markers have been put every 100 miles. Since the assignment is very simple, you bid adieu to the scientists, and wait for them to disembark. Once everyone gives you the hand’s up signal, you hit the start button, and the train smoothly begins to glide and zooms off. You look at your watch - it’s 8:45 a.m. You think to yourself, “Ah, I should arrive just in time for lunch at the other end - around 11:45.”
To pass the time, you view the scenery passing by and take photos - they built the engineer’s cab w/ a 360-degree panorama bubble that lets you see everything around you. The views that whiz by are amazing and really hold your interest, and before you even realize it, you spy the first 100-mile marker coming up.
As you pass the marker, you check your watch. It says 10:10. Hmm, looks like the train is a bit slow. You were expecting to hit it around 9:45.
“25 minutes behind. Oh well, I guess I’ll have lunch 25 minutes later than expected as well…12:10 isn’t that late,” you say to yourself.
“NOW WAIT A DAMN MINUTE!” (Yes, I hear your protestations, dear reader.)
“I’m smarter than that - if I’m the test engineer, and I see after the first marker that I’m 25 minutes behind schedule, then I know I will be delayed more than 25 minutes.”
Yes, you are correct.
If the train is delayed for 25 minutes the first 100 miles, then for every 100 miles, it will be delayed by 25 minutes each. Thus, for 300 miles, it will be 3 x 25 minutes = 75 minutes. For the math geeks out there, this is the infamous algebra problem of distance = rate x time.
Yes - you won’t be having lunch at 12:10…you’ll more than likely be having lunch at 1:15 - 75 minutes later than the intended 11:45 if the train really was meant to get to its destination in 3 hours. This is way late for your stomach (or mine at least
).
Unfortunately - the above scenario happens a lot in business - it happens a lot in traditional project management. PMs have their Gant and MS Project charts telling them that a project is currently 6 days behind for this one component in the critical path. Therefore, the project manager adds 6 days to the end of the critical path, and gives a new release date 6 days later.
DEAD WRONG. 6 days is wrong - and more than likely the project will be weeks, if not months, behind schedule.
Traditional project management unfortunately doesn’t factor in the capacity of the rate of work that project teams can accomplish. Agile project management handles this through velocity measurements. Using known velocity measurements, and story point sizing of features, one can calculate the impact of a few days being late at a sprint, and how it fits into the overall project schedule. Mike Cohn covers this really well in his book, Agile Estimation and Planning.
This is great if you have velocity measurements. But what happens if you don’t have velocity measurements? What happens if the team is new to Agile and has no established velocity or much less, story point estimates for the features? What happens if you’re new to a project, and you’re expected to deliver something in 6 weeks, and all you have is the current sprint’s burn-down?
Well, this is what I faced exactly at my new job. And I had answers…
(To be continued….)
Recent Comments