Risk Management isn't about fixating scope and budget anymore. It's about early and continuous validation. Making sure precious time and funds aren't spent on creating stuff that nobody wants. Making sure we keep up with constantly changing market and customer needs and facilitate the value adding teams to be awesome at this. Agile promotes managing these risks by doing the right things and doing things right.

Doing the right things

Early and continuous delivery

By frequently delivering a working solution, real users are able to give feedback based on a factual solution they can actually see and use. This is solving the ancient problem of the customer believing to want something specific, until seeing the actual end product and realizing this is not the solution to their problem. A working solution, even in the early stages of creation, is much more powerful than any design or mock-up. The sooner you are able to actually show a working product, the smaller the risk of wasting time on creating something useless.

For example Scrum promotes using actual usage data to substantiate choices within the Product Backlog for further development of the product.

Continuous validation

By working closely together with the customer, the team gets to learn what actually adds value for the customer and what doesn't. By continuously validating the solution to the customer's needs we can minimize the risk of the team working on the wrong stuff and the customer paying for a solution that doesn't fit expectations.

In Scrum the created solution is shown to the stakeholders at least every Sprint to gather feedback. The Sprint Review gives everyone a chance to adjust course in case a wrong path is taken. The Product Owner makes sure the Product Backlog is adjusted accordingly. By working in short iterations you are able to respond to change. If all goes wrong this means no more than one Sprint worth of work is discarded.

Early validation

By working on high risk items first, the feasibility of an entire solution can be validated early in its creation. For example if a successful implementation depends on a certain technology or tool, get this to work first. If it doesn't, you just saved yourself one hour of being yelled at in the boardroom, and probably a big pile of cash.

An different example in software development is to constantly merge code changes to validate compatibility with the contribution of others. Nothing is more annoying than someone taking lots of time to create one big behemoth of code and to find out that it kills the entire solution once checked in.

As assumption is the mother of all mistakes, validate as soon as possible.

Value oriented

By going through the features and wishes based on customer value, we make sure that as much value as possible is delivered before the customer decides that you have delivered enough or runs out of budget.

In Scrum the Product Owner prioritizes the Product Backlog mainly based on value to the stakeholders. The development team picks up work items in that specific order. This is to prevent that the team is cherry picking all the fun stuff and the really important items don't get finished in time.

Doing things right

Transparency

By exposing everything that is done it is much easier to see risks in an early stage. Furthermore a team will be more effective in addressing things that are not going well. Agile promotes transparency as a basis for risk identification and continuous improvement. Without transparency true learning will not come to fruition.

In Scrum the Product Backlog needs to be transparent about the state of work items in order to make sound decisions regarding value and risk. Without transparency these decisions may be flawed, resulting in a higher risk.

Ready work

By exclusively accepting work that is ready to execute we diminish the risk of starting something that can't be finished because of surprises along the way. A widely suggested practice for a team is to only work on items when the problem to solve, the expectations and the conditions are clear and complete. This way the team knows how to successfully handle the work. A popular term for starting work that holds too many unknowns is the Spike, which is typically used to discover the unknowns and validate feasibility.

In Scrum the development team decides whether a work item is ready to enter the Sprint. This is designed to prevent the Product Owner to push work onto the team that might not be feasible within a single Sprint. Accepting unready work would complicate planning and increase risk.

Collaborative planning

By planning the work with the entire team there is a greater chance to identify risks early. By appealing to everyone's knowledge it is more likely that the team works on stuff that is feasible and will end up as added value instead of wasted time.

Sustainable development

By having the development team members decide how much work they can handle and how they handle it, they are able to maintain a constant pace indefinitely. This enables a continuous delivery of value and restrains the risk of team members burning out and teams falling apart.

In Scrum there is a clear separation of responsibilities between the development team and the Product Owner. The Product Owner prioritizes the Product Backlog but has no say in the amount of work items to be delivered within a Sprint or what technology is to be used. Needless to say, this is best determined by the professionals that do the actual development work.

Product oriented

By focusing on products rather than projects we can trust the development team to take full responsibility for their solution. This is a commonly applied stance in Agile organizations.

As projects are known for their defined end date and budget, the responsibility for a solution often leaks away from the team that built the solution once it is 'finished'. Maintenance is handed over to others including all technical debt and possible quality issues. The successive difficulties in maintaining the solution are not the problem of the development team, so there is little encouragement to properly manage the long term risks of the solution.

A development team that retains full ownership of a product during its entire life cycle is inclined to deliver a high quality solution. Any shortcuts taken by the team will eventually have to be solved by the same team to assure a maintainable and robust product. Where projects lure people towards short term thinking, products are there for the long run.