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.
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:
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).
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:
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.
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.
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.
CEO, Net Objectives