Is it really that hard to learn agile?

I work with people going agile.  Sometimes it is an awesome experience and sometimes it is quite depressing.

For example, I worked with some good, experienced people a while back.  They were were pretty sad before I turned up and pretty happy that I came to help them. This is the part of the agile coaching experience that is awesome.

Before the dawn of agile:

  • Business cases took longer to get approval than some projects took to deliver; and
  • Worse than that, some projects took longer to die than the fading spirit of the team members on the project.

Then I arrived, crashing through the window with index cards in one hand and a mandate to free the people from tyranny in the other.

This is where I like to play.

Editor’s note – Unfortunately this article turns out to be a long read, so grab a cup of tea, or just look for some nice pictures and skip all the boring text.

How I coached the crew

As I was saying – I arrived, crashing through the window …

We looked at the business case process and agreed that it was more about Consulting the Sacred Chickens than making an evidence based decision about starting work.

You might think I am joking, but people actually decided to do a project and then went through the ceremony of a business case before continuing.

But it was purely ceremonial, just like consulting the sacred chickens.  The whole team knew what the outcome of the business case was supposed to be – and inevitably the ceremony of the business case confirmed that they should do exactly what they had already decided to do.

We replaced “Consulting the sacred Chicken” with “Being confident enough to commit.”

Projects actually got going quickly and some were even stopped before they created much waste.

Just as importantly, teams got involved soon enough set the direction for the project and so they got to work on things they really they believed in.

People were happy and I was pumped with energy.  I left them with a silver bullet before riding off into the sunset.

But then they made a sequel

Then, recently, I caught up with some of the old guard and heard that things had changed since I left.

But the journey had not continued as I had anticipated. Sadly the bad guys were back in town and the silly old ways were back. It was like someone decided to make a sequel – The return of the agile coach.

Sadly – this is what I heard:

We are stuck in the middle of a giant business case for a stupid project.  We know we are going to start the project and nobody thinks it will end well.

It seems odd that this would happen

But why would people do that when they had seen how good life could be?

Apparently there had been a restructure and people decided to suffer more.

I pondered this.

Maybe people are not very bright

It is possible that people are just dumb and keep hurting themselves.

But this did not ring true in this case.

I remembered the bozo hypothesis that my father taught me. It was more likely that these smart people were acting on information that I did not possess, than that they lacked intelligence.

According to the bozo hypothesis though, smart people act on the information they have.  If they are given the right information, then they will do great work.

But my friends agreed that they had regressed and were now sad.  It was not that they were ignorant, it was that they fell off the wagon.

The mystery deepened.

Maybe change is hard and the journey is long

Maybe people are smart but change is hard.

Let’s consider this theory:

Barring a giant crisis ….

If we don’t change, we will still get by, maybe even getting a little bit better over time.  Maybe it is worth the effort to improve, or maybe we are actually awesome enough where we are now.

Measuring awesomeness

To see if we are sufficiently awesome to settle for things the way they are, we can baseline our current level or awesomeness (or CLA).

We can measure this in “Awesome Units” or AU, where:

  • 0 awesome units means we are not at all awesome. In fact people would describe us as “mostly harmless”; and
  • 10 means that people will quote us in legend – they will say “you too could, one day, be like them,” –  It’s a good place to be.

Lets assume that I do a health-check and we measure the team at 3.2 AU.

Sketch

If we do not embark on a big change, then we will continue to be reasonably awesome.

But I estimate that if we implement some agile goodness then we will rise to a level of 5.0 AU (not quite as awesome as the teams of legend – but quite a bit more awesome than we are now):

post agile

So we decide to go agile.  Then we hope to improve at a steady pace until we get to 5AU.

But sadly change is not like that.  In fact, if we want to learn a new way of doing things, we usually get worse before we get better:

sucks

This is the bit that sucks.

For example we want to break work down as a team rather than have the BA do it.  Life will get better once we master it, but we are not used to this kind of work. So in our first meeting everyone is shy, then we try and make mistakes.  Then we get the hang of it but are not doing better than before.  Finally we start doing better than we did before and then we keep improving right up to 5AU.  Finally, we are pretty awesome.

Coaches reduce the bit that sucks

This is, essentially, the role of the agile coach.  It is really about two things –

  • Creating space to learn; and
  • Reducing how much the journey sucks.

In creating space to learn, the coach

  • Explains to everyone (stakeholders, team members and bosses) that the team will need to either make mistakes or slow down while they learn new skills.
    • In other words, to give people the confidence to set tough goals and the persistence to keep at it until they succeed; and
  • Stops optimists bringing in too much change, to let people learn one thing before being hit with another.
    • This is called reducing change fatigue.

Good coaches say:

Motivation gets you started, habit keeps you going.

I like to think that I am pretty good at this bit.

But unfortunately, the bit about optimists creating change fatigue is a real thing and it looks quite messy.

fatigue

I have been guilty of this –  implementing a series new “improvements” before anyone is even used to working with the first improvement.

People cope for a while and then things start to unravel.  The team feel overwhelmed and never get to master anything.  There is just too much to learn and people are frazzled.

Sorry if you are one of those teams I learned this with.  It took me a while to learn the gift of patience.

But coaches also reduce how much things suck while improving. In other words they reduce the drop in performance and the potential drop in motivation when the team is on a learning curve.

In reducing how much change sucks, coaches work on two things

  • Reducing the time that it takes the team to learn; and
  • Reducing the scale of the drop in performance and confidence that occurs when struggling to learn something new

reduce

So we set tough goals, but the coach helps the team both understand the value of the journey and either speed the learning up, or reduce the pain of learning.

This is why it is so motivating to be a coach.  It really is fun to be involved in this.

Another theory

I am used to the concept that agile coaches are there to reduce “suck-i-ness” so that the team have the energy to improve.

I would even consider the title “Chief Suckiness Reduction Officer” if you had a position open for that sort of thing.

But for all of this great coaching theory – it still does not explain why my friends went back to the bad old ways once they had have learned that there is a better way.

Is it that the team lose energy and can’t finish the journey? Is it just them, or is is a pattern that we all fall into?

Well I have a new theory, based on a video about riding a bike.  It might be worth checking out the video before I continue.

The backwards brain bicycle

According to this video (and apparently some science of learning) it is relatively easy to learn a new skill when you are young.

Naturally though, when you get more experienced, you have a lot of experience to fall back on.  This should make learning easier as you can connect new ideas to your vast experience in old ideas.

This turns out to be true – FOR UNDERSTANDING SOMETHING

But it does not work so well for APPLYING SOMETHING IN PRACTICE

When you go to apply your new skill (riding a backwards bike or launching projects without consulting the sacred chickens) your experience in the old ways actually makes it harder.

Your brain (and even your corporate way of working) keeps defaulting to what used to work,  even when you know better.

So, on a backwards bike, you try to steer, the bike goes the wrong way and you automatically correct the deviation – BUT IN THE WRONG DIRECTION.  So you fall over.

You know that you need to unlearn your automated responses, but it is not that easy.

In the video it took an experienced bike rider 8 months to unlearn how to ride a bike, so he could learn to ride a (backwards) bike again. On the other hand, it only took a child a couple of weeks to unlearn how to ride a bike, in order to learn to ride a (backwards) bike.

Work is not like riding a bike (or is it?)

When you are under pressure, you often have to act before you have time to think.

So you try to do something good, then things start happening and something goes wrong. You course correct then try to do the right thing, then things go wrong even more and you course correct again.

But each time you act, you react automatically – in the wrong direction.  So things get wobbly and then you fall over.

Let’s look at my friends and their old agile journey.  They empower teams but as soon as things look like they are going wrong, they step in to stop the error. But this works against empowerment, so the leaders over-correct.  They say the team need to step up, and they back off.  But then the team look out of control, so they step in.  Then things get wobbly.  Then they fall over.

Not good.

This applies to the business case and the sacred chickens too.

The crew replace “consulting the sacred chicken” with “enough evidence to commit” but soon encounter ambiguity and the risk of setting the team off on the wrong mission.

They look into a couple of key points, but each highlights more things to sort out.  Then before they know it they are falling over again.

This is the bit that makes agile coaching suck.

It turns out that coaching here is hard work.

The bit where you highlight room for improvement and get people to agree to what they can do is somewhat hard.  That is when I sometimes leave a silver bullet and ride off into the sunset.

Sadly, that is where the real coaching starts and not where it ends.  The hard bit of coaching is not teaching people new things.

It is actually about helping them unlearn things that actually made sense, but are not going to work anymore.

But unlearning a way of working is pointless if they are not developing new habits to support a new way of working.  So it is also about helping people build useful habits rather than just understanding what those habits should be.

This is where the coach can add real value.

The good news is once new ways become habits, it is hard to unlearn them.

So why did my friends go back to the old ways?

I guess the real issue was not that my friends were dumb, nor that they lacked the energy to make a change.

It is that their coach (who shall remain nameless 🙂 ) did not help them really unlearn their old habits or really convert new approaches into habit.

Lucky I have more victims to coach.  But maybe I better focus more on building good habits and less on uncovering awesome new improvements.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s