Risk management versus the Impediment List
Posted by Eelco Gravendeel just before lunchtime: December 19th, 2007
Just the other day someone asked me: “what is the difference between managing risks and working the impediment list?”. At that time I didn’t get much further than "impediments may be risks and they may already be existing problems, but not all risks have to become impediments"… A correct answer in my opinion, but not a very clear or complete one. So let’s see if I can provide a better answer.
To answer the question we will have to establish a definition for both. Let’s start with impediments. Assuming we're doing Scrum as a way of getting the work done, an impediment is everything that slows down work or stops it completely. In other words, impediments are obstacles that have a negative impact on the sprints' velocity. Typical examples include missing or incomplete information about a certain user story or the lack of tools or hardware required to complete the work.
Risks on the other hand are possible events that, if they do occur, have a negative impact on the desired outcome of the project. Of course this includes events that impact sprint velocity, but are not limited to this. Negative impact can also mean some event causing a lack of performance in the final system to occur. For example, we assumed to be able to use a certain hardware platform to get the performance we needed, but the risk exists that the intended hardware just will not deliver the promised speed.
Note that something that is sure to happen (and has a negative impact on your project's outcome) is not a risk, but a problem! Problems always have to be dealt with, so put the required actions on the backlog. Dealing with problems is more like crisis management and not risk management. Whenever a risk materializes it has become a problem. Any mitigation work, required to handle the situation after a risk has materialized should also be put on the backlog.
The most important difference between risks and impediments is that risks are possible events and obstacles that could occur and impediments, in general, are already reality.
Now that we have established that there is indeed a difference between impediments and risks, we can now answer another question: “Why manage both and not just the impediments?”. Management of both impediments and risks is very important. Managing your impediments is pretty obvious; these are obstacles which are already upon us. The team is experiencing some sort of blockage which stops them from achieving maximum velocity. So removing these obstacles should make work go faster. This minimizes the risk of not meeting deadlines for major milestones or even the entire project.
Acquiring and managing risks is just as important as managing the impediment list. Although risks are not problems yet and may even never materialize, it is very important to know which risks there are and what you are going to do about it if and when they materialize. By determining both the impact of a risk after it should materialize and the chance it actually could materialize you can determine how important it is to manage a certain risk. You could choose to take actions to prevent the risk from happening (removing the risk) or do some preparation work which helps minimizing impact when the risk materializes. Note that some risks are just not worth preparing for. For example: If a space shuttle should crash on the building your team is working in the project will most probably fail, the chance if such an event happening however is close to zero, so you do not want to waste valuable resources in managing this risk. On the other hand, the chance that any team member comes down with the flu is very real. The impact is a delay in your project. If this is not acceptable you will have to do something to minimize impact when this risk materializes, such as overstaffing or adding more slack into sprint planning.
In Scrum the ScrumMaster is responsible for creating, maintaining and working the impediment list. The ScrumMaster is responsible for getting the items on the list resolved. Note that he/she is not solely responsible actually resolving the items, but at least should convene impediments with someone who actually can resolve that impediment.
Managing the risks could be a job for the ScrumMaster too, but as the project gets bigger or spans more than one team, there should be a Project Manager involved. It is then his/her task to get possible risks identified and manage the list. This is not the responsibility of the ScrumMaster since there are risks that supersede the span of control of one team. Next to that, the ScrumMaster is probably busy enough working the impediments, without having to worry about and take action to prevent things that could happen.
Archives
Training
- Workshop Agile Management
Custom made, in-company - Scrum for Team Members
Custom made, in-company
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
Hi Eelco,
I am not exactly sure what you mean by managing the list. I interpret it has: Take actions to make sure the possibility of such a risk becoming an impediment (or problem) is minimal. If this is the case shouldn’t this be the product owner’s responsibility? Or is the Project Manager in your example the Product Owner?
Hi Lars,
First: Your interpretation is right, Managing a list of identified risks means making sure they don’t become impediments (or otherwise nasty problems that prevent the project from succeeding). In a pure (software) product development company, managing risks could and ideally would be the concern of the product owner. In an environment where the product owner is not used to doing projects a project manager should fulfill this role. Not that the perfect product owner is almost like a super hero: guarding vision, ROI, managing risks, perfectly knows his / her business both internally and externally etc. etc. So in practice it makes perfect sense to have a project manager on board in both environments to help out with managing things like the list of identified risks.