Or “Why Doesn't Traditional Project Management Work For Software Projects?”

When faced with making Portfolio and Program decisions there is a human bias at work which actually drives us to use inappropriate tools for decision making. That bias is (sometimes) called an “Information Bias”. The Information Bias is a type of cognitive bias that refers to the idea that amassing more information will aid in better decision-making (and, at its worst, requires people to generate extra information is irrelevant to the actual subject.)

In general, when confronted with uncertainty, people feel that to overcome the uncertainty, they need to generate more information. While this makes sense, the problem is that people use the wrong approach to generate more information.

To understand why, we need to understand a little about systems thinking and, in particular, decision making when operating in particular systems. The tool we use is called the Cynefin framework, a conceptual framework used to aid in decision-making created in 1999 by Dave Snowden when he worked for IBM Global Services.

Cynefin offers five decision-making contexts or “domains” - clear, complicated, complex, chaotic, and confusion. When you are trying to categorize (note: this is one use of the model) the problem space you are working in, you inspect the relationship between cause and effect of the problem space. If the relationship between cause and effect is straight-forward and obvious to all, then you problem is in the “clear” domain. If the relationship between cause and effect is not obvious, but can be analyzed in advance, then you have a “complicated” problem. If the cause and effect can only be determined with the benefit of hindsight, then you are in the “complex” domain, while if there is no obvious relationship between cause and effect, you are in the “chaotic” domain. If you don’t know the relationship between the cause and effect, then you are “Confused”.

Pictorially this is represented as:

Source: Modified from File:Cynefin framework 2022.jpg - Wikimedia Commons

Sounds logical, right, but how does this help understand development? It turns out that each of these domains has different approach decision making that helps us best deal with the context:

• Clear Domain. The response in the simple context is to “sense - categorize - respond”. People assess the facts of the situation, categorize them, and then base their response on established practice. If something goes wrong, a person can usually identify the problem, categorize it and respond appropriately. This is the domain of the “best practice”.
• Complicated Domain. The response in a complicated context is “sense - analyze - respond.” This approach often requires expertise - I can detect there is a problem with my car, but I have to take it to a mechanic who can analyze the cause and get the problem resolved. Because the complicated context calls for investigating several options and there may be more than one “correct” solution, identifying “good practice” (not “best practice”) is the best approach. This is the domain of the “expert”.
• Complex Domain. The response in the complex context is “probe - sense - respond.” In a complicated context, at least one right answer exists. In a complex context there may be no known “correct” solution. Instead of attempting to impose a course of action, we must allow the path forward to reveal itself. This means we have to create environments where experiments (probe) allow patterns to “emerge.” This also means increasing levels of interaction and communication between stakeholders so that changing understanding of the situations is worked on and communicated to all.
• Chaotic Domain. The response in the chaotic domain is “act - sense - respond.” In the chaotic domain, our immediate job is not to discover patterns but to stop the pain. We must first act to establish order, then sense where stability is present and from where it is absent, and then respond by working to transform the situation from chaos to complexity, where the identification of emerging patterns can both help prevent future crises and discern new opportunities. This is the domain of rapid response - “novel practice.”

Pictorially:

OK, great, but what now? If we look at the problem of software development, we can see we often have a complex problem. When things go wrong, it is often obvious with the benefit of hindsight what happened and why. As Steve McConnell says,

“There is a limit to how well a project can go but no limit to how many problems can occur.“

The problem is that we cannot learn enough in advance of doing the work to say “in this situation we will fix it in the following way” as there is a different problem the next time around. In todays world we have a situation where there is interaction between people doing the work in an environment that is increasingly complex as well. This is not to say the whole process is complex, but significant parts of it are.

The fallacy of the past is that we have treated software development like it is a complicated problem. We’d analyze by generating more and more data (detailed requirements, detailed designs, etc.) and hope to come up with a plan that made sense. We’d then be surprised, time after time, when it didn’t work out. With the benefit of hindsight, no pun intended, we can now see why this did not work. We were often dealing with a problem that is in the complex domain. In fact it is often worse than that in that we often speak of “best practices”; this is the “Clear” domain.

In other words we’ve applied “complicated” and “clear” decision making processes to a “complex” problem. In other words we were trapped in the illusion of “deterministic thinking”, the idea that with sufficient analysis we could determine the optimal plan. And then we wonder why things didn’t work out.

We can now we can see why an lean and agile iterative and incremental approach helps us improve the flow of business value.

We are generating more information through a process of feedback cycles rather than simply doing more analysis.

Tools such as Program Increments and Iterations with their cadence of planning and reviews / retrospectives offer an approach which leverages the “probe - sense - respond” approach of the complex domain. The emphasis on collaboration and communication also help us dealing with the complex environment. It also helps us understand why we cannot just “best practice” the software development process and why even identifying good practices might not be ideal in all situations.

As we work to improve the results of our software development process, we need to remember that a lot of the issues we face are “complex”. In fact it could be argued that since the development process involves independent agents (people) in an increasingly technologically challenging environment we should treat a lot more (most) of the process as “complex”; the only way to reduce risk is through cadenced feedback cycles of working systems. We need to be careful about falling into the trap of over analysis, generating data that in the end will not help us make better decisions.

We need to apply the “complex” tools to help us address the problem - establishing fast feedback cycles. When we do this there are no final “go / no-go” decision for the Initiative; it is not “once and done”. We set up the system so that we deliver value on a series of cadences - biweekly, quarterly - and so will have many opportunities to either pivot (change direction) or persevere based on what we are seeing and learning.

As a final note I have talked about only one aspect of Cynefin and have simplified the thinking process for a particular application. There are many other aspects that can be brought to bear using this tool. By way of background:

• The framework was developed by Dave Snowden (Cognitive Edge). A good 8min introduction to the Cynefin framework is offered on the Web site. A paper written for the Havard Business Review is also available.
• Cynefin is a Welsh meaning “habitat, place” and it implies a place of multiple belongings of which we are only partially aware: cultural, religious, tribal, etc. These “belongings” affect our decision processes.

In addition I have leaned heavily on the work of others (eg Dave Snowden mentioned above, John Helm (Agile 2013 Conference), Simon Bennett (Agile 2011 Conference)) to help me pull this together from the perspective of software development. Brilliance is a result of their thinking. Errors are mine.