In their keynote at XP Day last December Dan Jones and Marc Baker talked a little about the attempts to bring Lean to the National Health Service. One of the issues they mentioned was that while everyone “could talk the language”, many people had been on courses and many people agreed it was good very few people wanted to make the change.
I recognise the scenario and its one that is on the increase – and not just in the health service.
When a company asks me to help them “get Agile” I start by talking to people. At first I avoid mentioning Agile, we talk about their team, their company, the problems and opportunities they face, the frustration and the changes they want to me help make. I increasingly find that these people say something like “I’ve worked Agile before”, “I went on a course”, “We are quite Agile … we get pulled in many different directions” or “We’re trying to be Agile… we do stand up meetings”.
There is a debate going on – its been going on for a while but its louder at the moment – about just what “being Agile” means. Lean is being talked about more, either because people want another buzzword or because the true roots of Agile are now clearer.
Few people want to stand up and say “We’re not Agile” – its like saying “I don’t like Apple Pie” or admitting to an embarrassing medical condition. While is hardly surprising it is also a defence mechanism, and it can be a resistance to change.
Increasingly I don’t want to use the word Agile. The word brings a lot of baggage – pair programming, Scrum Master certification and all the rest. Once you use the word people start to have assumptions about what you are going to do.
Sure, many of those assumptions are reasonable: I probably am going to suggets they do visual planning and tracking, I probably am going to send the developers on TDD courses, and I am probably going to organise morning “stand up” or “Scrum” meetings.
But I’m not going to force pair programming on anyone, I’m not going to dogmatically demand 30-day sprints and I’m not going to force testers to write Java.
What I’m more interesting in is creating and instilling an improvement culture grounded in learning. My aim is to improve the way people develop software and run the company today.
So what word do I use for this?
I don’t think there is one. I’m starting to talk about Operational Excellence in Software Development. While that might sound like a bunch of management speak I think it is a better description of what I am trying to achieve.
But this term too has problems.
First it is management speak and a lot of people hear the word “excellence” and think “how can we run before we can walk?” – they see their organization as such a mess that excellence has little or nothing to do with the fire-fighting they do everyday. So any manager which talks about “excellence” is clearly disconnected from the real world.
Second the keyword problem: we live in a keyword driven society, you search Google for a keyword, you SMS a single word to a service, you Twitter half a dozen words, your CV/resume is scanned by software looking for keywords. “Operational excellence in software development” is five words, and includes two expressions which will trigger a million Google hits by themselves.
(Before you ask OESD doesn’t work as a keyword, Old English Sheep Dogs for starters.)
Still, the thing I like about Operational Excellence in Software Development is describes what you want to achieve – what you want to build – not how you are going to build it. “Agile” could have done that once but it was never given the change, look at the Agile manifesto, its about how, not what. It was good at the time but the world’s moved on.