Monday, March 09, 2009

We're all Agile now, next stop Operational Excellence

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.

2 comments:

  1. Hi Allan,

    I sense a underlying frustration in this post. "How do I make other people want to do it?" My answer is you can't. They must want to "do it" themselves. So what is your role as an outside consultant when they say they want to change, but they don't really? Well in my experience as a Coach you quickly end up in the snake oil business, selling what ever snake oil the people that sign your invoice want to be sold.

    You talk about resistance to change, and the use of Agile language becoming yet another mechanism for resisting true change in itself. Well I've got news for you. Lean language can be used in exactly the same way. I experienced this first hand as a Manager in a TQM company back in the mid-90's. Boy we knew how to talk the talk, but it was an open secret that no one in Management really intended to walk the walk. As a consequence, TQM became an open joke amongst the workers, pretty much like how Scrum is becoming today, and no doubt like Lean and Kanban will become tommorrow.

    And this is the rub. Consultants don't change organisations. Organisations change themselves because they want to change. A consultant is like a Coach, he can give you tips and tricks, but he can't run the race for you. Worst still a consultant can become a smoke screen, allowing you to play lip service to change, whilst not changing at all.

    All very negative and defeatist, I know. So what can be done? Well you can improve yourself. Lets face it you are the only person you care in full control of. From self improvement, you may become a beckon and an example for others who may decide for themselves that they want to change too, and then again you may not. You cannot decide for them, you can only decide fo yourself.

    Funny enough, the answer is staring us in the face. All the leading luminaries in process improvement are their own gurus. Kent Beck didn't hire a bunch of consultants. He took responsibility for working out solutions to problems himself. In your Blue-White-Agile the team looked at what worked for others, then did the work to work to taylor a process that would work for them. Taiichi Ono, worked out an approach to motor vehicle manufacture that worked well for him and his company Toyota, and so the examples continue.

    People who are motivated will solve their own problems themselves. Those who aren't won't. By selling our services as "the solution" to someone elses problem we run the risk of becoming part of the problem too.

    This explains why Scrum is failing, and why Kanban is likely to fail too. My view is that the Agile movement needs to stop selling, and get back to writing software. People like 8th Light and Signal 37 are showing the way forward. If we truly believe in what we say, then these companies are the future, and the others paying our consultancy fees are our past. We get to decide for ourselves whether we want to live in the past or whether we choose to grasp the future.

    Its up to you.

    Paul.

    ReplyDelete
  2. Sorry Paul, I didn't publish your post sooner, I was a little surprised by it and didn't OK it immediately. Then I forgot it still needed approval.

    Sorry again because I've obviously failed to explain myself. I actually agree with most of your argument - although not all of it.

    My reading of your post is that you think my arguments are self-serving, I'm sorry about that too. And I'm sorry to compound the situation by saying: if you read Changing Software Development you'll see I address your point about consultants not being the answer.

    ReplyDelete

Note: only a member of this blog may post a comment.