Avoid an agile adoption that's 'meh'

We suppose there are many ways to adopt Agile or Scrum.

And in a sense it is true that each organization adopts agile in it's own way.

One pattern is 'bottom-up'.  This means that it starts with one team, who finds out about it and starts doing it, and then it spreads.  Without official approval at first, but later with at least the authorities not resisting it.  To the degree the 'bottom' gets the 'top' to support it in some ways, this can be a very successful approach.

And other pattern is 'top-down'.  The Leader decides 'we will do agile', and tells the group in detail.  This can work, to some degree, especially if the Leader has credibility and, in one way or another, explains what and particularly why.  And gets buy-in.  In that case, with time, it can be successful.   Why?  In my opinion, in large part because Agile justifies itself to the people.  Once they try it, they see the results, and become convinced.

However, very commonly the top-down implementations are 'troubled.'  They get some benefits, but people naturally resist.  They do not become engaged, they do not buy-in.  And, hence (at least IMO), the energy is not there, and so the adoption's benefits are rather modest.  And the people slowly, in a sneaky way, start to revert back to what they want to do.  Perhaps they do it consciously, maybe even more they do it unconsciously.

There is a another method now, called Open Agile Adoption.  One of the key ideas is that it is 'optional', or maybe better to say 'experimental'.

In other words, it is an attempt to see what people will want to do. At first, as a group, they do not understand agile.  Often, even later, they do not fully understand agile or scrum.  So, we do recommend some training on what agile is.  And some discussion within the group.  And use other methods to learn what agile really is.

Then the Leader 'invites' them to experiment and discover the benefits.

One. The adoption is no longer 'forced' or perceived as forced.  So, the natural resistance that occurs when you do that (at least in some people) is avoided.

Second.  By inviting them, you get them to start to buy-in. They are making a choice.  They feel like they are creating the change themselves.

***
Here’s how it works.

1. Let's try letting them volunteer within the context of a vision.  Practice, experiment, learn (much as Ohno suggests).

2. Let's get them engaged in the change itself (partly via doing practical work).

3. Let's bind these 'chapters of learning' (or chapters of change) in timeboxes.  We call each timebox a 'rite of passage'.  Maybe 2-3 months.  After each timebox, the group levels up.

4. Let's put a self-organizing event at either end of the timebox. We'll call these 'open spaces'.  1 day each.  And they act kind of like a sprint planning meeting and a retrospective, all rolled into one.

Then rinse and repeat.

And let's include Steve Denning's idea of leadership story-telling.  In fact, let everyone tell stories (they do anyway), but we (the good guys) tell MORE stories than we usually do (for God's sake!  We must!).

And the culture gets changed.

***

I recommend this set of ideas.

Start here: http://newtechusa.net/open-agile-adoption/

And read Harrison Owen's book, Spirit, here: http://www.openspaceworld.com/Spirit.pdf
This is a fascinating read.  Too intense, I think, to read quickly.

Heck, you are NOT going to read Harrison's book until you watch the video:  https://www.youtube.com/watch?v=APD7oQ3xrSA
It's about 14 minutes.

***
 

OAA is practical and tested approach to 'good' agile adoption.

Who knew we could treat the people like people?  And self-organize the change within a vision!

This approach allows, as far as I know, you (as agile advocate) to do also almost every other 'trick' you were going to do.  But whenever you do something now,  do it with respect for the brains of the people you want to change.  Get them to see the merits.  Don't think about 'forcing' it.

So, the Leader does not 'mandate' the change in detail.  ie, In OAA the Leader can give a vision (eg, at first "We want to experiment with agile methods to see if they will work with us"), but we urge you not to add too much detail to the vision.

AND...you (the leader or the leader group) can also OFFER to them details about things (like Scrum) that they might use.  And suggest that they *experiment with them."

So training, coaching, talking can still be used.  But in the context of invitation.

Who knew people, especially our knowledge workers, needed a feeling of autonomy?  (Cf Danial Pink in "Drive".)

Seriously, I recommend you consider this approach.  You will get more success.