As the title of Kent Beck’s book “Extreme Programming Explained: Embrace Change” highlights, change is at the heart in Agile software development. Agile techniques like XP and SCRUM focus on the people and how those people interact when they develop software rather than pre-scribing how this interaction will occur. This is done through continually allowing the team to review and improve the way it works to deliver software better and faster. In SCRUM the primary tool for instigating this change is the retrospective. I have taken part in many retrospectives both as a facilitator and participant and have found varying degrees of success. Issues include
· Denial by the majority that a problem exists
· Resistance to change as it is seen to ‘get in the way’ of delivering software
· Lack of commitment to making the agreed changes happen
· When changes have been implemented, the team slip-back into their old behaviours.
To address these issues I want borrow a tool from psychology called the Cycle of Change. It is used primarily in helping people with addictions but can apply to any change process. The cycle is illustrated below:
It proposes two key things
· there are several stages a person must go through before they successfully action and maintain lasting change (a stage cannot be missed).
· that change is cyclic, it can involve several tries before lasting change is implemented.
It is important to note that the techniques to move people from one stage to another are different depending on the current stage they are in. For example, offering solutions when a person in Pre-contemplation will not help whereas if they are in Determination this could be very productive. It is therefore very important to identify what stage a person is in when they are confronted with change.
Applying this to a team I have put together the following table that could help identify what stage the team is in and some approaches to dealing with the team to help them move to the next stage.
|
Stage |
Attitude |
Strategy |
|
Pre-contemplation |
Surprise, denial, excuses and scape-goating |
· Make aware of defensiveness
· Do not offer advice
· Gather information and feedback |
|
Contemplation |
Ambivalence, unsure of value of change |
· Do cost benefit analysis
· Create belief in teams ability to enact change |
|
Determination |
Motivated to change, questioning how to do it |
· Strike while the iron is hot!
· Articulate and discuss choices
· Derive action plan
· Identify metric(s) |
|
Action |
Implementing change |
· Cheer on
· Fully support the implementation |
|
Maintenance |
Sustaining change |
· Measure and review metrics regularly
· Set expectation that relapse is likely |
|
(Re)lapse |
Re-emergence of old habits, failure to hit metrics |
· Identify strategies to prevent relapse
· Avoid demoralisation
· Re-state consequences of not implementing the change |
|
Lasting Change |
Change has become habit |
|
I have found that retrospectives are very good at moving issues that are in Determination stage to the Action stage, but do not cope so well with moving teams through the other stages in the cycle. This tends to driven by the team deciding what issues they wish to deal with at the end of each sprint. These weaknesses could be addressed by ensuring that important issues are not forgotten about by highlighting them during subsequent retrospectives. Suggestion include
· Provide analysis to the team that demonstrates the need to change regarding issues where the team are in the Pre-contemplation or Contemplation stage
· Summarise performance against metrics to highlight potential relapse and reaffirm success for at least six months after the change has been implemented.
However try to avoid forcing a team to make a change. Change will not be effective if the team have not taken ownership for the change.