The idea that Agile means no planning has more or less been eradicated by now. However, many people are left wondering what level of planning Agile processes, methods, or frameworks need.
Many “out of the box” Agile implementations you can get training and support implementing have specific guidance on what level of planning they require. The same can be said of many more generic approaches and frameworks. In a more general sense, practitioners such as myself enjoy the phrase “just enough to deliver value next sprint” or something similar. Of course, none of that really helps most people reading this right now.
The goals of planning in an Agile context are not all that different than planning in a classic context. We need to set expectations, guide efforts, control risk, and deliver value.
A product owner’s priority is the product. They want the best product possible, as fast as possible. The development team wants everything defined well enough for them to deliver a quality product, and the time to deliver that product. The customer wants value. The company wants profit. Everybody involved has some expectation, and those expectations need to me be managed. Proper planning allows all voices to be heard, a common vision to arise, and a sustainable pace to evolve.
For work to effectively result in real value there has to be a roadmap. Without knowing what is valuable, nobody knows what to work on. During planning the entire team works together to set that roadmap. Without this, people could work on functionality that is at odds with each other, resulting in bigger problems as opposed to solutions.
A big part of project management is risk management. In classical project management, this meant sticking as close to the plan as possible lest time or money slips out further than can be dealt with. In agile project management, this often means not planning things to such a detail that changing direction becomes problematic. The idea is to accept the risk of change rather than control it.
Even today everybody understands what the “death march” of a project is. Some date has to be met, no matter what. The pace is constantly quickened as issues come up to ensure the timeline doesn’t slip. This is anything but sustainable. In an agile environment, the scope is allowed to flex based on new information as it comes in. This doesn’t just mean a project can be on-time missing functionality or late with all functionality. It also means a project could release with functionality nobody envisioned until part-way through, and what was once thought important may be left out as all parties realize it was not needed.
How do we use that knowledge to fix our current planning sessions?
Listen to the entire team, not just the one who the product is for. Don’t look at the moon in your pocket and promise Jupiter. Be open to altering the plan as needed over time, and make sure everyone knows their input is actually used in planning.
Like many things in an agile environment planning is a team effort. If you’re struggling to see how the planning your team does matches with their reality, give me a call! We’ll talk about the disconnect you feel and how I can help you and your team close the gap.
