Building a Transition Backlog

When we start work with a new team, we bring a fresh pair of eyes. We see many things that we'd like to improve and many problems to be addressed. Part of our job, as an agile coach, is to help the team to bring these opportunities and challenges into focus. Now we can work with the team to implement solutions that mesh well with the organization / context they find themselves in. In this blog, I want to share a technique that I use with teams to surface driving forces and barriers to an agile transition so together we can work out the most effective place to put our energy.

The basic technique is called "Force Field Analysis" and is derived from the work of social psychologist, Kurt Lewin. Though I learned about this technique from Esther Derby and Diana Larsen's book, "Agile Retrospectives." Where I've added a twist is that I use the information from a force-field chart mapped out with the team to generate an initial Transition Backlog of work items supporting an agile transition that coaches and teams can work through iteratively. Mike Cohn gives some excellent advice on how to work with Transition Backlogs in his new book "Succeeding with Agile" (see his blog for some basic pointers).

Mapping out a Force Field

Let's see how to assemble an force-field analysis chart with your team. To start, find a big surface to draw the chart upon such as a whiteboard or flipchart. Bring along plenty of markers and sticky notes so you can get the whole team involved in building the picture of forces in play.

As we encourage teams to tune up their practices, we understand that being Agile is usually not the real goal. Often there's an underlying improvement focus within the organisation that has lead the team to adopt an agile approach. Whilst we value the attitude of reflection on current practice and continuous improvement elements of agile approaches, we don't want to lose sight of the desired improvement.

Step one of drawing a force-field analysis chart is to identify the desired improvement and draw a big arrow at the top (from left to right) that represents the change from current state to desired state. Although this could be "Go Agile" it may be better framed as "Deliver Software More Frequently" or "Reduce Time Spent on Defects".

Now, divide the chart into two equal sized columns. The left-hand column is used to list out the driving forces for the change summarized in the big arrow at the top. For example, "Management support" or "Budget for training". The right-hand column is used to list out the restraining forces. For example, "Company hiring policy" and "Teams are too busy".

Encourage the team to contribute their ideas for forces at work on sticky notes. For each force identified, draw an arrow pointing to the dividing line between the columns. Use line thickness to indicate the strength of the force (see example from a training class below).

Generating a Transition Backlog

When the team is happy that the force-field chart adequately represents the forces in play, it's time to consider how you can amplify the driving forces and reduce the restraining forces. Each action that you can identify is a candidate for a "transition backlog" that the coach and the team can use to focus their efforts on changes that will move them toward their desired end state.

You can now use the chart to ratify your current coaching strategy by walking through it with key stakeholders and getting their take on the priorities of the items in your initial transition backlog. Senior stakeholders may add additional forces to the chart. Their buy-in is often crucial as you may need their support to help escalate impediments to the agile transition. 

Comments

[Dave Rooney]

Very cool! Could you see this approach working even at the individual practice level?

[Mike Sutton]

I love this approach - it is something that everyone can get round and once they understand the concept (which is really easy) they can contribute fully.

I like that it is solution focused and that you emphasise that the desired improvement is stated more concretely i.e. 'Deliver software more frequently' vs 'Go Agile'.

There is no doubt in my mind that these kind of visual thinking tools add huge value to surfacing the things that we can do better and improve the understanding of the vision (or help emerge one).

Thanks for sharing Rachel.