At my company’s recent Agile Community Forum, we discussed whether all software development could be run using agile methodologies and frameworks. Should organizations instead be looking at a bimodal strategy, where some delivery still uses traditional methods such as waterfall, some is agile, and some is maybe a hybrid?

This led us into a debate about the key benefits of using agile and which methodology we would select or recommend. One of the factors in the decision on which methodology your team might choose is how to manage risk. Managing risk was one of the fundamental inputs into the creation of the Agile Manifesto and drove a lot of discussion.

How does aligning to the Agile Manifesto help us with managing risk? Let’s take each of the value statements from the Manifesto and explore this link.

Individuals and Interactions over Process and Tools

Software development is a complex task that takes expertise and judgment. Members of a team must work closely together to solve the problem in front of them. Having many different perspectives, as you do in a cross-functional team, allows them to create and adopt many different personas, giving the solutions a much better chance of delivering real customer value despite this complexity.

Teams must also adapt and change based on the situation, responding to change. If the team follows a specific process using only specific tools, they will often struggle or respond too slowly when things must change. Worse, they miss their opportunity to innovate.

Because there is greater collaboration in agile teams over traditional teams, this in itself reduces risk. If your teams are working well together, there should be plenty of talking and workshops, which means that it is likely that most (if not all) risks will be identified. Risks are also identified early, as each story is elaborated on and planned for delivery. Emerging risks are discussed daily at the standup, and team members identify and take actions to reduce them as soon as possible.

Using collaboration to reduce risk can be illustrated by what happens during a good iteration planning meeting. Test professionals will assess risk to make sure that the correct testing techniques are used and that the right test coverage will be achieved for the user story or product being implemented. The developer will add information that strengthens test coverage and reduces risk by talking about how they will implement the solution and how any technical risks are overcome. The business side will provide context for how the end customer is going to use the product, which helps clarify what must be built and tested.

All these individual viewpoints make for more accurate implementation and test coverage. Testing is a risk-mitigation strategy, so making sure the right product is tested to the right level reduces product risk. 

Working Software over Comprehensive Documentation

Producing working software on a continuous basis at the end of each iteration already reduces product and project risk by allowing the business to give feedback regularly. However, we need to be careful to define “working software” correctly for this to work. Sometimes software is created that works, but it may not give customers benefit or value. We need to make sure our definition of working software includes these attributes to reduce risk.

Of course, producing software in smaller chunks is easier to plan and manage, reducing risk further. Again, the feedback loop is much quicker when we do this. Instead of waiting weeks or even months to start testing a new feature, testing starts the next day. These small chunks are then integrated to produce potentially shippable code that can be released to production almost instantaneously. Creating software in small chunks is about building quality in rather than trying to test it in. The earlier a defect can be found, the cheaper and quicker it is to fix, and this reduces risk, too.

I think that we can safely say that writing a comprehensive document is not inherently going to reduce risk. Yes, the process of writing documentation, coupled with collaboration, may allow us to identify some risk and work out how to mitigate it, but comprehensive documentation is difficult to keep accurate, and that actually increases risk.

Agile encourages discussion over documentation for things like understanding our requirements. Requirements are written in the form of a minimal user story using the three C’s—card, conversation, confirmation—to make sure the requirements are understood. This approach reduces risk, as it is less likely that requirements will be misinterpreted when the team has the same conversation at the same time instead of reading lengthy documents someone else wrote.

In agile, we only classify a user story as done—in effect, is working software—if it has been accepted by the product owner (PO). That means that the PO agrees the software is functionally and nonfunctionally working and is adding value to the customer. At the time of release to production, some if not all of the risk of delivering the wrong things is reduced. 

Teams often also build minimum viable products to gain early feedback from end customers. Doing so means that we get faster feedback loops from both our internal and external customers, reducing our risk. Agile helps you find out very early whether your customers like your product, allowing you to pivot if they do not.

Customer Collaboration over Contract Negotiation

In traditional projects you may have interaction with the customer at the beginning, when requirements are being written, and at the end (sometimes a year or more later), during user acceptance testing (UAT). And that is if you are lucky; sometimes the testers even represent the customer during UAT, too. So, the first view the customer gets of the product is when they are using it to support their business or using the functionality as part of a product they have purchased.

When you stand back and think about it, this has always been a high-risk strategy because you are not mitigating any risk at all throughout the project. The scope was set at the very beginning of the project, when the least was known about the product or how it would be successfully used. Even when the product started to be developed and the team realized that something needed to change, this resulted in a change request. Often, doing the analysis for these change requests and involving all related parties cost more than actually making the change!

In agile, we recognize that things will change as we learn more about what we are building, and we adapt to new knowledge and information we discover. In order to be effective, contracts in agile delivery need to be written to support this adaptation. This means we must all work together to continually manage risk and reduce it as soon as it gets identified.

The continuous involvement of actual customers—not just customer proxies, like the PO—builds a better product that is fit for its purpose. As they are available, involving customers in all ceremonies (including daily standups) can reduce more risk, because the team can have discussions with the customers continuously and immediately about how to address risk.

Responding to Change over Following a Plan

A common myth in agile is that we do not have any planning. In fact, we are probably doing more planning activities in agile—it’s just not done all up front, when we have very little understanding of what needs to be built.

Instead, in agile we are planning and replanning on a very regular basis as we enter sprints, refine our backlog, and talk daily at standups. Doing planning this way makes sure the entire team is aware of what is being done, what changes are proposed, and the rationale behind why we are changing things. Planning continuously also involves the whole team, including all viewpoints so that the best decisions can be made.

In effect, this means that risk is being identified, analyzed, and mitigated (or at least planned to be mitigated) on a daily basis.

The graph below demonstrates the difference between risk reduction in traditional and agile software development approaches:

With traditional methods, you are betting that end-of-lifecycle testing will identify and give your team sufficient time to correct all risk, but history has taught us that this seldom happens. How many organizations have you seen in the news because their website crashed, payment processing was not available, or mobile app ratings were poor?

Under the agile model, you are incrementally reducing risk with every iteration and release you do, mitigating risks as you go. The fast feedback loops allow you to further reduce product risk by delighting the customer with what they value and what they need.

Agile gives risk visibility throughout your delivery cycle, from inception to customer delivery, so you can continuously eliminate waste from your processes and reduce risk as you produce your products.