Managers : Impediments

It should not be confusing how to manage in Scrum (agile) Let's put a scope of this. We are talking about the management of innovation, using Teams. Not the management of BAU or regular production or whatever your firm calls that. I am less sure these principles apply in those cases. First, you have a Team that should be a real Team. And they (the full Team) should mostly self-manage. Second: ask a few questions as a manager. Ask the Team things like this:

1. How is it going?

Then listen carefully. Don't 'talk', listen.

2. Am I (or is 'management') an impediment to the Team?

It is remarkable how often, in trying to help, we managers actually get in the way. We distract, we interrupt, we just don't help them. OTOH, sometimes things that actually are helpful are not understood that way. But if the Team does not understand (in your opinion), at least listen carefully to their opinion. They might actually be correct. Always recognize that management is 'overhead' and by definition is in some way 'getting in the way' of doing the real work of innovation.

3. Where is your public impediment list?

Review it with them, especially the top items. And you might suggest impediments that they should consider. You want to see a good, current list of the top 20 ways they think they can improve.

4. Let's discuss the impediments you have fixed lately (in the last sprint) and how much impact that has had.

Comment favorably on the progress they have made. Reward that behavior. Ask them: having done that, 20-20 hindsight, how might you (or you all) have done that better (the next time)?

5. Are there any impediments you would like me to help you with?

This is THE essential question. In fact, the answer always must be 'yes', and the only real question is deciding which one. It probably will be one where the manager is competent to help. And then, more competent than the Team itself to fix.

6. Is the Team spending enough time 'sharpening the saw'? What percentage is that?

"Sharpening the saw' is from that famous story in Covey's Seven Habits book. Human beings 'naturally' never spend enough time sharpening the saw. They seem to be thinking that it is 'better' to just do the work with brute force. Perhaps in the middle of a battle, hand-to-hand combat, that is the right thing to do. But not with our knowledge work. I recommend that the Team spend about 1/7th of the 'power' on getting better (aka fixing impediments). *** Some notes: The public impediment list will be prioritized, and the priorities could change with time. The order should include cost-benefit analysis, at least to the degree they can do it. You might need to help them think that through. Often they have little or no experience in doing that. Political cost is among the costs to consider. But we do expect managers (and teams) to take political risks, in a measured way. You might not agree with the priorities, especially at first. Discuss that with them, without using your power. Don't worry about the priorities too much. Even if you do them 'out of order', a significant part of the benefit of fixing impediments is that you did what they wanted you to do. It has a huge motivational impact. You are saying via action their work is important. Now, I am not saying spend tons of money just to have them 'feel good'. But do not ignore the motivational factor. There are many many more things to say about impediments. But I hope for many of you managers, these notes are a good start. I think if your encourage 'removing impediments' in these ways, I think you will be surprised how much better the Team becomes. *** Please comment....

Agile Adoption: Two styles contrasted

Imagine a smallish organization with 10 Scrum teams (or what will be 10 Scrum teams).  I want you to be thinking of a relatively uncomplicated situation.

Imagine that you offered two ways to implement agile. Let us assume that we believe that agile will lead to better lives for the workers and better lives for the customers.  And, indeed, better lives for all.  And to a fairly high degree.

Option 1. Top-down, via 'convincing'

You get a senior sponsor.  He says some good words.

You hire SMs, coaches, some agile people.

You get an 'agile committee,' not unlike a sponsor committee for a large project.

And the small group of agile people do things to make the agile transformation happen.

But, importantly, this approach does not allow the whole group to self-organize.  The Leader or a small group 

imposes an order on it.

And you are, and everyone knows you are, trying to 'make agile happen.'

Two commonplace sayings in change management.

"People do not resist change, they resist being changed."

"People are remarkably good at doing what they want to do."  Little's Second Law

 

Option 2. Similar, but allow self-organization

This approach is very similar, really, to me.  But with some very important differences.

You skip the 'agile committee.'  Because you know that committees almost always waste time and do nothing.  In fact, that's WHY we have committees.  It's what we do to ideas we wish to kill.

The agile advocates might still meet and talk, and get smarter.  But they do not attempt to decide for the group, nor to force the group to accept 'agile' (however it might be defined).

But an important difference: we invite everyone to help solve the problem or problems, to make agile work for us.

And we use Open Space to allow the whole group to self-organize within the context of a vision.  (Sample vision: "We want to experiment with agile and see if it will work for us, and maybe give us some great results.")   The self-organization is highlighted by two events bounding a timebox of change.  The opening and closing events are done using Open Space (some of you know OST).   And they learn how to self-organize by repeating this regularly (say, every 2-3 months at first).

In this way 'the wisdom of the crowd' is harnessed, in part for its wisdom.  And what is not working well in the formal structure is avoided.  Everyone can contribute and, particularly, the wisdom of the informal people is harnessed more.

But more importantly, we allow them, who are actually doing the real work, to tell us what their biggest concerns are.  And then we (all of us...management and workers) address those concerns and issues in priority order.

And they all become engaged.  They start to think of it as their own show (not completely, but to a large degree).  They are acting to help realize the vision.

BTW, management does not give up on introducing agile ideas to the group.  We have to be mindful that most of them do not understand agile at first, and have never experienced its real benefits.  So lots of explanations of the counter-intuitive aspects of agile are needed.  But the explanations are offered, not forced.

And management is very mindful about telling the story.  Stories about the past, the present and the future.  Stories that help them see the truth better, that agile is helping (well, assuming that is the truth now).  Stories that give the change meaning for them.  Everyone is, to some degree, telling stories, but management actively engages in forming the new story for the new culture.

Note: In these ways, we actively engage in culture change.

But 'our' attitude is different.  We are not 'forcing' these ideas on them (the ill-informed knowledge workers).  We are instead inviting them to experiment with these ideas.

Just as Taiichi Ohno suggested.

 

Results

It is, of course, a bit more complex than this.  There are other issues to consider, beyond the scope of this short blog piece.

But which Option will have more success?

This is your question.  And, in my experience, a huge difference hangs on your choice.

It seems to me that Option 2 is far more likely to realize the real benefits of Agile.  Potentially huge benefits.

Option 1 will still probably get you some benefits.  Maybe the Teams will be 20% better.  Probably.  And you don't have to give up the illusion that you can control people.

With Option 2 you can get 100-400% improvements in productivity.  We certainly can argue exactly why it happens (Scrum, Agile, self-organization, CAS, etc, etc.)

But to do Option 2 you must give up the illusion of control of people.  It feels hard to some of us.  It is not, really.  (Still, any change in paradigm is hard for those wedded to that paradigm.  Be sympathetic, as you will want them, in a different context, to be sympathetic to you.)

For senior managers: Asking the middle managers to give up the illusion of control of people can sound very dangerous to them.  You have to work with them, over and over, and get them comfortable.  Or, failing that, no matter which option you take, experience shows you are likely to end up with some problems and a relatively weak implementation of agile.

***

BTW, Option 2 is explained in more detail as part of Open Agile Adoption.  You might start reading here:

http://newtechusa.net/agile/open-agile-adoption-explained/

It has been tried and tested, to some degree.  (Open Space has decades of being tried and tested, and if done professionally, is very robust.)  OAA is relatively new.  But I hope you see its power.  I invite you to consider it.  And it works both for new agile adoptions and well as for a 're-start' of a troubled agile adoption.

Option 1 has been tried in myriad variations.  Pretty clear that unless you have a charismatic leader or a culture that already 'wants' to do agile, you are going to get a 'meh' adoption.  Very likely.  Yes, some benefits (20%), and a few teams doing well for a while.  But to me, only getting 20% is 'meh.'

Let me say it a different way.  I think if the adoption does not harness the will of the people in wanting the change, the change results will be 'meh'.  OAA is one way to engage the people.  I would be very interested in any other ways.  But for now, you may want to consider OAA.

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.