Agile Risk Management – Technical Risk

This is part two of a mini-series on risk management. Part one discussed how I think about business risk. This post will address some things to think about when considering technical risk.

Technical Risk

Technical risk deals with those unproven assumptions in your emerging design that might significantly impact your ability to deliver the solution. Are we planning to use any unproven technologies to build the solution? Have we exercised the significant interfaces between systems? Can we demonstrate a working skeleton of the system? What about performance? What about security? Any technical decisions not validated by working software count as technical risks.

Technical risk deals with feasibility. In other words, have we proven there is a solution that can be delivered within the time and cost constraints of the project?

Technical risk is also dealt with early in the project immediately after you have a handle on the critical business risks. This is where the team really gets engaged for the first time. You bring your resources to bear to build out the system and validate any assumptions you made during planning. The backlog should be prioritized with an eye toward technical risk. Build out those features early that are most likely to validate your architectural assumptions and stabilize your emerging design.

It is worth emphasizing here that technical risk should always be mitigated in the context of working software. We build features to mitigate risk. Proving interfaces, or that one system can talk to another, outside the context of delivered business value does little to prove anything or mitigate any real risk. Testing is an integral part of risk mitigation. Untested features deliver no value.

As we build features, we will certainly learn more about the architecture and more about what it is going to take to build out the proposed solutions. Stay open to this new information. Re-estimate the backlog if necessary. Share this information with your product owner. Allow them the opportunity to learn along with you and adjust their plans and expectations accordingly. Look for technical tradeoffs that will allow you to deliver within the agreed upon time and cost.

What happens if you prove there is not a solution that can be delivered within the time and cost constraints of the project? Sounds we’ve just identified a pretty significant business risk. Mitigate your technical risks early and ensure feasibility while your overall investment is still relatively low.

Click here to read my previous post on Business Risk. Next post we’ll address Logistical Risk