Planning and estimation discussions always come back to:
- Agreeing what will be done
- Agreeing how much it will cost
- Agreeing a deadline by which the what will be done
Because these questions require that one knows everything down to the deepest detail and that all possible happenings are known (which means knowing when people will be ill and for how long, how much time they’ll need to take off for dealing with family troubles, problems with the plumbing etc) and the risks are mitigated such that they absolutely will not affect your project in unpredictable fashions.
That’s not to say that one can’t set deadlines but one has to expect to trade features away, adjust resourcing etc. Of course none of this is news and yet so many places claim to be agile whilst continuing to have the what, how much, when discussion.
Technorati Tags: development, engineering, process, software
Entries (RSS)
This is not meant as an attack on your opinion – “you” is meant as a general “you” – and my comments are made after having experienced the fallacy named “agile”.
Agile is also not constantly moving features/ improvements/ bugs out of scope instead of addressing efficiency issues, i.e. “you’ll get what you get when you get it”.
With regards to the hint of “don’t plan because we don’t know all the detail anyway”, I disagree – if you actually manage your staff and keep track of how much absence there have been in your team previously, you can add this to your contingency and even high level estimates are better than no estimates at all.
At least in the real world (outside academia and unlimited budget companies), where there is a budget and competitors are around the corner, you need to have some idea whether there is a chance to deliver what is required before starting throwing money at it.
If you don’t have any plan (which doesn’t necessarily mean that it is a contract), how do you know when you are so far behind that you won’t be able to deliver the minimum requirements? (rhetorical) How do you know when to adjust resourcing? (rhetorical) Are you just going to let the stakeholders throw money at it for another six months and then realise that we can’t release due to lack of essential features? (rhetorical)
Would you get you builder in to refit your bathroom to work in an agile way where you either cut scope (e.g. the shower) or bring in an extra builder halfway through (@ £170/ day) and in the meantime you happily keep using the neighbour’s bathroom? (rhetorical)
“With regards to the hint of “don’t plan because we don’t know all the detail anyway”, I disagree”
So I think that’s a key statement worth some discussion – Agile doesn’t say there’s no plan – it justs says there’s only so much of a plan and how much of a plan there is will be dictated by how much is known about the difficulties of achieving some target. The bigger the target the less you’ll likely know over all and the more assumptive any plan is.
In response to this difficulty, Agile encourages us to break up the project into little pieces and do such things as controlled and time-boxed investigations to map out the work terrain. One can target the highest-risk/least known areas up front and as quickly as possible decide whether the intended target is remotely achievable.
The problem with many plans is they assume the target is achievable and the owners of the plan attempt to force convergence on factors such as deadline, resources etc and keep them within that initially defined set of targets rather than adapt and adjust. This seems to be about the nature of human beings and what happens when you put something called a “plan” in front of them. Another bad habit we see is negotiation over the plan where estimates are disagreed with by non-experts purely out of desire to hit some preferred target.
In respect of the builder example, I think we’d all like to believe that they work to a plan and it’s all well thought out etc in advance but I suspect the reality is different – there are parts they forget to account for (hence the sudden trips off to the local trade supplies), things don’t quite fit as expected and adjustments are made etc. In some cases, one even abandons and gets a new builder in to rework the previous effort. I’d also be tempted to suggest that reworking a bathroom is substantially simpler than most large scale software projects (where large scale includes extending an already large system which is rarely as simple as just adding a bit more code).
At the end of the day I believe Agile encourages more creative methods for reaching a target than the traditional plan approach which tends to cause tunnel vision. At it’s heart it’s nothing more than ongoing assessment with targeted attacking of key risk areas and regular time-boxing to facilitate early exit or adjustment. Agile also encourages honesty so we find out sooner rather than later there are problems. Big plans for some (human?) reason seem to cause denial and pretense that all is proceeding okay leading to late “shocks”.
Agile isn’t a fallacy but it’s not easy to do and requires discipline and solid understanding in all parties. I also think it serves to discourage all those bad human behaviours that grand plans tend to bring out in us all.
I think a fine example of the underlying issues in this debate can be found in many a military engagement. One starts out with an objective and a rough plan of action but very rarely an end-time simply because the enemy is unpredictable as are many other factors. The military knows it will have to adapt and adjust as it goes and in some cases withdraw from the field of battle with it’s tail between it’s legs. The general public would like to believe there is such a thing as perfect war and accurate plans but military minds know otherwise.