I prefer small change over big change. I’m talking about transformations, of course . Small transformations make it easy to check if what we want to happen actually happens, and how far of we are. If you’re reading this blog there is a fair chance you are familiar with growing software in small steps – I apply the same principles when working on myself or helping others to improve their (development) performance.
What works in teams is to use an change backlog to track items that we want to improve. A backlog of small changes makes even a big, bad, change tangible and thus easier to manage.
Allow me to show you why small change works better than big change, and how I approach it in day-to-day situations. Nothing is new, of course, and you will find literature references at the end.
If you want to achieve a change (say, introduce some Agile practices) you may believe performance is going to improve according to the learning curve model. If you really believe in this model, you may push a bit, so the learning goes faster:
“There will be a learning curve, it will take some time, but it will be ok… It will be worth it, trust Me! Now Change! I will even give you some time to learn…”
some people around you see this:
Chaos means lots of change, but no improvement that sticks – performance is wildly variable.
Especially if you preach a big transformation, say e.g. the Big Agile Transformation (BAT), and you go around preaching and convincing, people may feel threatened.
Or, if we go one step up the pushiness ladder, they may feel squeezed:
Assuming our intentions are good, and we are more interested in results than in convincing people, we would be more effective with a gradual approach that incorporates fear of the unknown plus time to learn, try and integrate new behaviour. The Satir Change Model can help us realise where we are.
In old (or late) status quo the system is stable, performing in a more or less predictable way. When the foreign element (in this case us, or our bold new idea or a shift in the environment) chaos hits. When the system finds the transforming idea (which we may believe we already have – but often the system needs to find its’ own because it experiences our transforming idea as a foreign element…), practice and integration starts – the system, by the people in it, experiments with the transforming idea by trying new behaviour. When the transforming idea is integrated in new behaviour, the system enters a new status quo, which over time becomes a new old status quo .
I like the model even better with colours (Red for Chaos, Yellow for Integration and Practice, Green for New Status Quo and Gray for Old Status Quo).
This still depicts Big Change – but at least there is light at the end of the tunnel, and you know that Chaos is only temporary.
My preferred application of small change takes this model, and sees it as a cycle: After (new) status quo another cycle of change starts:
A succession of these cycles gives us an upward spiral of incremental improvement. If we keep the change, we can prevent from getting stuck in a rut (late / old status quo – the grey zone). Drawn in a timeline, we can see increments like this:
a lot of small changes, each leading to improvement, and short amounts of chaos. Before status quo sets in, we start with the next change, so everyone stays accustomed to change (this is why for instance in retrospectives it is common to choose to do something ‘differently’, even though there may be nothing ‘wrong’ with the current situation).
Of course, it rarely gets as predictable as the previous picture. Each change is an experiment, with a hypothesis and a result, so what actually happens might be…
Some change experiments do not lead to improved performance, and some changes are so easy you hardly notice – the team is in the ‘green zone’ and stays there more or less.
If we forget the hard work involved in each step and push, we may (mistakenly) believe that we have a newtonian change model…
The subject of each change may be different, so we can leave some area for a while, and pick it up later.
As an example, here is a choreography for small-change agile transformations I’ve used:
How do we get there? There are a couple of ways, all of them involve a change backlog. The differences are in how the backlog gets filled.
When I start at a new client, we have one or more ‘intake’ conversations. We discuss what current issues are, what is most important, and what would be a pragmatic place to start. Often I keep the backlog implicit, in my head or my notebook, and act as a mentor by suggesting pragmatic starting points.
Project, Release or Iteration Retrospectives. A retrospective identifies areas for improvement and/or things to try soon. Participants can prioiritize items from the backlog, and brainstorm solutions / things to try, which feeds in to the prioritized improvement backlog.
Stand-up meetings – blocking issues can be added to the top of the backlog.
As always, someone has to make a benefit/cost analysis for improvement. Time spent on process improvement can not be spent on delivering product, so we have to get bang for our change buck. Especially in the beginning, thinking about what to change next without disrupting the production of features can be difficult. A visible backlog helps to prioritize and reduce the amount of chaos felt by participants – we can track progress (this often is on a larger timescale than building new features, so not everyone is able to see the results without training.).
Once a team (or teams) start to click, change is often no longer a topic, and each iteration several items are added to and picked from the change backlog without much ado.
Quality Software Management – IV – Anticipating Change by Gerald M. Weinberg (explanation of the Satir Change Model and Lynne mc Lyman’s zone theory for the colors used in the drawings), and Virginia Satir for publishing the model in the first place.
“Kitch Kafich” photo of guys in car swinging a baseball bat by KRC
Lynne Azpeitia, for drawing the Satir Change Model as a cycle.