Lean-agile risk management. Is there such a thing?

An interesting area of discussion is to whether a lean-agile approach contributes anything to effective risk management. Do lean-agile practices effectively mitigate risk? Some say yes and some say no.


There are, I believe, currently no lean-agile practices which are designed to identify the most important risks and then focus on mitigating and tracking them. Other (traditional) project management approaches have tools and practices for this – for example by the creation and ongoing review of a risk log. Yet this is missing in the lean-agile toolkit. Lean-agile practices need supplementing by a traditional risk management practice.


The traditional risk log approach is of limited effectiveness. If you ask a team what the top three risks the team faces are (go on, try it), it’s rare that the team comes with a consistent answer. Even when a risk log helps identify risks, analysing the true root cause of a risk in any particular case can be difficult.

By implementing lean-agile practices, teams get access to ways of mitigating the highest risks that an IT development project faces as evaluated by broad industry experience.

Take the Agile Manifesto. It was created by a group of experienced people. Apparently, it was tough to find things they agreed on (even though they were experienced, the number of projects they have worked on is still small so the number of data points they have is also small). They did manage to agree on the agile principles behind the manifesto. Each principle addresses one or more key underlying risk facing an IT development project. I’ve had a go at identifying the implied risk below. Would you think of these when you start a IT development project? Would you agree that these are the key risks?

Principle Implied risk
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Solution deliver generates no or little value. Unused features.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Solution could not be built as intended. Solution delivers no value. Things external to the project change.
Business people and developers must work
together daily throughout the project.
Business people and developers do not communicate quickly & effectively.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done
Environments and support not available.
Teams not empowered.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Geographical distribution of teams and over-reliance on electronic communication leads to ineffective communication.
Working software is the primary measure of progress. Focus on internal goals instead of meaningful ones (delivery of working software)
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Unsustainable development (pace, architecture, …)
Continuous attention to technical excellence
and good design enhances agility.
Lack of focus on technical excellence.
Simplicity–the art of maximizing the amount
of work not done–is essential.
Complex code. Doing work that doesn’t need to be done.
The best architectures, requirements, and designs
emerge from self-organizing teams.
Ineffective teams due to poor team structure/task management and the team not being empowered to change this.

What do you think?

Leave a Reply