How can we create reliable forecasts in software development, given that what we do is complex? Two things that are necessary are:

• A stable system
• Correct data

I will come back to this, but let’s first look at the difference between complicated and complex.

Complexity

When we say something is complicated, we are talking about whether something is easy to understand. A clock, for example, is quite complicated. It is not very easy to construct a clock yourself. However, a clock is - hopefully - predictable.

Complexity, on the other hand, refers to how something behaves. A set of dice, for example, which is quite simple to understand and construct, behaves very unpredictably. It is complex, but not complicated.

The Cynefin Framework

Dave Snowden describes the Cynefin framework as a “sense making” framework. It divides domains into degrees of complexity, and is intended as a tool to help understand the context you are in and guide how you act, make decisions and lead.

You can be in multiple domains at the same time, depending on which aspect of a problem you are looking at. It is also possible to move between domains over time. This usually happens clockwise.

How is this related to predictable software development then? We are mostly in the complex domain. For one thing, corporate culture is an example of a complex system.

What about the codebase? One could argue that it is complicated rather than complex. Okay, sure, but anyone who has ever worked on a large legacy product is likely to agree that it can be bordering on complex, too.

This means that we need strategies and mindsets that are adapted to the complex reality we are in.

Predictability

In a complex system there are no clear links between cause and effect. It is practically impossible to analyze one’s way to when something will be done. Instead, we need to find other ways to create forecasts.

Stable System

The first thing we need for reliable forecasts is a stable system. What does that mean?

In a stable system, the inflow of work matches the system’s capacity.

When the inflow exceeds the capacity, we get turbulence. Queues are created, lead times increase and we generate technical debt. In short, this makes all attempts at being predictable impossible.

Stable Teams

I mentioned earlier that corporate culture is an example of a complex system. Another example is teams. That means that stable systems require stable teams.

This does not mean that one never changes team composition, or that one is stuck forever in the same team. However, one should not change teams without thought or too often.

Correct Data

The second ingredient in predictability is correct data.

Psychological Safety

So how do we get correct data? To begin with, and this is independent of domain really, is psychological safety. If employees do not feel comfortable openly sharing their opinions and thoughts, you will never have correct data.

Whenever there is fear, you will get wrong figures.

• W. Edwards Deming

It does not have to be at the level that one is scolded or subjected to reprisals when one speaks up. If one is ignored, dismissed or rejected, then the trust in the organization will slowly erode, and people will start to play it safe and stop engaging.

Impartiality

The other puzzle piece is impartiality - unbiased data.

Click to expand

In an experiment, and I paraphrase a bit, a group was asked if they thought the highest tree in the world is higher or lower than 50 meters. Most answered “higher”. The next question was “How high?” and they answered on average slightly higher than 50 meters.

Another group was asked if they thought the world’s highest tree is higher or lower than 150 meters. “Lower” answered most. On the follow-up question, they answered on average slightly lower than 150 meters – but very different answers from the first group.

We are, subconsciously, influenced by the information and data we take in.

Combining lack of psychological safety with lack of impartiality, the only thing we can be sure of is that we are not going to be predictable.

The Solution

We know we are in the complex domain, and that we need a stable system and correct data. What can we do?

Separate Estimates from Forecasts

To begin with, separate estimates from forecasts. Use relative size-based estimates (or possibly no estimates) and derive calendar time based on empirical data.

Do not ask when something will be done, or how long it will take. Calculate duration based on previous speed – on empirical data.

Using techniques like planning poker is a good way to get relative unbiased estimates from the team. With distributed teams, you can run planning poker online with our tool linked below - or one of the other tools available.

Work Iteratively and Incrementally

As mentioned it’s possibly to move between domains in the Cynefin framework. We take advantage of this when we work in iterations. Note, however, that it is not enough to work in iterations. One must also work iteratively and incrementally.

Working in iterations does not necessarily mean that one is working either iteratively or incrementally.

When we work iteratively, we refine something over time, in each iteration. When we work incrementally, we add more and more functionality over time. In software development, we want to work both iteratively and incrementally – at the same time.

Click to expand

When we break down our large complex project into iterations, we can often consider a single iteration as complicated rather than complex. We let our experts – the teams – analyze the contents of the iteration and come up with possible solutions and estimates.

Perhaps the team breaks down the work further, and each broken-down task may even be considered a simple problem - clearly solvable for everyone involved.

The 80/20 Rule

When we work iteratively and incrementally, we can also make business decisions about what to deliver and when something is “good enough”. In a complex system, it is more relevant to formulate a goal than to list all requirements, and ultimately, the most important thing is that the goal is achieved.

Many times, the goal is achieved without all requirements being implemented. Other times, new requirements are added along the way. Focusing on the goal instead of individual requirements is crucial to being predictable.

Final Thoughts

Why are we often so bad at predicting development projects then?

In addition to an obvious lack of psychological safety in many organizations, I believe many act under the assumption that they are in the simple domain. Then, they think they can control the system centrally using Excel, Gantt charts, and resource allocation.

If the assumption, however, is incorrect (and it is), it will not work. Probably, they also do not have any strategies for working with a complex system.

The risk then is that they fall over the edge into chaos - what in Cynefin is called the “zone of complacency”. This is where heroes are born. The wrong kind of heroes. To stabilize the chaos that arises, strong individuals are needed who are not afraid to step on other people’s toes, and who do not care about the long-term consequences of their actions.

However, this undermines a stable system, and it undermines psychological safety. The next time, it will be even harder to be predictable.

So whatever you do, don’t fall over the edge.