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

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.

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.

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

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?

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