Resistance Is Not to Change

April 29, 2014 — Posted by Al Shalloway

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.  I tend to disagree with both positions as I think neither applies most of the time – and even “most of the time” is not a sufficiently high enough bar in my opinion. Our approach should always be determined by the situation we are in.  Not by what we have gotten 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 my earlier blog – 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 – that’ll be a topic for a future blog.

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.  One does not need to start driving on the right side of the road in the UK since that’s what they’ve 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 (and yes, I know about complexity - see Complexity, Causality and Why Keeping It Simple May Keep You Stupid).  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 one wants to do as soon as possible. 

Since this blog is related to my upcoming workgroup session at the Lean Systems Society Reactor 14 conference, please post comments at its LinkedIn discussion group.  Any comments here will be reposted there (anonymously) and answered there.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban