We need to change some behaviours!

Recently I've spoken to a few people who have told me "What we need here are some changes in behaviour", then they let me know what they will do to make these changes come about. It may be a new policy, or some kind of punishment/stick combination, it will certainly involve microsoft power point, but what ever the mechanism I would be amazed if it has the desired result.

Changing behaviour is rather difficult, and using a single device to achieve change will fail (maybe drugs or extreme violence would be the exception to this rule). This is because there are multiple factors that create behaviours, and a change to just one of these will not have much, if any, impact on the others.

The model below is by Edgerton & Palmer and is an attempt to show the interactions involved between five factors that have an effect on an individual. Actions (behaviors) is only part of the story here.

Social context - the where, what and when of the situation. The working environment is a constantly changing social context, from sitting at a desk and working alone to being in a formal meeting with colleagues to having an informal chat when making some coffee. As the other factors are effected by this they are also in flux.

Cognition - the thoughts of the individual will be as varied as the individuals. In different contexts and with different people these will also vary. In a situation where there are project managers playing a game of schedule chicken the thoughts will be a mix ways to defend their current plans to demonstrating the faults in their peer's plan - of course this would only happen in theory as all PMs are on the one team to deliver the best result for their organisation.

Emotion - apart from the emotions someone brings in the door to work, emotions will also be affected by many other factors. A chat with non-competitive peers will give more pleasant emotions than being in a performance review. Emotional responses are essentially responses to the other factors, but once fired up can create feedback into these factors.

Physiology - sleep and diet are pretty reasonable places to start when considering this factor (lots of over time and pizza will cause issues), but there are many other elements to physiology that may occur by situations at work. A stressful and aggressive exchange will create a physiological effect which may then create specific actions in response to this - heart rate up, adrenaline flowing.

Action - the thing we want to change, which is going to be a piece of cake when we consider the other factors.

All these factors can play on and build on each other, hence the double headed arrows.

Changing behaviours is not going to occur through power point, it will just add to the frustration of the person/people who created the power point presentation - probably making them angry, and they will then start raising their voices and being aggressive in meetings, finding their heart rate has increased and getting red faced, and thinking "why doesn't anyone listen to my perfect idea, they're all morons".

Edgerton, N. and S. Palmer (2005). "SPACE: A psychological model for use within cognitive behavioural coaching, therapy and stress management." The Coaching Psychologist 1(2): 25 -31.

Goals Goals

Goals are fantastic as standards or aspirational states for regulation. Using a goal as a way to set direction is a fundamental part of Scrum and I am seeing it more in generic "Big A" Agile. of course the goal needs to be the right goal, and if we are inherently goal directed organisms then we need to make sure everyone has their goals aligned.

Having learned some skills for project management the idea of managing a plan based on the original estimates (aka commitments) never seemed right to me. In this situation the goal is to make sure the plan is met, be that the dates/scope/budget. Ah hah! that's project management, the magic is to drive the team to achieve this result. Of course it's also utter bunk, it's hitting the target and missing the point.

My rough sketch above is an attempt to show what I am on about. An idea becomes a plan, then there is some action followed by measuring progress, then checking the progress against the plan. This assumes the plan and the idea are correct. With these two assumptions there isn't much room to make changes. This is a simplification and plans do change, but from what I have heard it's more about "updating" the plan than intentionally varying the plan and re-planning is a significant effort that is met with disapproval.

Now if we manage our work to achieve the goal rather than to follow the plan there is greater opportunity for changing what we doing. The second sketch shows this simple difference, that is to check progress against the goal rather than the plan. Each cycle through the action, measure, check and change needs to be treated as an experiment, where we learn what works and doesn't work to achieve the goal. In this scenario nothing is assumed to be correct until it is proven to help achieve the goal, and we can refine the goal as well.

Unfortunately within a traditional work environment this is a big change in thinking. Outside of a specific R&D team trying something that might fail is rarely approved. Changing this will be a significant challenge as structure of the organisation reinforces these ideas of how to view success.

Goals

Goals... simple stuff really. A goal is just something you want to achieve such as "get that job!", "get a promotion", "run the four minute mile". Interestingly there are some people who have made a career out of studying goals, weirder things have probably happened.

Austin and Vancouver (cool names for co-authors) define "goals as internal representations of desired states, where states are broadly construed as outcomes, events, or processes" which extends the discussion (and the career) on goals.

The upshot is that any person at any moment has multiple goals. Right now I have the following:

• Sit comfortably
• Write something sensible
• Don't let me right eye dry out - as it isn't closing properly
• Enjoy listening to Portico Quartet's Isla whilst writing this post

but wait there's more

• In the very near future I will need some sleep
• Right now I want to keep my body at a comfortable temperature and it's warming up in here
• I also want to read a few books that I have recently acquired
• Earn three stars on each level of Angry Birds (known in this house as Cranky Chickens)

This list could extend for a lot longer but it's boring enough.

So what? So everything we do can be interpreted as pursuing a goal. Whoop de do.

What if you want me to pursue a goal that's not on my list? For example you may want to change the way I work. Now we may have some difficulties as your goal may be discordant with my goal. Our first reactions in this situation are going to be interesting.

You - Lachlan just doesn't want to change.

Me - Why would I want to do that? What I am doing is fine.

Is this resistance? Rather than thinking in a confrontational way about the situation perhaps we could consider that we have competing goals and then we can start to dig into what these and whether they can be aligned.

Within the trans-theoretical model this conflict on goals is coming from one person being further through the cycle of change than the other. In my two line example I am in pre-contemplation, I think what I am doing is fine, I have no reason to change. It's back to raising my awareness of the alternatives and the limitations of the way I am acting/working.

Changing - conceptualisation

Earlier this year a colleague asked me what I would look for in a organisation considering adopting agile. Where would I stick my nose? (paraphrasing, she was more polite than that). Being a whiteboard junkie I grabbed a marker and drew the following.

Technology - what the development group create and maintain

People - organisational culture, teams and individuals

Process - how do they try to make the work work

Environment - what is the physical environment like to work in

The idea is that agile software development is influenced by these four forces/elements/modalities/thingies/horsemen. The conclusion of my 5 seconds of thinking is that if you want to adopt agile you need to have a good hard look at each of these and how they will influence the change.

I now like to think about this without "agile" in the middle of the picture - as I think the idea is more generally applicable without the A word there. How do these forces influence the way an organisation develops software (or do pretty much anything)? So something more like this (based on Greene and Grant 2003 - house of change).

I think each of these forces has a balancing influence on the others, so that a change to one will be pulled back by the others, a sort of equilibrium. Any attempt at making a significant or lasting change will need to take this into account. (There is an inkling about entropy too, but that's still in progress.)

For example making a change to "go Agile" may start with changing the way projects are run to work in iterations ie a process change. The organisational state before the Agile adoption came about from the influence of more than just the delivery process and none of the following processes have changed:

• Hiring
• Release management
• Funding/budgeting
• Organisational change

The organisation has been structured to support these processes (and many many more) and the original project process is part of this melange. There is now a foreign body in the organisational system and it may end up being treated as one.

What about the other forces?

Technology - no change. Unless there was attention to technical excellence before the process change this is going to hurt. Odds on that delivery to time and budget trumped internal quality.

People - no change. The same people, who may have been comfortable with how work was before the change, and the same structures to support the people. A culture that developed from how the organisation worked. Teams that may have competed now need to collaborate.

Environment - no change. Maybe everyone on the team is on the same floor or in the same building, but this is not real collocation. A nice open plan office - recommended over the alternatives - is not really the place for noisy exchanges of ideas, you end up having stand ups in a meeting room, story walls hidden in the computers so no one is disturbed.

What's the point?

To make a change you need to have a holistic or system perspective, unfortunately conceptualising the entire system is difficult. Making effective change is hard, even when there are no explicit forces against the change there will be tacit forces that will hold you back. No amount of analysis will reveals these forces so get going and expect to learn about these on the way, and make that explicit.

Greene, J., & Grant, A. M. (2003). Solution-focused coaching: Manging people in a complex world. Auckland, New Zealand: Pearson Education New Zealand; New Zealand.

Changes - ambivalence

Moving yourself into action can be challenging, helping some one or some people move into action can be bloody frustrating. The following is a tool from Tony Grant (dunno if he came up with it) to help deal with the ambivalence of change and try to get some one into preparation/action.

Start by rating the motivation for changing on a 1 -10 scale. Where 1 is "not likely matey", and 10 is "why are we having this conversation as I am on the move".

Use the following (crappy html) grid to explore the ambiguity of the change - better off with a white board, or something biggerer to review the items. Remember not to try to persuade, explore the ambivalence.

	Stay the same	Make a change
Positive	step 2. What's good about staying the same? Get it out and talk about it. Explore the hidden pay offs of not changing.	step 3. Dig into the positives of change. This will be the opposite of step one, but get into the details. Make the benefits clear and obvious.
Negative	step 1. Explore the downside of the change by brainstorming the negatives of the current situation. Don't dwell here.	step 4. Use this space to stick in a plan of action. If there are still barriers, explore these, get them out in the open.

then re-rate from 1 -10. There should be a shift, cease on this.

Here is a worked example. A team is considering increasing the unit test coverage in the legacy portion of a solution (ie code they did not write), there is "resistance" to doing this work and this is a look at the ambivalence around incorporating this work practice.

Motivation: 3

	Stay the same	Make a change
Positive	Quick to get the work done. Don't need to waste time reading through someone else's crap code. Only need to focus on my work and any new changes.	Learn more about how the entire solution works, perhaps there are opportunities for abstraction, decrease complexity or general improvement. Less brittle code base as the tests will support any refactoring. Decreased risk in enhancing or fixing the solution in the future as there is a safety net of tests.
Negative	Will never understand legacy code. Refactoring is very risky. Changes will take longer as time goes on.	As a start write some tests for what is considered the riskier parts of the solution, rather than everything. Expand on these whenever we work on the solution.

Motivation: 6

The tool is not a panacea, maybe there won't be a shift in motivation. Using the technique should help bring out more of the issues around the change, use these to help raise awareness and try again.

Enterprise Architecture

Having written no production code in the last few years I feel qualified to rave on about EA. Actually I don't really feel qualified, I know jack about it. I do know there are a number of people who works as EAs and how widely their work is ignored. So in the interest of efficiency here is the Enterprise Architecture chatterbox.

Folding instructions

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.

Changes

Transtheoretical model is widely used to help people make and understand change. The research for the model comes from health studies, particularly focused on drug addiction (e.g. tobacco). Some researchers have tested the model outside of the realm of addiction and found it to be a broadly applicable model for change.

The model integrates several theories - hence the name - and its core is a stages of change structure.

Stages...

Precontemplation - In this stage you are not thinking about change in the next six months

Contemplation - In this stage you are thinking about change in the next six months

Preparation - Making plans for change

Action - Executing the plans

Maintenance - Successful action over several month

Relapse - Reverting to old behaviours

Termination - New behaviour is natural

An important feature of this model is the open recognition of relapse. When making change there are is always the possibility of falling back into old ways, and acknowledging this gives you the opportunity to deal with it.

Many change theories have stages, Kubler-Ross's stage of grief for example, the advantage of TTM is that it you have guidance at each stage. Stages of grief for example can help you explain what is happening, but not what to do about it, TTM gives you more than "oh, I am bargaining now".

What to do...

Precontemplation - raise awareness, give someone the reason to change

Contemplation - an extremely ambivalent stage, play on this, tease out the tension, let the person make the decision

Preparation - plan small steps, you need to build on success

Action - support and encouragement, prepare for relapse - it will happen

Maintenance - support and encouragement

Relapse - this is falling back to another stage, it may be precontemplation, contemplation, use the techniques required at that stage.

Termination - pat yourself on the back and select a new goal

There a two other fundamental elements to the model (adding up to the transtheoretical name):

- Self efficacy

- Decisional balance

Self efficacy is how well someone thinks they can perform in a specific domain or circumstance. The degree of self efficacy an individual will feel across the stages of change varies and can be an indicator to where someone is within TTM.

Self-efficacy...

Precontemplation - High

Contemplation - Lower

Preparation - Lower

Action - Growing

Maintenance - High

Relapse - Low

Termination - High

What I find interesting is that self-efficacy is high in precontemplation. In this stage someone is feeling good about what you do and how you do it, you have no reason for change, so you "resist" change.

Transitioning into contemplation self-efficacy is lowered because of uncertainty about the new behaviours and no longer convinced about the existing behaviours.

As you practice the change through preparation and action you will build in your self-efficacy through small successes. Eventually the change is part of who the person is and how they act, self-efficacy is once again at its peak.

Decisional balance is about weighing up the pros and cons of change. Over the stages of change this balance changes.

Decisional balance...

Precontemplation - Cons out weigh pros

Contemplation - Pros and cons are equal (near)

Preparation - Pros start to outweigh cons

Action - Pros outweigh cons

Maintenance - Pros outweigh cons

Relapse - Cons out weigh pros

Termination - Pros outweigh cons

In important implication of this is that when you are thinking resistance it may be that someone doesn't see the need to change. The cons of change outweigh the pros, they feel effective in what they are doing, there is no reason for them to change.

Brief summary (in crappy HTML table)

Transtheoretical model
Stage	What to do	Self-efficacy	Decisional Balance
Precontemplation	raise awareness	High	Cons outweigh pros
Contemplation	work with the tension, let the person make the decision	Low	Pros and cons equal
Preparation	plan small steps, you need to build on success	Growing	Pros outweigh cons
Action	support and encouragement, prepare for relapse	High	Pros outweigh cons
Maintenance	support and encouragement	High	Pros outweigh cons
Relapse	revisit other stages	Low	Decisional Balance
Termination	party	High	Pros outweigh cons

Some light reading to kill off the insomnia

Velicer, W. F., C. C. DiClemente, et al. (1985). "Decisional balance measure for assessing and predicting smoking status." Journal of Personality and Social Psychology 48(5): 1279-1289.

McConnaughy, E. A., J. O. Prochaska, et al. (1983). "Stages of change in psychotherapy: Measurement and sample profiles." Psychotherapy: Theory, Research & Practice 20(3): 368-375.

Prochaska, J. O. and C. C. DiClemente (1983). "Stages and processes of self-change of smoking: Toward an integrative model of change." Journal of Consulting and Clinical Psychology 51(3): 390-395.

Prochaska, J. O. and et al. (1982). "Self-change processes, self-efficacy and self-concept in relapse and maintenance of cessation of smoking." Psychological Reports 51(3, Pt 1): 983-990.

Prochaska, J. O., W. F. Velicer, et al. (1994). "Stages of change and decisional balance for 12 problem behaviors." Health Psychology 13(1): 39-46.

Grant, A. M. (2006). An Integrative Goal-Focused Approach to Executive Coaching. Evidence based coaching handbook: Putting best practices to work for your clients. Hoboken, NJ, John Wiley & Sons Inc; US: 153-192.

Grant, A. M. and J. Franklin (2007). "The transtheoretical model and study skills." Behaviour Change 24(2): 99-113.

Ball point game - debriefing and options

The ball point game is a fun exercise to help people understand a whole bunch of ideas for agile/lean/scrum. I have been running the game regularly over the last six months and thought I would put together some variations I play with.

The game was invented by Boris Gloger but I picked it up from Rowan Bunning and you can read the instruction on Kane Mar's blog.

Most recently I have been running the ball point game after a discussion on continuous improvement as the game lends itself beautifully to this. After running the game as described in the links I like to ask the following questions:

1. Who had all the ideas?
2. What roles did you all take?
3. When something went wrong what did you do?

I haven't found a team yet that doesn't give answers like:

1. No one had all the ideas, we all suggested ideas and tried some out.
2. Apart from the person starting the cycle there were no roles.
3. We tried to work out how to fix what went wrong.

I then ask the team to compare this way of working with their usual delivery process, thinking about the three questions again.

Then ask about flow, improvement, reinforce the PDCA cycle ideas.

Dysfunctional forms

Odd balls

For running the ball point game I like to have a mix of balls. Various sizes, textures and weights. The variability greatly interrupts the flow of the team and several teams work out that as the balls all have the same value (one point) they might as well discard all but one type.

Debrief - the varying ball sizes are like varying sizes of requirements (stories, PBIs etc). With varying sizes it's difficult to create flow. As requirements are information there will be some variation but there needs to be effort put it to even these out to allow teams to develop flow.

Multi-tasking

As the team is going so well (after the 5th iteration) I need to take some people out of the team to help another team to do better, so these guys will be available part time. All rules stay the same and the part timers are considered part of the team.

To make this happen the part timers need to stand with their hands behind their backs when I say so - this is when they are working with another team. The team has 2 minutes to plan and give an estimate.

When running the iteration I watch the clock and call "out" to signal the part timers are to have their hands behind their backs and "in" for them to return to the team. The whole team stops when I call "out" and restarts when I call "in".

This is not a fantastic analogy for multi-tasking, it would be better to actually have two teams going at once and have these people on both, or have the people walk away from the team to give them as sense of task switching maybe I'll try that some time.

One team recently put the part time staff at the end of cycle, and when they were "out" the team put all the balls in a bucket ready for these guys when they started again. What happened was the bucket near the end filled up quickly, never emptied and the original ball source ran out of balls. This was interesting to debrief to help these guys see the problems of a push workflow with the throughput constraint on the end not having any control on what was coming in - dunno if I succeeded with that.

Debrief - multi tasking can really interrupt flow. People working on multiple tasks/projects/teams make it difficult to get work done.

Problem - this makes it look like people working part time are a pain in the butt for delivery.

Co-location

Another fun dysfunctional form is to stop the team from co-locating. Give the team the usual planning time but no team member may stand within 3 metres of another. All the rules are the same.

Debrief - it's harder when you are not right next to someone you are working with. It's more difficult to respond to what they are doing and vice versa. There is essential non-verbal communication that you can have when you are co-located that helps to enable more useful verbal communication.