I was just reading my good friend Jamie Fristroms blog where he was talking about measuring task velocity on his schizoid project
The entry is here.
Now the interesting part about this from my point of view is that he’s discovered from his statistics recording that velocity of task accomplishment is not constant, which is a point I’ve been making for a while now. It kinda undermines the whole point of velocity as a prediction tool (which is ultimately what it’s for) if velocity isn’t constant.
Given this information, I offer up a post I made on The Chaos Engine regarding Agile development, which mentions this particular point, plus some others.
“As I understand it and have seen it practiced, agile is designed for two things. One is to get accurate profiling, so you do what you expect to, and can expect to do what you do (with the implications that the work throughput is a known quantity and you can accurately predict what work you -or your team- can do) and the other is so that you don’t over commit on your deliverables, and to a point it tries to ensure that your deliverables are what you need to deliver.
Part of the first part is achieved by sprints, which are deliberate and aimed focusing of work to a meaningful and measurable point. After each sprint you can do a postmortem and decide whats not working – maybe its your prediction of how long tasks are etc. With each sprint you refine the process so that by the 4th of 5th sprint you are supposed to have it down, and be eminently predictable is what you can accomplish, and be working to maximum efficiency.
Now, given all that, it falls down in several key places. The first is that productivity is a sine wave, whereas agile wants to treat it as a linear line. In order to know how many tasks you can accomplish it assumes your output is static and that’s just not the case and never will be because we are all human. We all deviate within a certain amount – we all have a sine wave. The frequency (the time period you go from productive to non productive and back again), amplitude (how productive you can be, vs how not productive you are at your worst) and height of the mean of the sine wave (whats the average of your productivity?) is different for all of us, but it’s there.
The practical upshot of which is that each sprint you dick with what you think the duration of the task is when measured against a static value of ‘work accomplishable’ which isn’t static at all. So basically you always come back and say “well, I misread how long that task was going to be” when it’s not always about the task but also about your ability to sit down and get the job done encumbered with other thoughts or people disturbing you.
One thing agile does do is flatten that sine wave, because it makes you more efficient, more of the time. It also makes you concentrate on that task so when you get blocked it’s all the more apparent, and it provides the infrastructure and desire to get you unblocked asap so you can go back to being productive, which is nothing but a good thing. But it never makes the value static and as such it’s never 100% accurate. It’s more accurate, for sure. But it’s never more than about 80-85% accurate (although for lots of people thats way good enough and they are probably right).
The second thing is that it assumes that the task being measured *is* something you can measure / predict.
That doesn’t work for debugging. How do you predict how long a debug task is going to take? How long is a piece of string? The idea is that as sprints go on you get better at this, but if you are developing something with no experience in it (“Well, this game we need a streaming system. Anyone ever done one of those before? No? Crap…”) or that no one can have experience in (because no ones ever done it before) then there’s an issue.
Its the same with iteration of a prototype. How long before this is fun? I dunno, ask me one on sports. About the best you can do in those situations is give yourself a set time and if it’s not fun in that set time, let it go. Not what most people would want, but there are time and money constraints to everything.
Velocity tracking is better at real production / development tasks than it is for when you hit alpha / beta (depending on your definitions).
Most places that I know of tend to totally lose it in terms of task / velocity prediction and tracking half way between alpha and beta, when QA starts getting involved and you start hitting interminable bug fixing tasks.
On the other hand one of the other things that agile does is make the point that fixed schedules beyond a month are pointless and a complete work of fiction and therefore a waste of time, something that pretty much everyone here I’m sure is painfully aware of.
Having a high level milestone schedule but building your task list sprint to spring is a good thing, no question, because it focuses you on what you need to do, rather than what is currently fashionable for you to do.
Other assorted things you need to watch out for is that everyone is actively engaged in what you are doing and take their jobs seriously. If you have a scum master who isn’t engaged everyone might as well go home. If you have a product customer who isn’t able to get back to people when they need to with changes and approvals, then again, you might be on time and engaged but who cares? You are held up at the top level from making progress elsewhere. It’s like a car that can do a 100 mph stuck at traffic lights time that never turn green.
Note – one thing I recommend if you take this on is that you construct your contracts with outside sources – e.g. the publisher – so that they both understand how you develop and their responsibility in it. A friend of mine has a clause that states if they take more than 9 days in approvals he gets to go sit in their offices and be rude to them, which is definitely a step in the right direction but isn’t enough. The problem is that YOU as a team are still paying the price for them failing to deliver. Yeah, it’s satisfying to go be rude at their offices, but your team is still sitting there not able to make progress while you wait. What would be better would be a clause that says “after 9 days, silence is taken as assent and the right to dis allow approvals for that milestone is withdrawn”.
It’s hard to argue a clause like that because it means the publisher is acting in bad faith when negotiating the contract to start with (meaning they intend to withhold approvals) and there are civil laws about that.
But getting back to the point, Agile offers better methodology for tracking tasks and prediction than almost anything else – just don’t be suckered into thinking it’s “the solution” because it’s not. The only way to get “the solution” is to take people out of the equation – good luck with that
Like all things, there are things that Agile does well and things it doesn’t. Pick and choose according to your needs, don’t blindly follow the book, because the book is only applicable in totality for the examples it gives – it’ll never tell you where it doesn’t work – you’ll find that out for yourself.”
- February 2015
- January 2015
- August 2014
- July 2014
- May 2014
- April 2014
- February 2013
- January 2013
- December 2012
- March 2010
- February 2010
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- January 2007
- December 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006