Dave Stokes' Blog

In this blog I’m going to talk about the real-world challenge of identifying risks on projects and the way to deal with them. In the world we live in, risks are ubiquitous and we know from experience ignoring them is eventually going to lead to unwanted consequences. If you Google “risk proverbs” it will return a whole list of great quotes for embracing risk to fulfil your dreams and ambitions. Taking risks can bring rewards, but before you embark on something, it’s worth understanding what the dangers are and what to do about them.

On projects, it’s very easy to ignore thinking about them, assume (or hope) that it’s going to be fine and just focus on the here and now. This is not how we live our normal lives. You don’t go to work in the morning hoping you have enough fuel to get to work. You probably check the fuel gauge when starting the car and as a failsafe you have a dashboard warning light. You know you need to get to work, how far it is, how much fuel you have, so the risk has been resolved with those simple checks. Whilst cars are very similar, the nature of projects means each one is often unique, so I’ve built a cheat sheet to call out areas of projects that are susceptible to risk. It applies to Business Intelligence projects, but you could easily adapt it to suit others.

To use the cheat sheet the project team should work through the list and discuss each item. For each one, is it known, understood, measurable and achievable (applying SMART criteria is a good approach). For example, “Time milestones”, do we have any and if so, do we know what’s required to achieve them, how do we know if it’s on track and what are the factors that affect it. The team can then discuss and agree if it’s a possible risk. Using the poker planning cards to score it (1-Very risky -> 13-Piece of cake) will help to ensure everyone’s views are gauged and we are not just going with the strongest opinion. If there is ambiguity and you don’t have an irrefutable reason to ignore an item it’s got to be on the risk radar.

There are always intangible and unknown risks, but at least we have done the due diligence to check on what we do know. Now that we have our candidates, if it is a genuine risk that can’t be avoided, score the likelihood of it happening and what is the impact.

Now that we “can see the wood from the trees” we can apply one of the standard techniques and ROAM through the list. Spend your time on each risk, proportional to its combined likelihood and impact.

With ROAM risk has the four following states:

R – Resolved, O – Owned, A – Accepted, M – Mitigated

If a risk has no ROAM status the project team should discuss whether action can be taken to resolve it altogether, reduce it with mitigation, accept it or work out what action needs to take place to get one of the first three outcomes. Actions are owned by a person with a deadline to carry them out.

So, going back to the earlier example and applying ROAM, if I’m not sure I have enough fuel to get to work it’s a risk. If I checked and confirmed I had enough fuel, the risk would be resolved. If I don’t know what fuel stations are on the way to work I will own the risk to find out if I can get to station before I run out. If I know that I can reach a fuel station, I know the risk is mitigated. If I don’t know where the stations are and I don’t check, I’m accepting the risk knowing I will probably be OK.

Risk registers are living breathing documents that should not belong in a cupboard. The project team should pre-book regular meetings to review owned risks and how they are progressing. Also check the mitigations are still valid and in place. Flicking through the risk cheat sheet also helps to avoid complacency. If you have come up with every risk you can think of, resolved and mitigated as much as it is possible within the project constraints, then you can sleep soundly, knowing that you have prepared all you can.

The people who regularly do risky things and get away with it, are the ones who have prepared the most, done their homework and eliminated as much of the risk as possible, so only an unknown or an unlucky event is going to catch them out. As the golfer Gary Player always said “the more I practice, the luckier I get.”

Most will know that a pow wow is a native North American term for a social gathering. It originated from the Narragansett tribe of Rhode Island, where it means “spiritual leader”. The output of the gathering is an agreement on a way of behaving or interacting between the participants. In Latin, it’s referred to as modus operandi, but from an agile Scrum perspective it’s better known at the Way of Working (WoW).

In a previous blog called Scrum Insanity, I introduced the concept of a sprint cheat sheet to avoid basic errors from creeping into sprints. The sheet effectively is a gating process for functional sprints, so that during each project meeting, we can check we are not overlooking any risky behaviours. The one thing it did not directly address was the WoW. The WoW is critical to how a project can be delivered as smoothly as possible. So as the spiritual leader (or this case superhero) it’s critical you smash the WoW as quickly as possible. If the picture below means nothing to you, you’ll need to google “batman pow” to see the awesome TV effects of the 1970s, but failure to Pow WoW will allow villains to creep into the project.

Finding a WoW involves building rapport, confidence and trust in the project team. This begins the when you meet the client for the first time. First impressions are critical, so you need to have mobilised and prepared everyone for the project. You must be professional from the get go. The next thing is communicate, communicate, communicate and the best way to do that is face to face. That does not mean you should do all the talking. You have two ears and one mouth, which is a good ratio for how they’re used. Make sure everyone in the meeting has an opportunity to raise issues or concerns. As the various topics are covered you will understand the client’s etiquette; how they talk, their level of formality, how process driven they are, their general demeanour and even what banter they engage in. Topics to cover would typically be:

Introductions – Roles and responsibilities.

What is the purpose of the project and what is it delivering

How you run projects (in this case the Scrum methodology)

What meetings are required and how they are undertaken

How the project team interacts (i.e. rules of engagement)

What additional artefacts the client requires

Environments (technical like servers and physical like working locations)

Stick to your project processes as much as possible, but try to accommodate the client’s needs as much possible earlier on, especially if they are not familiar to Scrum. Once the WoW is working, the client may be more accommodating to doing things your way. If they are pulling you away from your process, remind them that the further they drag you away from the norm, the more unfamiliar and inexperienced you will be. There is a reason why pilots are all trained the same way.

Capture and document the WoW and then get to it. It’s important to emphasise that it’s not us and them; it’s one team that succeeds or fails together. Run the sprint retros after the first sprint (or sooner if required) to refine the WoW based upon how things are going. Keep doing the retros until all parties are comfortable that it is working. Once this happens trust and confidence in the team grows and the need for some of the additional project artefacts recede.

I have another cheat sheet to help guide me through the project process. Yours may be different and that’s OK, so long as it helps guide you through the process of establishing the WoW. So much like the Indian pow wow, the Pow WoW should be a convivial, almost social interaction so that the project can be successfully delivered as pain free as possible and there may even be the odd joke or smoking of the pipes of peace.

When agile projects go wrong it’s often not a single massive mistake, but a series of small ones that get compounded into something much bigger. Common reasons include:

Forgetting to follow the basics

Lack of communication

The Way of Working isn’t working

No surprises there, but why do we see it happen again and again? I’ve often been told that the definition of insanity is doing the same thing and expecting different results. In fact, the legal definition is the ability to determine right from wrong when a crime is committed. This means if you are not learning and making changes, you are either insane, making original mistakes or you’re doing something criminal.

By running sprint and project retros we can establish what we should and shouldn’t be doing on projects. It is often very simple to follow but it’s hard to remember it all. But this isn’t exam conditions, so we can build a sprint cheat sheet to help. Building one is simply an iterative process of grouping the output actions of retros for each of the sprint activities. I’ve included my own one, that’s evolved over time.

For each activity, we go through all the bullet points to check that we’re not falling into any obvious bear traps. If we are, we then agree as a team whether to mitigate or accept the risk. The risk points are totalled up for the sprint (one for green, two for amber and three for red), so that we know how risky the sprint is. I think of total risk points, as the height of a swimming pool diving board. It’s OK to jump from 10ft or below, but it starts getting scary above 20ft.

If you are exposing a sprint to lots of risks, make sure the client signs up to that. Retros are a good time to reflect by consulting the check list and see how many of the risks hurt the sprint. One area I’ve excluded from this blog is the wider project, particularly around project kick-off and sprint 0. Both are critical to agreeing an initial Way of Working, but I’ll cover that in a separate blog.

Another top tip is to print your cheat sheet on A5, laminate it and make sure the whole project team have a copy. You can even run all the sessions using the cheat sheet as a checklist. As a minimum capture and communicate the total risks points for the sprint. It takes 5 minutes a sprint; chances are it’s less than an hour for the whole project. To have a simple way to mitigate so many possible project problems, surely, you’d have to be insane not to use the cheat sheet.

On our Agile / Scrum projects, we found we were suffering from the same issues coming out of Sprint retrospectives:

We overlooked many of the important events in the sprint

Not everyone was engaged

They were taking too long

Having carried out a retro on the retro, we now have a new approach with the sprint poker planning cards. We go through the list of questions (see table below) and score on how we feel about each one, using the cards. The scoring is as follows:

1 – Mad

3 – Sad

5 – Ad(equate)

8 – Glad

13 – Rad(ical)

? – Don’t know or not applicable

The planning cards will remain hidden until all the team are ready to reveal. We then question the outlying scorers and discuss / re-score until we have a consensus value. Scores of 5 are ignored but for the others we agree what went wrong / right, why and the action. The lower the score the longer you should spend on it, to work out what needs adding to the start-doing, stop-doing and keep-doing lists. The high numbers can also be discussed in order to identify potential learnings for future sprints \ projects. The list of questions are:

Understanding of what’s going on, planned and blocked (Communication)

Operating as a single team; pulling in the same direction (Teamwork)

The assumptions the sprint was based on were accurate (Information accuracy)

Did we know what the sprint success criteria looked like (Definition of Done)

The approach makes everyone think about each of the questions and must come up with a score that they can justify. Doing this engages everyone and targets all aspects of the sprint. We find calling out the outliers is key as it can quickly help identify way of working issues. The retro takes about 30-40 minutes.

I’d recommend adding the actions into your risk log, so that they get followed up in the subsequent sprints.

We have also expanded the questions to cover a project implementation review / retro. Get in touch if you want more details of what they are.