Agile teams value assumptions over forecasts

This post is inspired by my favorite systems thinker prof Russel Ackoff.

In development we have lots of uncertainties. Uncertainties in technology, scope, costs and schedule just to name a few. We face the challenge of staying in control in a uncertain environment. We face the challenge of dealing with the uncertain future.
There are two things you can do to deal with the future. You can use assumptions and you can use forecasts. Forecasts are about probabilities of events happening and assumptions are about possibilities of events happening!

A thermostat controls the temparature of a room by frequent measuring temperatures and adjusting the heating-cooling system. The thermostat does not need to predict or forecast the future ‘weather’ in the room in order to control it. The thermostat does not need probabilities. It only needs assumptions! The thermostat assumes that the temperature will change in the room and therefore it is made in such a way that it can respond rapidly and effectively to whatever the temperature turns out to be.

There are two nonexclusive ways of dealing with possibilities; contingency planning and developing responsiveness.

Russel Ackoff

We do contingency planning for the cases we see as an exceptional risk. You identify the small set of possibilities and come up with a plan or measure to tackle each possibility. I carry a Jerrycan in my car not because I forecast that I will run out of fuel in the middle of nowhere but because I assume it is possible that I do. When the set of possibilities is to large and therefore to complex to handle we develop responsiveness.

In agile teams there is a lot of attention for developing responsiveness. We have short iterations and increments, various quick feedback loops, work in order of value and keep quality high so we are ready to change direction every iteration. There is also a lot of attention on forecasts. We have release burndowns, avg cycle times, work in progress, defects trends and so on. There is nothing wrong with forecasts about the future except for the unpleasant fact that they are usually wrong.

In Scrum we used to say that a team committed to a sprint goal. The use of the word commit made lots of people think that a team should be able to predict the future after it was sprinting for a while. Nowadays in Scrum, in order to make things clearer, the Development Team is said to give a forecast of what it thinks it can do within a sprint. So a Development Team actually makes a statement about how probable it is that they can accomplish the selected product backlog. It’s a forecast based on the Yesterdays Weather XP rule.

In agile teams there is little attention for contingency planning. Agile Risk management just does not seem to be interesting enough and set based development seems to be regarded as to expensive by most teams! So lots of agile team focus on their forecasts although the best way to handle the future is not by trying to predict it but by the possibilities we have of adapting to it! An Agile team should therefore assume certain possibilities will materialize and have options ready so they can adapt quickly to what the future might bring. An agile team should therefore value assumptions over forecasts.