Our story begins with an awesome software product, many software developers, and a manager.

Over time, the codebase of the software grew and it became slower to write code for it and reliably put that code into production.

One day, a manager decided that something needs to be done about that. He decided to help create a working group to help with that problem. That group will be tasked to identify and suggest improvements in the product, so over time, after each of them is implemented, the software product is even more awesome, plus the speed and reliability are back.

Solution

Many developers saw this as an opportunity to do something they wanted to do for a long time. People from every team with different skills and backgrounds soon joined forces and started to think about ways to understand the issues and propose ways to improve.

The group took a data-based approach and decided to look for ideas that will bring the most impact and solve the most pressing issues first. So they collected a lot of data about the code, the issues they see with it, and the effects these have in production.

Some patterns started to emerge – they have found a direction!

Finally, after some false starts a list of improvements where suggested, split into smaller chunks where possible and prioritized.

A process was put into place to make sure the list is never “done” and improvements will be added to it over time.

The list was made public, put into the issue board used by most teams, and every team working on the product was asked to start working on issues from it. Finally, the “real” improvement work could start!

Problem solved?

Fast forward a few months ahead and the unfortunate truth emerged – the software was not getting better. But why? What happened with all those small improvements that were identified and everybody was so sure they will help?

The answer: not much.

From the list of improvements, only a few were picked up and even smaller number fixed. More than 90% were still waiting.

Why were people not picking them up?

“Debugging”

The group gathered and analyzed the situation, thinking about the many things that could have been wrong.

Direction: Maybe people did not understand this was important?

The discussion showed however goal was well understood by most of the software developers in the organization.

Motivation: Perhaps people lacked motivation?

Not really, everybody wanted to work faster and have less support. People were eager to improve things and each software team had a representative in the group that identified the improvements list.

There was also management buy-in!

Path: Maybe the way to achieve the goal was not clear?

All of the improvements were relatively small and clearly linked to a problem in the software because of the data-driven approach used.

Seems everything is fine?

What is it then?

How do people actually get an “improvement” task and start working on it?

Of course they do it when they plan they work.

But they plan a lot of other work as well – feature work, support requests, a number of different other requests. Different teams also plan at different times and have slightly different processes.

There was no clear guidance on how many improvements should teams pick during planning.

So people thought – this is probably important, we will pick something up when we have free time.

Good luck with that.

Finally, a possible solution was discussed and put into action:

Commit to one small or medium-sized improvement in your planning sessions.

As a result, one ticket at a time, the list of improvements started to shrink.

The third surprise about change

What is resistance is often lack of clarity.

Things are not always how they appear. People did not lack buy-in to commit. They needed some clarity. Now they had a guideline on how much work they need to pull from that list compared to the other work they needed to do.

What about surprises one and two?

Here are all three, together:

• What looks like resistance is often a lack of clarity
• What looks like laziness is often exhaustion
• What looks like a people problem is often a situation problem

You can find more about them in the book “Switch: How to change things when change is hard”, which I reviewed here a few weeks ago.

What I wanted to show is how to put the model described in the book in action, how it could be used, so it’s not just an entertaining read. The story described really happened, but many details were altered.

What was missing in the story was to “script the critical move” – give that additional clarity on the direction, so people can start doing some improvement work at last. It was making it easy to start.

There are many books on change and many models. “Switch” does not pretend to give you the most useful model, but the most practical one. So, in case you want to read and study the topic, I can recommend many books, but to make things more clear and easier for you – just read that one 🙂

Thank you for reading!