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 doingthings 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 mechanicsmust 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.