The Agile Project Manager—Viewing RISK Through a Different Lens

This post was originally made in June 2010. However, I wanted to make it part of my “Agile Project Manager” series, so I’ve updated and extended it a bit…hope you enjoy v2.

I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMP’s in the audience the more spirited the discussions become.

One of the core translation areas between traditional and agile project management relates to risk management. I often get a lot of pushback from the PMP’s telling me that the agile approaches to risk management simply won’t work. Their arguments are more based on traditional thinking, PMBOK guidance, and “we’ve always done it this way” pattern; rather than a situational response to individual project needs. I usually just leave it that agile risk management is “different” and move onto safer topic areas. But I usually want to add more flavor and this post seemed like a good opportunity to do so.

Traditional Risk Management

In this view, the Project Manager is managing the risk. The premise is that you need a highly skilled and experienced PM to adequately control and manage project risks. That risk can be anticipated, planned, reduced, avoided, transferred, positive, triggered, and mitigated.

One of the first activities with any project is to begin the compilation of a risk list so one can manage the project risks. These risks can be gleaned in a wide variety of methods—team brainstorming, speaking directly to key stakeholders, analyzing previous projects, and from the technology and business climate.

Once identified, teams often evaluate the size of each risk. A common mechanism is to gather likelihood and impact from the project team, then multiply the likelihood of the risk occurring against the impact the risk would have. So, something like the following table—

Potential Risk	Likelihood of Occurrence: 0 – minimal / none, 1, 2, 3 – Certain!	Impact of Risk: 0 – minimal / none, 1, 2, 3 – Project Failure!	Risk Priority
50% of technical team will leave for a competitive position	0	3	0
The open source LAMP stack will be acquired by Oracle	1	2	2
Chance we will deliver 100% of the agreed functionality?	3	1	3
System Performance will not meet requirement levels; only 50%	2	2	4
Business stakeholders will be confused on required features	3	2	6

Once you’ve accumulated a “complete” list of risks and analyzed their “priority”, then a plan is put in place to detect and mitigate the risks that are most likely to occur. Quite often, this is a very detailed plan that is formulated with all of the projects functional teams—expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

A Quick Point of Context

Oh, and I need to get this point out of the way. My primary context for this post is technology projects. If you’ve managed a technology-driven project, IT project, software development effort, or product integration project you will certainly agree that these beasties are “different” than other types of projects. And yes, their risks are different too. Rarely can you predict risks early on in these projects. Why? Because you simply haven’t done it before—so you have little to no experience with this specific type of project or technology within the team chartered with implementing it.

In my view, the variability in complex software projects is what undermines traditional risk management. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we know and don’t know with respect to our technologies–or specifically how do we design & code this particular widget. I.e. do some of the project work before trying to predict risk—so let the risks emerge from our design and coding efforts rather than trying to predict them.

It’s this focus on iterative, working code that raises agile software project risk management from conjecture to real-time risk discovery. So, let’s move onto agile risk management…

    

Reference for the diagrams

Agile Risk Management

The two diagrams nicely capture the essence of the difference in traditional (Waterfall) and agile risk management. In traditional projects risk essentially surfaces late—usually in the latter 20% of a project and sort of all at once. For agile projects, they’re much more front-loaded. Yes, for an identical project the same risks will probably surface in agile. So, it’s not a prevention mechanism.

This nicely leads into the essence of agile risk management being an emergent approach. First of all, you rarely hear the agile methods focus on risk at all. Why? Because we flip the notion of planning risk on its ear a bit. How is that? Well instead of guessing or planning for risk, one of the central themes of the agile methodologies is to deliver, real working software, in very thin slices of functionality via time-boxed iterations.

Realization of risk occurs quickly and abruptly. It hits you in the face as a team at the earliest possible moment. Quite often it surfaces in your daily stand-up meetings—so very little lag time.

Is it solely the responsibility of the Project Manager? No, in the agile case the self-directed team is primarily responsible for detecting, acting on, and mitigating risk…and here’s the important part, in real-time, as each risk occurs. It’s a whole-team and highly reactive stance towards risk.

The team often engages in strategies surrounding risk by how they approach iteration planning. They have the choice of what to build first, so very often the development strategy is to load risky items first—

• To complete research oriented user stories well in advance of delivering the related feature story
• To do early experimentation to see how the team will respond to technical challenges and the unknown.
• To measure the velocity of the team to understand their capacity to meet business milestones.
• To engage stakeholders in assessing requirements as they evolve…in real-time and on working software.

The Rework Balance

One of the most important aspects of agile risk management is effectively balancing your rework. This is one of the key indicators that your agile project is being run well or running off the rails. Agile teams have a tendency to either sprint too early, before they fully understand what they’re about to build, or they sprint too late, as they over-analyze the work.

Agile speed is a rework balancing act. If you have zero rework, then you’re playing it too safe. You analyzing everything in advance and taking no risk. For example, you deliver a fully operational messaging framework component for use without ever having sent a message through it. This is sort of that BDUF (Big Design Up Front) waterfall-esque approach to architecture. It appears less risky, but it isn’t. You’ve just delayed your information gathering on how well your strategy works.

But if you start too early, without even thinking about some of the dynamics of your messaging architecture, instead simply slinging code, then your rework is likely to be high. As you make discoveries in your testing you’ll need to go back and rework large swatches of your framework ideas.

So somewhere in between these two end-points lies an appropriate rework balance for each unique agile team. If they don’t think, then they’ll suffer from too much rework risk. If they go to slow, then they’ll not achieve the delivery and speed promises of agility. They’ll also still have rework—as they will not have anticipated every eventuality.

Wrapping Up

Now all of that being said, I don’t think we throw out all of the traditional risk approaches in agile contexts. For example, I think it a very healthy exercise for larger-scale agile projects to assess and understand the Top 10 risks they might be facing. In addition, to also look for more systemic or organizational risks and do a bit of up-front planning for them.

But don’t spend too much time there. Nor in exhaustive detection strategies or mitigation plans. Setup a straw man risk structure and then start leveraging the emergent nature of agile iterations to surface risks quickly. And once they surface, then ACT immediately on the risk that are real risks and not those you planned or anticipated.

Now for you traditional project managers listening in, I wonder if some of these agile approaches might be applicable in your current project contexts. I’d guess yes!

Don’t forget to leave your comments below.