Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Bennett's Blog

Nobody can do Agile

Let's be clear on one point.

You can't do Agile.

You can only be Agile.

What causes some confusion I think is that in order to be Agile, you often need to do some of the things you're currently doing now differently.

But if you really want to succeed at being or becoming Agile, you really need to first conquer how you're thinking.

Agile Is Culture, Not Process

Before you learn anything else about Agile, you should take this concept on board.

Because it frames absolutely everything else that you learn and do after that point.

Many Agile coaches and trainers think that the majority of their students infer this fact based on the common practice among good Agile courses of starting with the Values and Principles of the Agile Manifesto.

But in my experience, this isn't true enough of the time.

So I feel it's time to start saying it explicitly:

Agile is Culture, Not Process. This is what the Agile Manifesto is trying to tell you. This is not a process you can simply adopt. It's potentially a new way of life.

When faced with something genuinely novel in a familiar setting, the majority of busy people have difficulty relating the abstract to the concrete. This is doubly so if they are making the assumption that what they're seeing is not in fact genuinely novel, but just yet another process with weird new words for things they've been doing for years.

"So this year we're calling our requirements User Stories and Milestones are now called Sprints and there are a lot more of them"

The second problem with implying culture solely from teaching the Manifesto is that most people have been subjected to around 10-15 years of Corporate and Management Consulting rhetoric which has resulted in the words Value, Principle and Vision having in many cases lost all meaning.

So in a lot of these cases, once they hear the word "Values", some folks tune out of the Agile Manifesto stuff...

...then only tune in when the instructor starts talking about specific practices that they can concretely relate to their job.

Why does this matter?

Starting with the concept that Agile is not a process, but a culture allows for the possibility of being Agile but doing things that are "the same" or "similar" to the way in which things are done now.

Mental Models

The mental model of "Agile is a process"  drives people towards asking questions like:
"How does Agile handle this specific thing [that is a pre-existing concept present in my culture] differently to the way my existing process does?"
...and if the answer does not appear sufficiently obviously different to them, then they reject Agile as a whole because it's "no different" and thus clearly snake oil.

The concept of Agile as a process leads people to believe that if Agile is to create "better" results, then the mechanics must all be different. And if they are not convinced that the mechanics are in fact different, they then reject the premise that the results could be different.

Finally, thinking of Agile as a process leads to the 'pick and choose' mentality of
"We'll try daily stand-ups and see if that doubles productivity"
or the pick and reject mentality of:
"We can't do Agile because automated testing is impossible"

Situational Coaching

So I was talking about this just the other day at a social gathering and an acquaintance (who is currently involved in an Agile adoption) said to me:
That's what we're doing. We're trying to change people's behaviour. People expect to have a process, to be told exactly what to do in any situation.  But instead, we're saying 'you can decide for yourself what to do and these are the principles that you should use to determine the best course of action' But it's not really working. They're just waiting for instructions. Help!

So that probably came out differently than how it was meant - but obviously teaching people the Agile principles and then saying "you decide" is not going to work in the majority of cases, which is why in my team at EMC, we use what we call the "Situational Coaching Model" (which is based on the Situational Leadership Model)

In a nutshell, the Situational Coaching Model sees your Agile Coach taking your team, project, programme or even organisation on a journey through Directing, Guiding, Supporting and finally to Delegating.

If you've not read the referenced article, one of the key points is that in the first two phases, the Coach decides how the team approaches the situation. The rationale behind this seemingly un-Agile approach is that in the early stages of adoption it's only the coach who's living and breathing the manifesto, and whose job is not on the line when they cross the corporate culture police.

The beauty of the model is however if the team already lives the Manifesto, then it's easy to move through the stages quickly. (I have horribly oversimplified my explanation of this approach)

I think as a community we're sometimes not correctly setting expectations as to just how long it can take teams to move out of the first two stages.  It's just not something you can set to a timetable.

Being vs Doing

One of the aspects of "being" as opposed to "doing" is that ultimately every individual decides for themselves. Your boss can make you "do" something. They can't however make you "be" something. (Except maybe miserable if they do a lot of the first thing)

It's the attitude that each individual brings to the daily stand-up that matters exponentially more than the precision with which they follow the process of answering those three questions and taking up exactly 15 minutes a day on it.

If you don't internalise the culture / process distinction - you'll never leave the first two phases.

This is the leading root cause behind Agile rollouts that begin to "come unstuck" once all the Coaches and Trainers leave. The culture never changed.

If Agile isn't a process, then why is there so much emphasis on how to do things differently?

There are several answers to this question - some reasonable, some harsh.

Reasonably speaking, once you start to believe and value different things - you look for ways in which to support your new beliefs and values. The central tenant of quality, quality, quality in the Agile Manifesto Principles drove people to find better ways to develop and test software. The emphasis on working software as a measure of progress led to developing software in vertical slices, which in turn led to Continuous Integration in XP and resulting in the burn down charts used in Scrum.

These techniques are mostly all awesome - and generally useful too even if you're not Agile, which causes confusion if you believe Agile is a process.

But understand, regardless of their subsequent general utility these techniques were born of the Agile culture; the desire for individual mastery, the desire to enjoy work for a sense of camaraderie, pride & craftsmanship.

The harsh answer is however that the emphasis on processes and techniques is potentially a failing of those trying to teach you Agile - either knowingly or unknowingly.

The knowing kind are the worst - these are the people who do know that Agile is culture, but assume you don't want a culture change and so tell you it's a process because they want to take your money.

The unknowing kind may very well be experts in other fields, but are genuinely ignorant of the true nature of Agile themselves. Perhaps they're enthusiastic beginners, or perhaps they were led astray by one of the "knowing kind".

In either case, are these the people you want guiding your Agile adoption?

Or to be more accurate, your Agile transition, because if you've read this far, I hope I've convinced you that you can't really adopt Agile, you can only transition your culture towards it.

Published Wednesday, May 12, 2010 8:12 PM by Anonymous
Filed under: , , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Justin Hunter said:


Very nicely put.  I haven't heard Agile described in quite this way but I like your description of it a lot.

- Justin

May 13, 2010 2:06 AM

Mike Sutton said:

Brilliantly written and goes right to the heart of the whole damn thing.

The focus on process as a mechanism to change thinking is a tried and tested approach - and one that is reasonably successful.  But in a business context - business (or busyness) must go on - so we can't all go and sit and contemplate the awesomeness of agile till we 'get' it.

The danger of transitioning thought through process is that it is all too easy to distil the richness and possibilities of being agile in mindset (principles and values) to a set of practices (which can be checked off a sheet and audited!).

Great post!


Something is missing though :|

May 13, 2010 5:02 AM

Jeff Patton said:

Great post.  I'm glad this is becoming a meme more folks are discussing.  For people looking for some more thought on this subject, in particular different aspects of culture, I have this blog essay from last year: Agile is more culture than process: http://www.agileproductdesign.com/blog/agile_is_culture_not_process.html

May 13, 2010 6:26 AM

Lior said:

Wow, that was a great read. thank you for putting so clearly.

May 13, 2010 9:26 AM

James said:

Agile is culture? Not a process?

You might come back and read your own words one day only to realize that you can't have a culture without underlying processes...

Bosses? Bosses do not exist... Loose cannon sales people with a blatant disregard for the capabilities of their staff. Those exist.

Ask for credentials, a game plan or anything remotely resembling effort before you deviate from your "culture" to persue an "agile whim".

I trust the author of this document has the credentials or history to back their beliefs but I see very little of value to everyone who does not. It just concerns me.

By definition... everything is progressive. Sure...

May 13, 2010 11:22 AM

Bob Hartman said:

Simon, I think I agree.  I give a talk titled "Doing Agile Isn't the Same as BEING Agile!"  I make many of the same points and give different ways to start changing the culture and mindset.  It is usually a popular talk.  In fact I'll be giving it at an Agile Austin meeting on May 19 and an Agile San Diego meeting on June 3.

Good stuff, keep it up!

Bob Hartman

Certified Scrum Trainer and Coach


May 14, 2010 3:09 PM

GarthT said:

Great post.  The topic is something I've been thinking a lot about lately.  

I think there are many analogs for exactly what you're describing here and by looking at them we gain some insight into this issue:

Take the martial arts.  There are people that study martial arts strictly for the martial aspect - learning to kick ass.  There are those who begin to study for that reason and recognize that the arts have a philosophy driving them - these people go on to dive into the more esoteric aspects of their art.  Finally, there are those who begin martial arts recognizing the depth of the art and actively seeking that level of learning along with the martial aspect.

Literature and Religions come quickly to mind as similarly having multiple levels at which they may be appreciated.

The cause I think, in many respects is that process has so frequently been foist upon people doing the work rather than being derived from them that people expect to be told what to do and asking them to think about this is seen as extra work for them.  This causes them to operate simply at the "I want to learn martial arts to kick ass" level rather than understanding the principles/philosophy.

May 14, 2010 8:23 PM

Nigel S said:

A great article that gets to the roots of Agile success. Too many organiasations think that if they run the courses they are Agile!

May 19, 2010 8:24 AM

Maria Matarelli said:

Well said, Simon! Sometimes "Agile" is thrown around by people where you have to question if they even know the proper context. In the words of Inigo Montoya... http://www.youtube.com/watch?v=G2y8Sx4B2Sk

May 22, 2010 8:12 PM

Craig Knighton said:

This gets right to the heart of our struggle in positioning Agile coaching - people look at the cost of long term involvement (even part time) of a coach and while that may be what they know they should do, more often than not what they actually buy is training.  It's kind of like visiting the dentist - we all know we should go regularly and that we should floss every day, but what we actually pay for is a bad tooth that needs to get fixed.  I've found it takes 4-6 months of direct operational involvement to actually affect the culture; any other comparable results?

June 2, 2010 1:28 PM

Leave a Comment

Powered by Community Server (Personal Edition), by Telligent Systems