Small Change
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.
sources:
-
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.
Credits
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.
Alternative change models comics by Nynke Fokma
“Kitch Kafich” photo of guys in car swinging a baseball bat by KRC
Lynne Azpeitia, for drawing the Satir Change Model as a cycle.
Nynke Fokma and colleagues for color coding the Satir Change Model.
Kathy Sierra (Creating Passionate Users) for the inspiring visual style of her blog.
And you?
I would love to hear what your approaches to small change are. Feel free to leave a comment. Or, even better, join us at Agile Open or the Change Artistry Workshop at Agile 2007.
May 8th, 2007 at 11:04 am
Hi Willem. Two thoughts as I read this:
a) one of the benefits of a succession of small changes is that people’s capacity to change grows. They survive chaos a couple of times and they get better at dealing with it. I think this is a big factor in many organisations – some have built a lot of underlying change capacity, and some haven’t.
b) one of the risks is that changes come at people faster than they can deal with them – they get left permanently in chaos. (And different people stay in chaos for different lengths of time, so just because some people are getting to new status quo doesn’t mean that everyone is.) This is where, I think, building change capacity before you try to make major changes can add a lot of value.
Graham
May 8th, 2007 at 2:49 pm
Hi Graham,
I totally agree with thought a) . Have small changes to cope more effectively with changes.
b) would be a reason to use a change backlog – that helps me / a group see that there is progress, while limiting the rate of change to an extent that the whole group (or at least a significant majority) can keep up. That way the group does not get stuck in chaos or reverts to the last status quo and stays there.
“building change capacity” makes me wonder: are there other things we can do to build change capacity besides going through small changes?
May 8th, 2007 at 4:11 pm
Willem –
What an excellent piece on change management! Great info and insight – you definitely get a better understanding of incremental (small) change after reading. Thanks for taking the time to put together such a comprehensive, well-written piece!
FYI – I’ve referenced your post at my site here:
http://ravenyoung.spaces.live.com/blog/cns!17376F4C11A91E0E!3521.entry
May 10th, 2007 at 7:45 am
Hi Willem,
Nice article. Do you do the do the drawings your self?
With regards to change management, this is a tough one. What you explain is very similar to the way I work. Usually I start with the most important things which you, I guess, would put on the change-backlog in a prioritised order. What would these things be? I suppose whole-team involvement and collaborative planning spring to mind. Of course, the context will have an effect.
But, is there no scope for a big transformation? I can’t help but think of the Priory clinic in the United Kingdom. Here people are given ‘tough love’ for their drink and drug problems. The idea is to snap people out of the rut they are in. And, of course, in some cases it works. With this in mind, can we snap teams and organisation out of their ruts? What if they don’t think they are in a rut? Well, if they don’t think that neither you or I would be working for them. Would we?
Of course we would! I rarely get hired to rescue anyone, although often that happens. Going back to big transformations. I did, for a former client, what would almost definitely be described as a big transformation. However, in that context it really was rather painless. The team recognised they were in trouble and were willing to try anything. Thus, we went from waterfall to agile in 6 weeks with continuous improvements a la your small steps until the end of the project.
Now, for other clients the first small steps are sometimes not even related to agile. They are more related to culture and approach. Examples would be trying to get teams to challenge their own thought processes, think in objects or write some tests. In some contexts, ones I have worked in, these seemingly small steps are actually huge! Asking some developers to write tests and do a bit of design is tantamount to asking them to throw away 20 years of learning. (Did you ever help a team shift from waterfall C development to iterative Java development? If so, you may know that I mean).
The point I am trying to make is that what constitutes a big change, I think, is actually a function of what a team or organisation is capable of. I have taught Acceptance Test-Driven-Development in days and have struggled with teaching unit testing over a period of months. The size of these transformations was a function of the team, not the “thing” we wanted to transition too.
In the latter case, when organisational culture is anti-change; things take for ever to shift; when all suggestions are met with passive-aggression (the Dutch Polder Model way of thinking being the biggest form of passive-aggression); I truly believe a shake up would be more cost-effective, albeit more painful, then an incremental approach.
I guess the way I’d do that would be with some big bang kick-off followed by an agile change strategy. The change strategy is agile because it will change over time. I guess one approach, if I were in a development environment, would be invoke Jidoka and teach everyone the core XP development practices. At the same time I’d reverse the task system and get the management thinking in terms of points, stories, and iterations. Pascal’s XP game is great for that. Let’s say this first section would take three weeks. I’d do a couple of days creating a product, project, and process vision. Then I’d start a three week iteration zero. With the focus on following the process correctly as opposed to producing lots of code. I’d hold a retrospective on the Friday, then I’d go home and collapse with exhaustion, and we’d start again on the Monday.
This type of kick-off could be used effectively in conjunction with your change backlog. I do realise this is high risk. However, when the clock is ticking, our customers usually sell products to waiting markets, and a project/organisation are in crisis, this approach can work quite well. I played Rugby for many years and I learnt that you can get people to do extraordinary things under tough conditions providing the intent is good. That is why I think that some big transformation are not only possible but would be the right thing to do.
I guess we have found a discussion point for Agile Open. Some questions I’d like us to tackle would be: what is a big agile transformation and can they ever work? Can a hybrid model model of tranformation work? What patterns of tranformation can the group share? What kind of resistance are the group used to seeing? What war stories can we share?
I loook forward to Agile Open with curiousity, hope you are doing well, Jamie.
May 11th, 2007 at 8:14 am
HI Jamie,
thanks for your extensive reply
Food for thought (and action).
Did I make the drawings myself? Nynke Fokma made the comic strips, I drew the graphs and the circle (using Inkscape, an open source vector illustrator – very nice stuff). The first two Satir Change Model drawings are based on the pictures in Quality Software Management volume 4 (In the book they are both in black and white, which works less well for a model with colored zones…).
I used to work like this before I started using a change backlog as well. I noticed I wasn’t always sharing my reasoning with the team, which might hinder their progress after I leave. On the other hand, in the beginning it might be that some handholding makes changing easier than discussing everything.
Usually I do start off with some kick-off, like you seem to do (XP Game is still one of my favourites ). Your emphasis on doing the things right in iteration zero is interesting. I guess my emphasis is mostly on getting the team in a state where it is safe to deliver software (e.g. get a working version control system, maybe a wiki and automated build if the team is > 2 persons – I have coached some small teams as well
) – usually one or two weeks and then start developing stories. With iterations people tend to get nervous when they are not completing stories (as they should, maybe…).
I guess there is place for Big Change, but I might not be the most suited to deliver it… I’m not sure I can get people out of a rut quickly in the context of a project. If I get the people out of that context, say in a training situation, I might. Like you, I have experienced teams moving at radically different paces – I used to think that two two six weeks was normal for what I would call gradual change, and after six weeks I’d start being more and more absent.
Jidoka – stopping the line is one of my favourite practices. I like your rugby story and the way you phrased: A big change is possible _providing the intent is good_. I have a similar experience with sailing. In my (limited) experience it also requires a steady hand – be consistent.
I believe a hybrid model can work – it depends at which level of granularity we look at changes. Through this work I notice changes sooner than most people in the teams I coach. So what may be a bunch of small changes to me, may look like magic (or a big change) to other people…
I also look forward to Agile Open – you never know what is going to happen at an open space event
. In the meantime I’m preparing for courses (going through my own change backlog from one course to the next 
) and waiting for a longer running coaching or consultancy gig. Hope you are doing well too. Willem.
May 19th, 2007 at 1:00 pm
[...] to “Small change“. Thanks, [...]
May 31st, 2007 at 7:03 am
Thanks for your reply Willem.
If the group agrees we can discuss this matter further at the event.
We can maybe focus on that one sentance ‘I learnt that you can get people to do extraordinary things under tough conditions providing the intent is good’.
Jamie
September 14th, 2007 at 5:02 am
[...] about this topic. three people who have influenced me quite a bit on this issue are jack mezirow, virginia satir, and scott [...]
October 30th, 2007 at 7:32 am
[...] process of transformation itself can be done in a steering way, for instance by using a change backlog. It helps if one knows, for instance by experience, where to look. Because we don’t have a [...]
November 21st, 2008 at 8:44 am
I love the stick-people drawings on this page. Would you consent to their being used for non-commercial (educational) purposes in a presentation? If so, please advise on how you should be credited.