James Shore recently wrote an article on agile mediocrity:
“In sales, they teach that the first objection is often a false objection–misdirection rather than a real concern. “Does Agile scale?” can be one of these false objections.
I wasn’t really being asked “Does Agile scale?” (By now, though, we know the answer: yes.) What I was really being asked was, “Does Agile work in large, dysfunctional organizations? Can I keep doing all of the ineffective things I’m required to do and still say I’m Agile? I can’t have a co-located team–it’s out of my control. I can’t have active, involved product managers–they’re too busy. I can’t create cross-functional teams–it would disrupt our reporting hierarchy. How does Agile scale to mysituation?”
It doesn’t… at least, not well. Welcome to Mediocrity.”
I’m slightly more sympathetic than James (who has clearly become frustrated seeing the same pattern over and over again) having worked in a large organisation adopting agile and see how we can quickly get to agile mediocrity, but struggle to go any further. Typically the catalyst for change is some enthusiastic developers and a forward thinking dev manager bold enough to take a chance that the Agile gumpf these guys keep going on about might just solve a few problems. This has some success, which gets jumped on by higher management who are lured in by the buzz and enthusiasm and it gets rolled out to other teams, however then it starts hitting walls. Firstly is the resistance within the department (and this is relatively easy to get over), but then it becomes clear (to the agile teams) that to achieve real results change needs to occur further afield and here’s where it all starts to seize up.
Agile is a bit like dropping a bomb in an organisation in that it creates shock waves which spread outside the IT department and have the potential to change the entire organisation (after all agile is the child of lean production which can be applied everywhere ). The problem is the wider the shock waves spread the more difficult the change is. Large bureaucratic organisations will always suffer from more inertia and change will be slower. I guess here is where a lot of people might get frustrated and start saying things like “it doesn’t scale”. The big mistake is blaming agile for your organisational inefficiencies. It’s not the fault of agile that your company is a lumbering old dinosaur that shares the characteristics of a supertanker when trying to change direction 
In my mind this is largely a management problem. They’re often very keen on Agile when it doesn’t mean they actually have to do anything. A self-motivated software team trying to make things better? Great! Restructure the organisation so the delivery team is sitting and speaking with the customer, employ in-house testers and allow time for learning in working hours? Mmm not so attractive.
It’s not sufficient just to roll out Scrum or install a Kanban board. As I’ve said similarly before to succeed with agile you need to look past the latest fashionable methodology and really understand the underlying principles. The Agile Manifesto and the principles behind it would be a good place to start.
Leave a Reply