Who hasn’t made plans at some time, and who hasn’t had to change them? I, for example, remember very well my time as a student, I needed to arrive at each exam with the subject well worked. I tried various planning methods and, based on my experience, I constantly re-planned down to the smallest detail. The hard reality is that one day I would get less done and another day a lot for no apparent reason. There was no problem, I was always sure I could adapt my plan, I was gaining more experience and therefore more certainty. With a good plan, success was guaranteed. What could go wrong? To this day I think I could have spent all the time I spent planning on more useful activities such as resting, having a few beers with my friends, or simply continuing to study. Where was the problem?
It’s been years (a lot of years!), but it’s something I still observe in my work environment. I always observe the need to find the perfect plan and estimate when there is uncertainty or complexity because, no matter how much you learn and re-plan, you will probably never manage to make a reality of what you have put so much effort on paper. That’s why I always try to make teams see the real purpose of planning and estimating because, I’ll tell you, it’s not to make a perfect plan.
In 1979, the psychologist Daniel Kahneman, the author of “Thinking, fast and slow“, together with Amos Tversky, also a psychologist, introduced a cognitive bias that he called the planning fallacy. This bias tells us how we always value with optimism the time we are going to spend doing something ourselves, while if we have to estimate a task that other people do, we use a pessimistic criteria. The problem is not only related to time estimation, but we also underestimate the cost and risks and, moreover, it affects both personally and professionally. In agile we rely on techniques such as the relative estimation of elements to reduce the time spent on estimating and achieve its true objective, which is none other than to reduce uncertainty. We are not looking for an exact estimate of what will happen because, in fact, an estimate is only a forecast. What we are looking for is an idea that helps us to orient ourselves in order to plan better, a support. It is important to emphasize the importance of estimating “the elements”, not the time or personal effort to perform a task, but to focus on whether this task compared to another is greater or lesser. Moreover, if we integrate this type of estimation with other techniques such as planning poker, we further reduce the effect of the planning fallacy, since we integrate the views of the different participants reducing biases.
But then, what is the point of planning? Normally, we have to plan for organizational needs. Indeed, when an organization wants to start a project, it is necessary to set a time frame and ask for a budget to execute it. These projects are usually associated with an annual strategy that is validated and that releases parts of the overall budget, which are the ones that enable the execution of the projects. On the other hand, we also plan when it is necessary to involve several teams, since it is necessary to have a tentative idea that allows them to align and reduce blocks and dependencies. There are many other reasons to make a plan, however, there is an even greater objective that we must not forget: to achieve maximum value, finding a balance between the needs to be met, the resources we can count on and the timetable. With good planning we manage to reduce risk and uncertainty, improve decision making, generate confidence and transmit our expectations of what can happen in the development of a product or project. The interesting thing is to do it with an iterative and incremental approach, collecting feedback as the project progresses, learning and incorporating that learning to optimize the delivery of value.
Complexity requires reaction and adaptation to change, not a detailed plan, because we don’t know where the difficulty is going to come from or what unforeseen events there will be. Otherwise, it wouldn’t be complex, would it? Whether you are an expert, have done the task many times, or think you have all the possible influencing factors under control, the context changes frequently. Our real weapon is to be able to adapt on a day-to-day basis and have a minimum planning that guides us, balancing the effort spent on it with the objective we are pursuing. If we propose intermediate goals, more short-term, and have frequent feedback points, we can learn and redirect our path with more confident steps until we reach the final goal. We can estimate to help reduce uncertainty and make a plan to help us organize our work, but our effort must be in achieving our goals and knowing how to redirect our plans to achieve them. I remember the frustration of a team when they had to launch an initiative to reorganize some technical resources in a different way than they had initially planned, this made them take a step back from the initial design of their solution, the hard effort spent in its execution and the time invested in understanding the needs of the users to make the best proposal. However, it was not a step back, it was a step forward, a very firm step, with the learning acquired after the implementation of the solution and having gathered feedback that we could not have had otherwise but from the users’ experience. We had to leave behind some a priori interesting developments, prioritizing this rethinking of the solution. What did we get? A final solution much more adapted to the needs of the users, who did not yet have experience in a similar environment and who were discovering a new world and learning as they used their new work environment.
We should not be afraid to change plans that do not take us to the expected place and that we made when we did not have the learning about the project that we have as we move forward. As Mike Cohn says in Agile Estimating and Planning, with agile planning we balance the effort and time investment in planning with the peace of mind that we will revisit that plan when necessary and adjust it. Agile planning should focus more on the planning than the plan. What does your team focus on most?
Leave A Comment