Anxiety can be define as: “a future-oriented mood state in which one is ready or prepared to attempt to cope with upcoming negative events” or simply as “life on a product development team”.
One of the great benefits of an agile approach is the visibility we get into the real state of the project. Using working software as the measure progress makes the progress – or lack of progress – transparent. The transparency provided shows us the hard truth of reality – this can either help us work through our anxiety or make it worse when the ugly details of our actual progress compared to our desired progress become clear.
Given the above definition, anxiety is really our mood about the risks on the project. To manage our sense of anxiety on a project is to manage both the risks of the project and how we react to those risks. I’ll talk about how we manage the risks on an agile project – and I’ll leave up to you to decide how to manage your own internal emotional state. So, how do we manage the risks on an agile project?
First, we need to take a deep breath, have some faith in the agile process, and keep focused on doing the right things in the most effective way possible. Now that we have calmed down a little, let’s look at how we can deal with the risks.
1.) Review the prioritization of the backlog to ensure that we have the stories with the highest risk as high in the backlog as possible.
We want to address the risky stories as soon as possible so we have a better sense of the true impact to our project and the have most time available to adequately address any issues we find while completing those stories.
2.) Host a negative brainstorming session.
A negative brainstorming session is an opportunity for the team to get together and try to identify all the things that could possibly go wrong. In this session, we want to capture absolutely everything we can think of including scope risk, schedule risk, resource risk – and any other risks that are internal or external to our project. Don’t forget to think about stories that you may have over looked when building the backlog.
3.) Create a risk register
Using the output of the negative brainstorming session, we create a risk register that lists each risk the impact of the risk to the project, and the likelihood (probability) of the risk event occurring.
We can use the risk register as the basis for completing both a qualitative and quantitative analysis of the risk.
4.) Based on the risks identified – we want to develop a strategy for addressing each risk if it occurs — or better yet, structuring our project so remove the likelihood of the risk occurring at all.
5.) Make the risks visible.
We want to make the risks to the project visible and focus on reducing risk throughout the project. To do this:
We can create a risk board (information radiator) where we put each risk on a post-it note and paste these notes on the board.
We can add a risk burn-down chart to this to add visibility to the quantitative risks to the project. The risk burn down chart will plot the total risk (risk = impact of risk occurring * the likelihood of the risk occurring) on the vertical axis and time (iterations) on the horizontal axis.
Discuss the risks throughout the project: At the daily standup, at release planning, and during the retrospective.
6.) Address risks early and often with risk-based spikes to ensure we are gaining the knowledge needed to be fully informed about the technical risks and develop strategies to address these risks.
The uncertainty inherent in any project can cause a lot of anxiety on the project team. It’s important to have some faith in the process so we can deal with the uncertainty, ensure we are getting the best information possible, and recognize that knowing what is really happening on the project gives us the best chance for success.
Keep Calm and sprint on.