Why your organisation won’t be agile – Part I

I’ve been peddling a talk around the place recently. Ostensibly it’s on “Why your Agile roll-out is failing”. Though Dan North got the name first. So I called mine Agile Adoption Anti-patterns. meh.

The behaviours I describe are based on my experiences over the last several years as a developer and coach. They seem to indicate a number of systemic problems that organisations face when looking to go agile.

One conclusion I reach in that talk is that you will fail unless you are prepared for systematic change in the organisational architecture, the people, the culture and routines that define your organisation.

Ok, that’s pretty strong. let me rephrase that.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

Golf course agile

“We want to be ‘Agile'”

“Really? You want to learn how to value and trust your people? Be courageous? Build the right software at the right time? That stuff? Cool! I can help with that!”

“Umm, no. We want predictability and metrics. I want to know our velocity so that I know how lazy my developers are.”

“Oh, ok. Rename all your Six Sigma black-belts to Scrum Masters*. See how that works out for you and call us in 12 months when it doesn’t. Then we’ll chat about the rest of it. Failing that, can you just leave my card on your desk for the next CIO that comes through? Thanks.”

I used to find it was the developers who were into the idea of working in a more agile way. I think there are two reasons for this, the first is that undeniably there are shiny new tools and techniques out there that are associated with Agile. BDD, CI, Pairing etc all appeal to developers looking for ways to manage complexity in their code.

The second was that contrary to the popular image of a developer as some crusty old bearded dude (and it’s always a dude), sitting in a darkened room, only caring about copy-on-write semantics for lists, most are unbelievable passionate about their jobs and Doing The Right Thing. And incredibly intolerant of the wasteful processes they have imposed on them. Some even actually care about getting the right software out in front of their users so it can be used.

So for some of these reasons and almost certainly for a bunch I haven’t thought about, developers started getting the Agile bug years ago. It describes my reasons anyway. Plus I’m a hippy. Shrug.

Fortunately, the golfing class has now caught up. That’s a good thing right? Agile is going mainstream. Everyone and their dog is doing it. It’ll fix all our problems! Everything will be visible.

Management iz in ur progekt, wotchin ur progrez

Except I don’t really see Agile becoming mainstream. I see iterative development becoming mainstream, visibility becoming mainstream.

In fact, what I see most is that Agile is being used as another mechanism by which executives exert more control over their staff. Visibility onto a project should not mean you know who to fire when it fails. I haven’t seen much in the way of courage becoming mainstream.

In part II of this post I will talk a bit about the root causes of some of this behaviour. Stay tuned…

* Disclaimer: I’m not saying that Scrum is any more guilty of this than any other methodology, just that it is very popular. No-one ever got fired for choosing Scrum.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.