Resistance is Not to Change

In the Agile space, whether or not to do change up front is a bone of contention.  There are two extreme camps: one requiring a certain starting point (and thereby often requiring up-front change in order to follow its approach) and the other saying any up-front change will result in resistance by the development teams.  Neither position is sufficient. Neither applies most of the time. “Most of the time” is not even a sufficiently high enough bar. Your approach should always be determined by the situation you are in… not by whatever approach you are most comfortable with.

Ignoring Change or Avoiding Change are not the Only Two Alternatives

Let’s be clear about the approaches I am talking about: Scrum and the Kanban Method (not to be confused with Kanban; see Demystifying Kanban). Scrum, although a framework, requires a cross-functional team to implement it.  However, in many cases, this is either not advisable or can be somewhat traumatic.  However, when one looks at where Scrum often works and where it often hasn’t, one gets clues about the nature of change.  My own experience, matched by many in the industry, is that when Scrum is initiated by the team it often works well.  However, when imposed by management, it often doesn’t.  In my mind Scrum’s challenge to an up-front approach is that:

  1. It may not be the team part of the value stream that is the real problem (so Scrum doesn’t always address the true challenge that needs addressing)
  2. Creating teams may not be the correct solution (see How successful pilots often hurt an organization’s transition to Agile)
  3. A cross-functional team may not be advisable (some people need to work on several teams, at least initially)
  4. The change in roles may have an adverse effect on the team

When considering whether to do Scrum or to follow another approach it is important to see how the team views the change and how it affects other parts of the organization.

The alternative approach with the Kanban Method is to avoid all change until the value stream has been mapped, WIP limits have been put in place, cycle times measured and possibly more.  The idea here is that all up-front change will be resisted.  I find these two extremes (ignoring the effect of change and avoiding up-front change) to usually either cause problems or miss early opportunities for improvement (not to mention often causing framework tunnel vision).

The Nature of Resistance to Change

While I believe that ignoring the effect of change is very risky, I do not think up-front change is always bad.  An insight into the nature of resistance to change comes from Margaret Wheatley & Myron Kellner-Rogers’ “a simpler way.”  Here’s one of my favorite quotes:

“In practice, all systems do insist on exercising their own creativity.  They never accept imposed solutions, pre-determined designs, or well-articulated plans that have been generated somewhere else.  Too often, we interpret their refusal as resistance.  We say that people innately resist change.  But the resistance we experience from others is not to change itself. It is to the particular process of change that believes in imposition rather than creation.  It is the resistance of a living system to being treated as a non-living thing.  It is an assertion of the system’s right to create. It is life insisting on its primary responsibility to create itself.”

The issue isn’t whether change is bad if done prior to the Kanban Method’s recommendation.  The issue is whether those changes will be embraced by the teams.   In Extending the Kanban Method – Updated, I talk about how Lean suggests looking at three changes prior to implementing a kanban system:

  1. Decrease the batch size of work by attending to the core value needed
  2. Limit the amount of work hitting the team to match their overall capacity
  3. Attempt to create teams to the extent possible

See the aforementioned blog for more information on each of these steps.  My own experience is that doing steps 1 and 2 are virtually always embraced by teams.  And why not?  These are great steps to stop overloading them. Sometimes folks will resist being put into teams. But sometimes that shouldn’t be their choice.

Why Management can Often Make Changes That are Accepted by the Team

In the cases above, it is easy to see that teams will like management changes that stop them from being overloaded.  But are there other changes the teams will embrace?  Absolutely.   These are changes that will increase the teams’ abilities to be creative or at least, suppress them less.

I find it odd that many in the Lean/Agile/Kanban community have ranted against poor management decisions (e.g., waterfall, off-shoring, splitting up developers and testers, …) yet insist that management shouldn’t make any future unilateral decisions.  If they’ve said to do something that’s bad, isn’t them recanting on it and creating better organizational structures a step in the right direction? I think so.

Some Definite Truths

The concept of sometimes up-front change is good is often attacked by folks saying “imposed change and pre-defined changes are bad.”  But that’s not what I am talking about.  A competent consultant familiar with Lean-flow and experience with large organizational development can often see patterns of improvement that both management and teams will embrace.  These are not pre-defined in the sense that one comes in knowing they will work.  But rather they are approaches looked for with very high certainty that they will improve things in certain situations.  You do not need to start driving on the right side of the road in the UK since that’s what they have done in the US and then see what happens.  We can take information and apply it to the situation we are in.

There are many causal effects in the software world.  The point is don’t impose things on people where they feel their importance is being diminished.  Executives, management and teams must work together to create better organizational structures and workflows.  Sometimes merely working together is a big change – and one you should do as soon as possible.