As the scrum godfathers said, scrum is a lightweight framework used to deal with complex problems in a changing environment. Whether you use it for continuous product development or in a project-oriented mode, stakeholders always demand timelines, cost predictions, roadmaps, and other prophecies of this sort. It is perfectly understandable and justifiable - in the end, the project or product development is there to bring value to them. And financial profit is certainly one of these values.

Many of us know how painful the inevitable questions about delivery forecasts can be. When will this feature be released? How long will it take you to develop this bunch of items? Will this be ready by Christmas? We would, of course, like to answer them in the most honest way: "I don't have a clue". But that rarely helps, because even though it is perfectly true, it is not very useful and does not help the management very much. For them, approving a project development based on such information would be writing a blank check.

I've seen several ways in which people approach such situations. Some just give blind promises and hope for the best, while feeling a bit nervous in the back of their minds. Others go into all the nitty-gritty details of all the required backlog items, trying to analyze them perfectly and then give a very definitive and exact answer, while feeling quite optimistic and confident that they have taken everything into account. Some people also add a bottom line "...if things go as planned".

If things go as planned

Well, our experience shows that all these approaches usually generate more problems than benefits because the impact of that innocent appendix "...if things go as planned" proves to be massive and makes the original plan fall far from reality. It actually stems from the very definition of the words project and process. A process is a set of actions, which are taken to achieve an expected result, and this set is meant to be repeated on demand. On the other hand, a project is a temporary undertaking that aims to deliver a unique outcome or product. While the process is meant to be triggered as a routine and its variables are well known and defined, a project is always unique.

So, a project is something that people do for the first time, to achieve something new. And when we do something for the first time, there are two kinds of unknowns involved: the known unknowns (knowledge we consciously know we are lacking) and the unknown unknowns (stuff we don't know and we don't even realize it). Based on the nature and environment of the project and our experience in this field, we can identify some of the unknowns and risks to a certain degree. But I don't believe that there will really be a project where all the potential pitfalls could be identified unless you actually implement the project - only then you will know for sure. If we'd like to identify all risks and analyze future problems and their potential impact, we need to try it out in real life. Only then could we be certain about the outcomes, approving or disapproving our initial expectations.

I am trying to express that uncertainty is part of every project. That means that when planning a project, we need to take that into account. So when setting up a project and trying to get a grasp of the costs, timeline, and scope, we must understand we're always dealing with estimates and planning errors. So instead of trying to pretend it doesn't exist and requiring (or providing) a seemingly "exact and final" project number, I think a more constructive discussion would be about the actual scale of the error.

Cognitive biases

While the above is generally logically acceptable to rational and experienced people, why do we tend to ignore or underestimate the risks at the beginning? I believe it's got something to do with how our minds work.

There is a phenomenon called the planning fallacy, first described by psychologists in the 1970s. In essence, they found that people tend to (vastly) underestimate time, costs, and risks of actions while (vastly) overestimating the benefits. The researchers measured how probable were various subjects to finish various tasks within the timeframes the subjects have estimated. Interestingly, over half of the subjects often needed more time to finish the task than was their catastrophic-case estimate.

The actual thinking processes are even more interesting. Even with past experience of solving a similar problem and a good recollection of it, people tend to think they will be able to solve it quicker this time. And that people genuinely believe their past predictions (which went wrong in the end) were too optimistic, but this time they believe they are making a realistic estimate.

There is also something called an optimism bias. Optimism bias makes people believe that they are less likely to experience problems (compared to others). So even though we can have a broad range of experience with something, we tend to think things will evolve in an optimistic way. We tend to put less weight on the problems we may have already encountered in similar situations, believing this was "back then" and now we are of course more clever, and we won't run into any problems this time. People tend to think stuff is going to go well just because they wish for it.

Another interesting factor is our tendency to take credit for whatever went well in the past, overestimating our influence, while naturally shifting the reasons for negative events to the outside world - effectively blaming others for what went wrong or blaming bad luck. This might not be expressed out loud, but it influences our views regardless. This stems from a phenomenon called egocentric bias.

Combining psychology with projects

So it becomes quite obvious that if we combine the lack of relevant experience (a project is always a unique undertaking up to a certain degree, remember?) with the natural tendency to wish for the best, we get a pretty explosive mixture.

We need to understand that not just the project team itself, but also the stakeholders fall victim to the above-mentioned factors. They also wish for a project to go as they planned and managers rarely like sorting out any problems that stem from a project in trouble that doesn't evolve as expected.

Yes, I have met managers who naturally expect considerable risks and don't take positive outcomes for granted. Managers who understand the uncertainties and will constructively attempt to help a project which slowly deviates from the initial expectations. When we have a manager who addresses risks and issues factually and rationally, it is bliss.

But what if that's not the case? Many managers try to transfer the responsibility for possible problems to the project teams or project managers while insisting that the project manager must ensure "project goes as estimated". Usually, their way of supporting a project is by stressing how important it is to deliver stuff in time and that the team must ensure it no matter what. And that all the features need to be included, of course.

Now when you combine the fuse in the form of pressure from stakeholders with this explosive mix, that's when the fireworks start.

So how to increase the chance of creating a sane plan, keep the stakeholders realistically informed, while maintaining a reasonably peaceful atmosphere in the development team? I think we can help it by gathering certain statistics and knowing we are constantly under the effect of cognitive biases. We'll look at this in the next part of this series.