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.
The options are: (1) Top-down, via ‘convincing’, or (2) Enable self-organization.
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 enable self-organization
This approach is very similar, really. 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. They do not attempt to decide for the group, nor 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.
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 time box 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. 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.
More importantly, we allow those, who are actually doing the work, to tell us what their biggest concerns are. Then ….management and workers) address those concerns and issues in priority order.
All become engaged. They start to think of it as their 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; offered, not forced.
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 ( assuming that is the truth now). Stories that give the change meaning. 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 a culture change.
‘Our’ attitude is different. We are not ‘forcing’ these ideas on them. We are instead inviting them to experiment with these ideas.
Just as Taiichi Ohno suggested.
It is, of course, a bit more complex than this. There are other issues to consider, beyond the scope of this short blog.
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 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 can sound very dangerous to them. You have to work with them 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:
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. I hope you see its power. I invite you to consider it. It works both for new agile adoptions and well as 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.