A common misconception is that the agile approach to projects means no planning and no documentation and control by the team. Does Agile mean no plan? Certainly not, but it will mean a different approach to your planning. Bad management of an agile project means anarchy. But on the other extreme a bad approach to waterfall project is total dictatorship. Neither extreme establishes a good foundation for success. Flexible control, guidance and facilitating project progress is a good approach regardless of your project management framework.
What sort of planning should be done?
In waterfall projects it is common to build a plan for the whole project. Sometimes this is done in great detail for each phase of the project. But often planning of future phases can result in wasted effort. The nature of the plan will change during the life of a project. Taking a quote and some thinking from military situation:
“NO BATTLE plan ever survives first contact with the enemy,” Helmuth von Moltke
So, you should expect the plan in a project to change over time. But it is also true that failing to plan is planning to fail as used by a number of historical figures. Any plan should contain enough information to service the project, and aid direction.
In an agile project a planning framework for the project allows it to focus on the main objectives. Much of the detailed planning can be left to the team in project teams where sprint delivery is meeting expectation.
The plan is an aid to completing the project and does not need to be more than that.
Tracking the plan
Tracking the plan in an agile project is valuable in providing key information for future iterations. The progress from each iteration can tune what elements could be included in future cycles.
But you should only plan in detail for tasks taking place in the near future. Just as the team drive work and the approach to work each individual should drive planning for the tasks they are involved with.
A positive point from people planning their own tasks is they are much more likely to own the schedule. They are also best placed to understand dependencies and technical risks around the work they need to do.