Change in action

My last post on the Transtheoretical model was a quick summary of the basics of the model:

• Stages of change
• What to do in a stage
• Self-efficacy
• Decisional balance

I am going to try to give some more applicable examples of the theory in action. These are subjective interpretation of my experience, if you want to read empirically validated studies of model check out the references in the last post.

Introducing change

"A sense of urgency", or "the burning platform" are phrases often used as summaries for how to kick off change. Honestly, if the floor was on fire, I would feel a sense of urgency and we would be changing pretty quickly. This often doesn't work so well in organisational settings. The executive burning platform is probably not shared with the people who ... um ... do the work. I think this is particularly so in IT, especially with the great job market.

From a TTM perspective senior management may be well into preparation or action, but the rest of the organisation is in precontemplation where the what to do is "raise awareness".

As leaders get amongst the work and the people doing the work. Look at what is happening and let the people know about the organisational situation and what they can do to help. Take down the motivational posters or the awards or the press releases and replace this will real data that affects the day to day work lives of the people who need to change.

The information and education needs to be situational. I am currently working with two groups trying to adopt some new practices. For one group there is great technology and industry support for what they want to do, for the other they will need to break new ground. The education for the two groups is quite different, the former is more on "how, with a little why". For the latter it is much more about "why", focusing on the principles behind the change, the benefits to them and their work. If I take the same approach with both groups one would never get out of precontemplation - of course there is no certainty they will anyway, but let's give them the best chance.

Group 1

• Good technology support
• Good industry knowledge
• Expect a reasonably quick shift in decisional balance and self-efficacy due to this external validation of the change - will vary on an individual basis

Group 2

• Poor technology support
• Bugger all industry knowledge
• Expect to maintain high self-efficacy and no change in decisional balance as "no one else has done this, so why should we"

It's not that the change we want to adopt is not beneficial but there is no burning platform. There is no urgency for these guys if there was other people would be making the change. If we can get an understanding of the benefits of the change then the decisional balance may shift and we can get some movement.

Starting to change

If we get through precontemplation - maybe it's been mandated that people change what they are doing, that's always effective - then we need to help people get through contemplation.

Contemplation is where the decisional balance is pretty even, and the self-efficacy is low. For example if you want to introduce a new way to estimate (or get rid of estimation) for projects then just about everyone involved is going to be feeling uncomfortable. You'll probably hear this like "Why don't we just do this the way we always have?", which is ok because change is hard. Now it's time to "roll with the resistance", don't confront it.

In a team we want people working together so if you attack someone who is feeling out of place then you lose part of the team, it's a bad choice. Focus on any ambivalence, use the data/information you have used before to help work through precontemplation. Explore the pros and cons of staying the same and the pros and cons of changing - for example talk about what happened with projects that were estimated in "usual way" what was good about that, what was bad, focus on the principles behind the change rather than the mechanics. Let the individuals decide to make the change.

Getting going

Preparation needs to focus on small steps to help people build in their self-efficacy. If you want to adopt XP it's going to be very hard to adopt all the practices over night. In an organisation there will be existing social, process, environmental and technology moderators to any change, so you need to create some success in this complex environment. Having senior organisation support can be very helpful in clearing blockers to change, but few senior managers are going to be blindly courageous so you need to give them some evidence the change will work.

When taking action make sure you have something to measure with rather than just imagine everything is going great. Demonstrate the progress and check on whether it is growing.

TDD adoption for example can have some simple steps of just having a simple test written in some example code rather than aiming for a unit test coverage from day 1. The success of setting up the unit test framework and then writing test, executing the build to watch the test fail/pass gives someone some obvious success with this practice that can be built on.

Once you are going be ready for the grinding halt of relapse. This will happen and it will happen a few times.

Back to the beginning

I am waiting for you, Vizzini. You told me to go back to the beginning. So I have. This is where I am, and this is where I will stay. I will not be moved.

Relapse will happen, be prepared. Learn from relapse, look at what was tried, why didn't it work, what will need to be different.

In an organisation there will be many potential causes for this, perhaps it's a time constraint, or how bonus structures are put in place.

From my experience tracking delivery is a common area of relapse for teams trying to change. When organisations are used to committing to dates and scope and dollars the change to measure delivery in contrast with measuring the plan is very difficult. Relapsing to old ways of thinking and behaving is reflected in commitment based planning, extended hours, tracking partially done work. If you know this is going to happen then you can be ready for the event, accept it and be ready to demonstrate the side-effects.

The way we work

Maintenance and termination is what we are aiming for, and this requires long and sustained effort. Building on small successes and adapting from failures is hard work.

In my last post I had "party" as what to do when you have made it to termination. This is rather facetious as in termination the change is part of normality and how often do you have a party for the run or the mill parts of life?

For teams adopting agile practices you know you are in these stages when people feel uncomfortable when not working collaboratively. For example no one person on the team will estimate a piece of work, when the teams starts a new delivery they want to talk about it with the customer/product owner to get a good understanding of the why and what of the delivery.

Resistance

In the TTM framework resistance can be understood as a mix of the stage of change and decisional balance. People who are in precontemplation - not thinking of changing - that suddenly have some kind of change thrust upon them will be extremely unwilling to change not because they are necessarily people who won't change, but they think the cons of the change outweigh the pros. From this perspective it's easier to work with people in precontemplation as the situation is depersonalised and have a less confrontational discussion.