The very first time I encountered Agile development practices I was puzzled by how one does planning in that environment. The mantra, from many sources, is that you really do not need to do planning. As the theory goes, all planning is time consuming and wrong, so why bother doing it. It is a waste of time. But as a senior business leader in several businesses, I could let go of what I know every business needs. Every business needs some projections about the future.
On the other hand, Agile methodologies have definitely shown the benefits of being real time and iterative in the planning. Plans are invariably wrong and so spending a lot of time planning is a waste of time. Having relative estimation at the core of any planning activity and limiting the estimation to the people actually doing the work significantly raises the odds of the work being accepted and completed with professionalism and high quality. Software development efforts benefit greatly from the just in time planning that focuses on the next iteration and the effort it takes to complete that iteration, leaving the rest of the backlog for later.
But if I am running a business I have to anticipate a great many things that require me to plan. Some the key reasons for me to have some understanding of what might happen in the future are:
At the highest level I need to obtain financing. Whether the financing comes from internal or external sources, I have to have some notion of how much money I will need to accomplish the goals at hand.
I need to know how many people to hire to do the work that needs to be done. Do I hire one team or 10 teams? Do I hire junior people or do I hire senior people or some mix. What kinds of skills will these people need so that the project executes well?
What are the risks to this project that I can mitigate now? Are there long lead times for some of the things I need (e.g. partnerships, complex algorithms, unsolved problems) that cannot be done at the last minute?
What are the implications of what I am building on my channel? Will I need to change the channel? Will I need to change my cost structure?
Is the time frame we are dealing with going to satisfy the external pressures that effect the project? Will we meet legal deadlines? Will we meet our contractual obligations? Will we deliver in time to effect the market in the manner required?
These conflicting needs and desires lead to a fundamental conflict that is hard to resolve. The people doing the work have been taught to do planning in a different way that is working for them incredibly well. Certainly better than the planning they did under a Waterfall methodology. Given that the developers are much happier under the new planning methodology, it is hard to convince them otherwise. The business leader are probably also happier with the new methodology because the software is being delivered on a regular basis with higher quality and more flexibility. So far it is a win-win. But the business leaders cannot ignore their planning and future looking needs.
Is there a way to do planning that preserves the essential goodness of the Agile process and delivers the essential needs to the business leader? Clearly, I think it is possible to accomplish both these goals, but it takes a different methodology than past planning exercises. The goals and constraints of the planning are different. The process of doing the planning is different. Expectations of all involved need to be rest as the business leaders will not achieve the level of detail and commitment they want and the Agile adherents will not get the freedom to not do any forecasting of the future.
The Agile Planning processes are not a fixed set of rules for how to behave. Instead, the process consists of a series of principles and philosophies that when adhered to provide flexibility, reasonable planning, and adherence to basic Agile principles.
Imprecise Planning Results
The first important principle is that the planning effort yields broad results that cannot be viewed as precise answers to the planning questions. A firm precept in Agile is that only the people doing the work can judge what it will take to do that work and even then, they can only succeed for small iterations at a time. The past history of doing a broad detailed plan to include all aspects of some project has proven to be a failure and so it needs to be abandoned.
Instead, we have an imprecise planning process that comes as close as is reasonable to predicting what the future will hold. It is imprecise by design and does not try to achieve anything remotely close to an exact answer to the planning questions.
The first important principle is that the planning effort yields broad results that cannot be viewed as meaningless.
© 2011-18 Westerly Consulting LLC, all rights reserved