Agile Project Management

3rd March 2016 Mario De'Cristofano

Agile

Ah, that term I often here bandied around agencies all the time. ‘Agile’. Say it again…..’Agile’… You may have heard software teams mutter it, or team heads trying to implement it, or maybe you’ve seen it on a Project Manager blog. But to truly know what it is, let’s look at a dictionary definition first:

Agile: able to move quickly and easily (dictionary def layout)

So, no matter what your business, you want to be Agile – to move quickly and easily right? That’s fair enough.

What starts to get confusing is Agile refers to both a workflow methodology and also a cultural approach to general workflow & its this cross over where confusion occurs. Of course everyone and every business wants to be nimble, quick, to move quickly & easily but if your Enron, or Shell, or Apple, that’s not so easy. But are we talking about cultural workflow or are we talking about the Project Management methodology here?

Who knows.

At it’s very specific, Agile is suitable for anybody or any team working on product. The idea is you build something from start to finish in a small sprint and then you release it warts and all. You then collect feedback, iterate and launch again. You keep doing this until you get to where you want to be. Working this way has a number of benefits, it stops lethargy for example or procrastination. It helps shape a product by getting real world testing done as early as possible. And it’s a great way of working with software development!

But here’s the rub.

Your client needs to be as invested in agile as you are, for the thing to work. If your client is prepared to receive constant iterations of a product, glitches and all, and can join you on the journey then that’s great. But typically a client wants a specific fully featured and finished product, as quickly as possible and wants to pay a fixed price for it. Sometimes Agile doesn’t work for them, they can’t get on board.

Think of it as going into a car showroom and not knowing what car you want to buy but knowing the type of features you may want. So you pay a bunch of money and get told to come back in two days. You come back, and get a go kart. Wheels, somewhere to sit, and a small hand-wound engine. You take this away, and realise after a day or so its not quite as comfortable as you would like so you take it back and ask for a better seat. Whilst you’re there you remember you didn’t really enjoy the wind hitting you in the face either so you ask for a windscreen. Two days later your products returned with those very things. You take away, you test and then you come back and iterate again. You do this until you get to where you want to be. Great for software, not so great maybe for cars but you get the idea!

For Agile to work, you have to be clear what Agile you’re rocking! A business, and it’s client will want you to be ‘agile’ from a picking up the phone quickly and being able to rapidly fix a problem type of perspective, but strict Agile methodology requires both the business & the client understanding exactly what it is.

So what’s it good for.

Agile is great for software or product teams. For clients who are keen to see a raw product defined over a period of time, and who can afford to test & iterate in a live way with real users in the real world.

Hold on a minute, that’s only two types of Agile!

So far, we’ve learnt about common sense ‘agile’ and ‘Agile’ as a software/product delivery framework but now to cause further confusion there’s a third type of Agile. An Agile which weaves its way through the other two and joins them all up. It’s Agile Project Management!