Agile Risk Management

By: David Hawks | Nov 30, 2017 |  Scrum,  Video

We handle risk in Agile differently than how we handle risk in traditional development. Because there’s more visibility into the risks, we are better able to mitigate them and deliver quality software. In this video, David Hawks explains the difference and why Agile can reduce the risk of delivery and increase predictability throughout an agile development.


Video Transcription (has been slightly edited for brevity and clarity):

Traditional Waterfall Risks

Hi, I’m David Hawks with Agile Velocity and today I’d like to talk to you about how we handle risk in Agile differently than how we handle risk in traditional development. In a traditional waterfall project, we start off with requirements, and then from there do design. Say this is a five-month project—we do a month of requirements, a month of design, two months of development and then we do testing at the end. Let’s say you’re the project manager and we get to the end of requirements phase and all of them are done and everyone had reviewed and signed off the document. Is the project green, yellow or red? We will probably report a green status. End of the design, end of month two, we’re still green. We get to the end of dev, all the code is done and checked in, the build is passing, so we report again that the project is green.

What is going to happen halfway through testing? We’re going to report we went red. Why did we go red all of a sudden? The reason is that this is the first point we’re validating anything upstream—that the code works, the code didn’t break anything else, that it meets the design, that it meets the requirements. And all of a sudden we’re red, we go to the management team and they’re like, “Oh my gracious, what happened? You’ve been reporting the project is green for 4 months. At this point, we told everyone we were 80% done.” What were we 80% done with at this point? We were 80% done with our plan, our schedule, our budget. But we’re probably not 80% ready to ship. We don’t have 80% of the features done.

So what we would do in the middle of the test, all of sudden, what are our options? We’re two weeks away from the delivery date, what can we consider to salvage our project? The options are things like add more time or extend the date. We could test less or fix fewer bugs. We won’t get as high a quality product out. So really what we’re doing at this point is sacrificing quality. Time and quality are our main levers. Some people will say, “We can cut features.” But can we? We’ve already done all the requirements, design and development. The features are there, we can only hide those features or not test and deliver those features with quality. We can throw more people at it. But that will probably affect quality. If we pull people from another project, it’s affecting the time of that other project.

The Risk Iceberg

These aren’t good options. And the reason for that is because we have what we call the “Risk Iceberg” problem. Every project has risks, but the problem is the water line is up there and we cannot see below the water line. We’re up here and for 80% of the time, all we could see was the tip of the iceberg. But then, when we got to test, all of a sudden, we look underneath the water line and we see that there’s a whole lot of risk. There’s a whole lot of issues, those risks show up in the form of defects and bugs. We find out that thing was there the whole time, we just didn’t see it because we’ve been working in a way that’s focused on assuming all our requirements are right and assuming our design is right and assuming our developers would write good code. Then we’d just have to verify it at the end. But the problem is that we’d get to verification and we’d fall on our face.

Agile Risks

How do we solve this from an Agile perspective? We’re going to work in sprints. The goal of the sprint is to get to a potentially shippable product increment. The way we do that is complete requirements, design, dev and test every single sprint. Every two weeks we’ll get something tested and fixed, we’re going to fix the bugs so that we’re going to get a potentially shippable product increment every two weeks. Principal 7 of the Agile Manifesto says that “working software is our primary measure of progress.” If we look at working software as our primary measure of progress up here, at the end of requirements, we had 0% working software, we had 0% at the end of design, and 0% working validated software at the end of dev. In waterfall, we said we’re 80% complete, but in Agile, we’re 0% complete because we have nothing of value we can deliver and we’re 4/5 of the way through our plan and we have no value.

But in Agile, we’re going to work on features and get them done-done at the end of every sprint. and if by the end of sprint 1, we finish 2 of 10 features of similar size, we would say we’re 20% complete and mean it. And if we finish at the end of sprint 2, 4 out of 10 features, we could say we’re 40% done and mean it. We could ship 40% of the functionality right now because it’s tested and working. And that allows us to engage with our stakeholders and potentially change the priorities of the things we haven’t worked on yet, it allows us to deliver value earlier. It has a lot of gains, but one of the biggest gains is that it leads to predictability because we don’t have the risk iceberg problem. Evey sprint we’re assessing the risk, we’re doing the testing in every sprint and looking under the waterline and we’re able to mitigate those risks. We usually mitigate bugs by fixing them and closing bugs to make sure we have a good quality state very sprint. If we do that, if we’re 4/10 features and we’re halfway through the schedule, then we’re probably yellow. We’re not green, we’re not on track, but we’re not necessarily way off track either. But we have an early warning indicator which allows us to mitigate risk.

Let’s look at our options if we get behind in an Agile initiative. First, we could reduce scope. We’re  gonna push 2 features to our next release or sprints. We could add time, add another sprint into this release. But what we don’t have is a sacrifice of quality. That’s not an option because we’re investing in quality all along. And by investing in quality all along, that’s what allows us to reduce the risk of delivery and allows us to be more predictable throughout an agile development.


2 Responses to “Agile Risk Management”

  1. Kirsti van Wessel

    Having done waterfall for years, I do not agree that the risks will not show before the test stage.
    I have always from the first phase on estimated risks, trying to get them out of the way before we even get to testing.
    You are giving a false view of how this is done.
    We can already see where we think we hit problems from requirements (think of support-ability, at which point I would reach out to the BU and support to see what product planning is, and if we need a support exception)
    Mind you, this is implementation of existing software.

    For writing software, I would even in Waterfall, keep track of much more than money and time.
    Especially when you are working on t&m basis, you can involve the customer, and as part of the deal define MVP(s)
    Also there will be active Change Management to support the risks we think we can see coming during development.
    I really feel you give a very bad example here.

    • David Hawks

      You are right. I definitely am over simplifying Waterfall in the video to the extreme case. I agree that in waterfall we do lots of things to try and identify and mitigate risk as early as possible. The main point is there is nothing more valuable to mitigate risk like getting working tested software as early as possible. Pre-agile I even did iterative waterfall where I would bring testing in much earlier into the process in order to mitigate the risk of finding defects late. That is why in agile we say “Working Software us our primary measure of progress.”

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back