The cost of change

[#1]

A post by Josh Golosinsky on Linkedin made me connect the dots on a few things that has been rattling around in my brain for a while regarding the cost of change

Change in priority

Agile tells us to “embrace change” and welcome changing requirements, even late in development. I think you need to remember where this comes from. It was written in a time when waterfall was the prominent way to organize and deliver software projects.

The focus was to:

1. Gather requirements and freeze them

2. Do the design and create the plan

3. Deliver according to plan

4. Enforce strict change management if new requirements arise or existing changed.

Did it work? Not very well since customers have a hard time to describe what they acually want. When they see something it is easier to raise an opinion. “Yes, like that but it would be better if it worked this way”. Many good ideas never saw the light of day because people didn’t bother to engage in the complex change management process and rather delivered according to the requirements even if they knew that it wouldn’t be the best solution. The plan would eventually break but at least it wasn’t “my fault”

Agile was new way to deliver value where everybody had the authority to raise their opiniion and say “Hey, why don’t we do it this way instead”. Embracing short deliveries and experimentation to “uncover new ways of delivering working software”

The drawback? It still comes with a cost. Late changes in prority or strategy means that everybody is ready to run in one direction but you suddenly decide to go another way. Backlogs are prioritized, sprints are planned and everybody is dressed, but for completely different game. The cost of change is real.

Change in configuration

I can’t even count the number of times I have been asked to change a configuration in Jira. Adding a status in a workflow, configuring a custom field, changing a permission schema or add a new Marketplace app. Most things are 5 minute jobs when it comes to configuration but changing a process and informing maybe hundreds or thousands of users how the new configuraton works is a task that can take weeks or months. And added to that is all the new features that is rolled out in the application itself (everybody loves a GUI change, right?).

So a 5 min job or a cheap marketplace app is not the real cost of change, behaviour is.

Organizations are non-newtonian

If you mix corn-starch with water you get a non-newtonian liquid (Oobleck) which is a substance whose viscosity changes depending on the shear rate or force applied, rather than having a constant viscosity like water.

Organizations works very much in the same way. When trying to force a change you will create stress and that can create a solid wall of resistance. If you instead work with the liquid, sorry organization you will need much less force, but it will take time and patience.

Being a fast moving start-up is not feasible when you are a large organisation, the number of people itself makes your organization non-newtonian. There is a significant cost of change so before applying any type of preassure make sure you are pushing in the right direction.

How do you tacle the cost of change in your organization?

[Samia]

Very insightful 👏

It reminds me of changing your route in the middle of a trip — on paper, it only takes a few seconds to update the plan, but in reality you need to realign everyone, adjust each step, and deal with unexpected friction along the way.

In the end, the real cost isn’t the change itself, but getting people aligned with it.

[Van Rees_ David]

Overall I agree with the concepts and the article is well written.

I do disagree with the thought that agile means major change in priority or strategy happens more often  or costs more for agile groups.  There are many levels of planning in agile and if there is discipline and maturity around planning, then the work will be the right work more often, and what you are learning at the end are the details and nuances that don't come from planning but from seeing live work. 

Priority or strategy can and will change occasionally, that's agnostic to delivery methodology and shows a mature leadership group.  Agile teams and groups operating correctly are specifically designed to handle that type of change, much more than a waterfall team, lowering that cost of change not increasing it.

[Staffan Redelius]

Hi @Van Rees_ David 

I don't disagree with you, Agile done right includes a lot of planning and a agile culture is more responsive to change. 

My point is, when "embracing change" is interpered as "no need for planing, cause we are Agile" things often goes horriibly wrong.  

The plan is nothing -  planning is everything as Winston Churchill allegedly said