Lean-Agile does not promote zero planning. Planning is conducted in Lean-Agile. Where it differs is that it has a smaller part of planning up-front and also includes planning efforts distributed to each iteration.
Planning Versus a Plan
"Prepare for the unknown by studying how others in the past have coped with the unforeseeable and the unpredictable." 
Planning does not dominate the project so completely up-front as in plan-driven all up-front waterfall approaches.
Lean-Agile means something different by planning than what some traditional project management approaches have come to mean. Traditionally, there has been a heavy emphasis on planning meaning the plan, as in an artifact. If the operational environment is certain and predictable, then that can work. However if the operational environment is complex, unpredictable and higher tempo, like warfare, then what our military customers do can also be instructive for business teams.
Planning Prepares the Mind for the Coming Challenges
As military history bears out repeatedly, and is taught to military officers, planning adds value, but the plan itself has very little value.
The U.S. Army has a saying that “No plan survives first contact with the enemy.” They say this not to devalue planning, but only to acknowledge that what will actually need to happen may be different from the earlier plan. We mention this to highlight that planning is dependent on the information available at the time. Agile allows planning to be adjusted to the new realities that exist at the time of execution that may be quite different from the original envisioning of the project up-front as more information has become available over time. When using earned value, think of this as rolling wave planning.
In military warfare and in Lean-Agile, planning is discovering the factors involved in the circumstances and the systems structures (systems thinking) that create dependencies and feedback loops which constrain our decisions. So planning is more about adding insight and wisdom to team/organization decision making than simply having an artifact called a "plan".
Planning makes us better prepared to respond to the changing situational context. Planning helps get us into the mindset to see opportunities.
Where possible, it is better to have the same people who planned (and thus built the insights) execute the plan, rather than having different people analyze/plan and execute to avoid the loss of their mental situational model when the planners move to other assignments when execution begins. The plan artifacts that remain are often many large documents people don’t want to read and that don’t keep up with the execution anyway. New staff charged with execution must replan (rework is waste) for their own situational awareness, so they are ready to respond to changing conditions.
Reading someone else’s plan document does not provide team members the contextual awareness that doing the thinking, making findings and forming their own conclusions provides.
The goal of Lean-Agile planning is not to create a large plan document, but to get ready to execute well. In less complex, predictable environments, a deterministic plan may succeed. In a complex adaptive system, discovering what is happening and how to adapt is the key.
"In preparing for battle I have always found that plans are useless, but planning is indispensable." 
Lean-Agile planning puts the value on what is learned and discovered while planning more than putting value in the artifact itself. Rather than a long written plan, the product backlog and the iteration backlog form the "plan" of intended work items for the project or specific iteration.
Rather than predicting what will happen and then following the plan exactly, we’re focused on gaining the mental model of the environment. The U.S. military also works in complex environments, and in their lexicon they call this "visualizing the battlespace" to help clear the fog of war. So in Lean-Agile as we plan and gain the mental model of the environment, it helps us clear the fog of complexity during the quickly-changing execution.
Project/Program Definition Planning
Project/Program definition planning still includes stating the aim of the Project/Program and identifying Project/Program objectives.
The work breakdown structure (WBS) is detailed only down to the iterations, delaying planning the specifics of what occurs in each iteration until closer to the iteration so that all involved have the latest information.
Resource requirements are identified for the people and tools needed.
Traditional up-front deliverable sequencing, resource scheduling and risk management is mostly distributed to iteration planning meetings.
Roles and responsibilities are discussed later in the book.
Lean goes so far as to say that too much time spent planning everything up front is a form of Lean waste because the situation emerges and changes as more is known.
The following figure depicts the differences in when the planning occurs. Note that the same 100 "units" of planning effort still occur, but they are spread or distributed across the iteration planning meetings rather than all up front. Like rolling wave planning the planning has more value when the effort is delayed until more is known, leading to less planning waste.
|For more details on planning, see Conduct High-Level Planning Tasks skill statements in Appendix A.|
During project/program planning, a Lean-Agile team conducts planning to wrap their head around what is involved overall. The backlog is the current 'plan' given what we know now. The development team may estimate the work effort in the training product requirements backlog items.
Iteration Adaptive Planning (recurring, like rolling wave planning)
Lean-Agile plans the high level up-front and allows room to plan the details in the iterations where the information is more up-to-date.
During iteration planning, the iteration backlog plan is pulled from the product backlog. The iteration backlog plan is visible to the entire development team on the Kanban board, and it is prioritized so that the team knows which work items they should pull next.
Iteration planning also helps teams adapt to emerging circumstances based on the parameters of the operating environment about which our planning provided so much discovery and insight. The Scrum method builds-in a closed-loop control process to get feedback (+, -, change) fed into each iteration planning meeting, so the team can adapt for the next iteration in striving for perfection.
Daily Adaptive Planning (recurring)
Because of complexity, the plan is then adjusted in the daily synchronization meeting when the team applies PDCA.
Whether you call them daily synchronization, daily scrum or daily standup meetings, the team adjusts and adapts based on what is actually happening. Having gained a mental model of the environment, they can recognize the impact of new and unexpected risks and opportunities as they emerge and decide the handling actions in a daily frequency rather than the monthly frequency of traditional sequential waterfall ADDIE. Each day in Lean-Agile, the team looks together at the situation on a visual Kanban board, seeing the current status and visual cards representing both planned (predicted) and newly emerged (unpredicted) risks and opportunities. This allows them to collaboratively decided what steps to take for the day. As in a coach’s soccer game planning, opportunities come up fast for shots on the goal, and the opportunity is fleeting. The 'plan' is not the goal. Being ready to score is the goal. Daily standup planning is the place to see and exploit those game changing opportunities.
For anyone you run into who thinks or has heard that Lean-Agile does not include rigorous plans, we can assure them it has rigorous and distributed planning and that the planning is the foundation of decision making. The emphasis differs and is less on the artifacts themselves and more on what’s in between the ears of those planning. This includes discovering and balancing the constraining lay-of-the-land factors involved in the circumstances and the systems structures (stocks and flows) that create dependencies and feedback loops so that we make better decisions during execution.