Proof Agile Doesn’t Work

canstock12611275-proof-blueWhilst recently attending a networking event, I was asked what I do, to which I replied I’m an Agile & Lean consultant.

Being this was not a software development related event, my response was met by blank faces; until one of the group I was speaking to (who I’ll call ‘John’ for the purpose of this post) commented that “agile is a project management methodology used in software development.”

Feeling this was not the time to be pedantic, I agreed that agiles’ roots can be traced back to software development – adding that agility has since become a strategic approach for cutting costs, getting an earlier return on investment and gaining a competitive advantage, widely used across many industries.

John then asked if we could catch up later to talk ‘agile’ as his organisation was considering adopting it.

“Sure” I said, “Let’s do that.”

The Mysterious Case of the ‘Agile’ Duck

Baby-DuckMy son will be 3 next month.

And he’s currently at the stage of language development where he generalises.

Which makes for some very interesting — sometimes embarrassing — moments.

For example, whilst walking down the street the other day we saw an elderly man. And being the friendly type he is, my son waved to him and said “Hello Grandad” — even though the man was a complete stranger and definitely not one of his granddads.

But my son’s current level of logical thinking led him to generalise that since both his grandad’s are elderly, then all elderly men must be ‘Grandads’ too.

Now here’s the thing…

…although such generalisations made by toddlers developing language skills might be acceptable (even laughable), the same cannot always be said when illogical conclusions are drawn by adults — especially those expected to know better.

Let’s take Agile implementation for example…

Mind Your ‘Agile’ Language

ConfusedI recently got back from honeymooning in the Dominican Republic.

It was a wonderful experience.

Except for the language barrier off course. Because in the Dom Rep they speak Spanish – and I don’t.

So naturally, a few things got lost in translation (like the time I asked for a ‘shandy’ and got met with confused faces)

That said, because words only make up 7% of communication, during those rare times when there wasn’t an English speaking person on hand to save me from further embarrassment, I did manage to get by using gestures and facial expressions.

And that got me thinking about how often we use language ineffectively — especially when communicating with people who speak the same language as us.

Take agile transition for example…

Transitioning to Agile in Heavily Bureaucratic Environments

Although it’s often argued that ‘agile’ is not suited to heavily bureaucratic environments, in this video Matthew Bissett explains how a branch of ‘Her Majesties Government’ successfully reduced its delivery cycle from 9 months to 1 week by transitioning to agile.

(This interview was originally recorded at the Agile Development Conference and Better Software Conference East 2012 in Orlando. For more information on the conferences, please visit: http://sqe.com/conferences)

The Agile Response to a P1 Incident

emergencyHow should  a team respond to change?

The simple answer is “they should respond by being agile”.

If there’s one concept about agility that sceptical managers have caught onto it’s this one. When change happens, they expect that a truly agile team will be able to turn on a dime. You can hardly blame them, it sounds like a great idea. It suggests that perhaps managers don’t need to stabilise the working environment. They just need to pass change on. The teams will be able to deal with the impact…if they’re any good.

After all, aren’t they meant to be agile?

Of course, team members will have a rather different interpretation of this. They’ll tell you that agility isn’t about being reactive – it’s about responding to change in a controlled manner. With seemingly limitless demands on the team, and clearly finite resources, prioritisation becomes essential. Agile teams will work from an ordered backlog, and they’ll plan to deliver value by drawing work requests out of that queue. In other words they plan to follow an agile process…and that means things like “Sprint Planning” can still happen.

So let’s ask the question again – how should a team respond to change?