Most of the time the problems we are trying to solve are of our own making. The actions we took or processes we created in the past were not wrong, but the system changed, and now we must deal with the problems this has created. The challenge is, we could end up making matters worse, creating an even bigger problem for our future selves.

If we have analysed our current situation and even identified and resolved a core conflict we are in a good position to solve the root cause. We can build on those activities to work forward, identifying the consequences of our good actions, and validate they resolve the symptoms we identified. We can also see if we can spot any negative consequences which would be a problem to resolve and future, and get ahead by ‘trimming’ it now before it can cause any trouble.

Why are projects always late?

The best way to illustrate the process is to start with a Current Reality Tree for a problem. My experience in software projects has seen this problem frequently arise. The outline of the tree below is often embedded in an analysis of the problems growing teams are facing.

As teams scale up, or as they iterate on a software product, eventually there is complexity which must be coordinated and managed with each successive change. Planning processes adjust to allow for this, and the additional overhead is justified because it makes the overall delivery smoother. After some time, the longer times affect, and the teams must budget for the changes which occur during the project due to the increased length. More contingency time is added to ensure they can still meet deadlines. So begins a vicious circle where changes become more likely, and projects gradually get longer and longer:

The Core Problem

Whilst the techniques we used to mitigate the increasing complexity and size of projects were well-intentioned and even made a difference to the symptoms, the problematic aspects ended up expanding into the space created. We need to address this, and the conflict is that we can’t afford to plan less upfront as we end up derailing projects. We must, however, plan less upfront to be able to work in smaller increments, to ensure we deliver sooner.

I won’t go into the assumptions and resolve this cloud, as I want to demonstrate the Future Reality Tree. The solution to this is at the heart of the Agile Manifesto . Focus on building smaller projects, and get feedback on the progress we are making frequently. This allows us to respond to the changes more readily, and even choose to stop a project if we have already met enough key objectives.

Does our solution work?

We know the theory, but can we be sure that if we plan in smaller increments we will address our problems? The original solution to the problem was to increase the amount of planning we did upfront; before we change our approach we should validate our new solution.

To do this we have to navigate a path between our solution (known as an injection) and the better world we seek to create:

Notice the target at the top (shown in green) is the ‘opposite’ of the problems in the original Current Reality Tree. These describe the bright future we are pursuing.

What will happen if we…?

The path is plotted by asking: what would that action cause to happen? In the case of planning in small increments, the following are likely logical consequences:

• We start the work earlier
• We more accurately estimate the work

And as a consequence of starting earlier, and more accurate estimates we will finish increments earlier; this, in turn, will give us feedback sooner, allowing for re-prioritising the most important work and removal of unnecessary items. We can then choose to close the project when all the important items are finished, and therefore projects will rarely overrun. We have worked forward to one of our target conditions:

Sustainable Change

If we examine the tree above, we haven’t yet connected the dots to “projects taking less and less time”. Whilst starting earlier, finishing earlier and not over-running are likely to result in projects taking less time, we are interested in creating a positive feedback loop. In the Current Reality Tree, there was a negative loop, a self-feeding condition leading to the projects getting larger and larger over time, and therefore taking longer and longer over time.

If we can create a positive feedback loop in our Future Reality Tree, then the system will be self-sustaining and is less likely to degrade back into the problematic state we are in now. Our solution should lead to the opposite, projects trending smaller and smaller over time, and therefore project taking less and less time.

Examining the Current Reality Tree we see one of the contributing factors for the negative cycle:

• We add additional scope into the project

because:

• We cannot afford to wait until after the project for extra scope

In the Future Reality Tree, we see we have created two new key conditions:

• We can re-prioritise requirements based on changing information
• Projects rarely over-run

We are now likely to be able to start new phases earlier. This will make projects smaller (and smaller) over time, and free people up to start new work earlier. This creates our positive feedback loop, and the target condition of projects taking less and less time is achieved:

Problem Solved?

We have validated that this approach will address our problems and start us down a path of increasingly smaller projects, getting value to customers or users quickly. We don’t, however, know if this will create problems that are worse for us. Anyone who has worked with agile projects will no doubt have encountered difficulties which take the shine off the idea.

The key to avoiding such difficulties is to collaboratively get the problems out in the open and discuss them. We can share the tree, and canvas our teams for problems which these may cause. If we examine our Future Reality Tree we may identify the following problems:

• If we plan in small increments, we may lose sight of the big picture
• If we re-prioritise after each increment, we may discover key dependencies too late, or find the planning overhead exceeds the work being done
• Project completion based on when important work is done may mean we cannot predict end-dates for projects, or that we make less money if customers stop earlier than they would have.
• Leaving later requirements out of the initial scope could mean we end up creating rework we would have avoided had we planned it originally.

These are effectively negative side-effects our future self would identify and a Current Reality Tree would show our smaller increments as the route cause! We refer to these as negative branches. There may well be more cascading effects from the above problems which would be even worse. Our aim, like a tree surgeon on the analogous garden variety tree, is to trim off bad branches before they damage the whole tree.

Pruning the negative branches.

Fortunately, we are already capable of creating and validating solutions to problems, the Future Reality Tree itself. In essence, for the tree to be complete, we must also ensure the tree of logical consequences leads to the opposite condition to these newly identified negative conditions, not just the original conditions from the Current Reality Tree.

This can mean looking at other cause-effects in our tree and more often adding additional injections to create other conditions. In the example we may end up with a complete tree which looks as follows:

We could, and should, review the new items added to the tree and check if there are any new negative branches created until we are reasonably certain we have a solid plan to work to.

Working through the plan

We now have a much more detailed view of what we expect to happen when we start doing our improvements. We can monitor what happens in reality and when we achieve our target conditions. If circumstances change whilst we are working through the plans we can revisit and adjust the tree to better respond to those changes.