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.