Why I like to be Agile

Let’s face the reality that no matter how clear the project goals seemed at inception, they rarely look the same by the end. I’ve worked on projects where the whole scope of the project changed between the initial planning phase and the start of the technical work. What’s more the timescale tends to shift on a daily basis and your management keep ‘borrowing’ your resources for other vital work. This is the primary reason why I now prefer a more responsive approach; essential in a unstable world!

The Agile approach is more adaptable with respect to three key project variables; only the last of which, in my experience, is considered flexible in the waterfall world of engineering.

• Scope.
• Time.
• Resources.

Scope contraction.

Scope flexibility is something of a taboo subject. Scope is something that is added to in both a controlled manner — providing additional revenue — or uncontrolled creep. But the point of any project is delivering something that achieves the customers business goals. This is not necessarily the product that they, or the development team, initially envisaged.

One uncomfortably overspent project lead to the realisation that I could have achieved the business objective well under budget by actually drastically reducing the scope. It wouldn’t have delivered exactly what the customer expected, but it would easily have achieved their goal.

Which is more important, expectation or results? If you have a customer representative on the team it’s much easier to explain your rationale, and the chances are they’ll like the idea of results with less work as much as you do.

Timescales.

If you have a customer that doesn’t mind when you deliver, you’re a rare and lucky project manager, though you’ll never actually finish anything; deadlines do provide focus. So set plenty of deadlines, that’s what iterations and releases are about.

Try to answer the most pressing question as quickly as possible. Leave refinements and those ever present scope changes to the next iteration, it’s probably only a few days away.

This rapid cycle provides useful results, whilst allowing the flexibility to quickly change direction without that wasteful churn: just tidy this up a bit then I’ll be with you.

And the resources?

I’m afraid the project manager has to earn their money too. Line management will always have the urge to reassign any of your key people they feel aren’t being fully employed. It’s important to emphasise that the productivity of any team depends on preventing this happening.

Agile teams don’t strictly segregate workload on the basis of job descriptions, that’s why you need versatile individuals. Unfortunately, these are exactly the type of individuals that those managers will want to steal away. Removing the demarcation of tasks will help ensure everyone is kept busy and that work is conducted using the minimum number of people.

Better than the Waterfall.

I’ve found actual project goals shift too frequently for effective use of the Waterfall approach to project management. Using iterations within this framework always felt unnatural; how do you decide how may there will be and when will you actually deliver something?

An Agile approach perversely leaves me feeling more in control by worrying less about control. There are a huge array of Agile software development techniques, many of which can be adapted to other engineering disciplines.

For Software Engineering, I would recommend reading The Art of Agile Development. The Agile Alliance promote the use of Agile techniques, so take a look at the Manifesto for Agile Software Development upon which it’s all based.