Agile - Grandmother was right - you can't fit a quart into a pint pot

My Grandmother used have lots of sayings.  I remember - "We had one of those and the wheels fell off", "As much use as a chocolate fireguard" and "Look after the pennies and the pounds look after themseleves".  My favourites as a project manager were "If you're in a hole don't dig" and "you can't fit a quart into a pint pot".  It's the last one that came to mind today!

Lean project management has lots of great attributes – more effective use of people & resources, better quality development, increased communications and faster time to market.  Yet however hard I look through research & documentation I can’t find the evidence that it’s also some form of “miracle worker”.

I’ve been involved in a lot of discussions on failing projects and the reasons for failure always seem to be the same – no one really thought about how they were going to do it.  Of course people understood why and, to a certain extent, what they want to do.  But when it comes to – so how are we going to do it – managers wanted to avoid the self-evident truth.

But back to basics - it doesn’t matter what methodology you use you’re still going to be faced with a fundamental aspect of physics.  If a project has a certain amount of work involved to complete it then it really doesn’t matter which approach you adopt – Waterfall, Agile, RUP or Lean – it will still take the same amount of time & effort to finish. A quart doesn’t fit in a pint pot…

Of course, lean approaches are better at focussing on real requirements and what will add value.  They deliver functionality up front avoiding big bang delivery.  However, there are implementations that need a base amount of functionality to be useful & chores to be completed to generate any significant value before they can be rolled out.  It doesn’t matter if we work as a small team, communicate better, concentrate on high value items or adopt Scrum methods to concentrate on great delivery processes ultimately the development work that needs to be done remains essentially the same.

Today I’ve had the ultimate Agile discussion.  Essentially it consisted of:

Looking at the user stories we’re looking at 4 sprints to complete the base functionality and probably another 3 to add the high priority business requirements.  That’s about 21 weeks.

But we need it by Christmas

I appreciate that but that doesn’t change the amount of work that we need to do it will still take 21 weeks

But we need it by Christmas

What requirements do you want us to drop?

None – but we need it by Christmas – maybe if you don’t test it so much?

The work hasn’t changed – it will take 21 weeks

I thought Agile was meant to be quicker?

It is more focussed and relevant but it can’t make 21 weeks of work take 10 weeks

I think you get the idea…..

That’s the problem with something being sold as the new solution.  Everyone says Agile is quicker, faster & more improved.  Of course we all know it isn’t but that’s the press it’s got.

So I’m left with the age old problem.  Lean project management is a much better solution to delivering great software.  However, it’s reputation is going to be tarnished by a few individuals who’ve sold the “faster” tag and Agile can’t always deliver.  I’m sure that someone soon is going to suggest that planning things upfront, signing up to detailed designs & requirements and agreeing a detailed plan that managed centrally is the best way to get things delivered quickly.  I wonder what they’ll call that approach – I suspect it will be popular if they promise to deliver 21 weeks work in 10 weeks by simply adding more people.

I’ll let you know how the argument is resolved.

Mike