If I had to describe an Agile process in as few words as possible I think I would choose business first, iterative planning, honest plans, a project heartbeat, working software, team empowerment, and daily communication.
I prefer to say iterative planning instead of iterative development because it places the emphasis where it belongs: You must adapt as the project unfolds by changing your plans. You can plan out an entire project into detailed iterations in advance, but that isn't Agile. You change plans based on feedback from incremental delivery of working software. The customer/product owner is part of your team so let them guide your project not just at the start but day by day. Show them the system as it is being built so they can learn more about the solution and then listen to them.
Agile projects keep a set of unfinished features as a simple spreadsheet, list, or stack of cards that are a backlog of product features. You want to prune or groom this list on a regular basis by removing and destroying things your customer or product owner doesn't need anymore. Only keep features you would consider paying good money for, the rest go into the trash can or shredder.
From the list of unfinished features you will choose the most important. Important means different things to different teams. You can choose the highest return on investment (ROI). You can choose the architecturally significant features first. Risk is a very important way to sort. You can choose the features in groups that make good business sense. Most projects settle on a combination. The one constraint is that the customers guided by estimates of effort from developers choose what is most important next.
This collection of most important features is the input to the planning process. Features are represented in a minimal way that allows rough estimates of effort, but not detail. You will probably only implement a fraction of the features, so spending time on details is a waste until they are actually part of an iteration or sprint plan. Many Agile teams use a quick way to scope projects called story cards.
Stories are the currency of your project. Like money they don't have much value themselves, just a piece of paper, but they represent value and can be used to buy things.

Stories represent valuable software to customers, time to developers, and negotiable increments of scope to managers. Stories without value to the customer are counterfeit. Destroy any stories that have no value. If you find that you can't tear up or delete a story without second thoughts then you are making your stories more valuable than mere currency by spending too much time on them. Use cases can be especially hard to throw away once created unless you limit them to title, estimate, and a brief description at first.
There are three Agile levels of planning. Release planning is a group of stories selected because they represent a usable set of features that can be released together. These types of plans are made by selecting the stories and deciding how many iterations are needed or by selecting a release date and seeing how much can be done by then. Release plans have no details other than a list of stories to be done by a date.
The second level of planning is the iteration or sprint plan. This plan is a subset of the release plan stories that will be done in the very next iteration or sprint. Only one iteration plan exists at a time. With our chosen collection of important features we can now estimate the amount of effort to implement them. The people who will do the work, namely the developers, have authority to set the estimates. The manager will set the total amount of work that the next iteration can have planned. The customer then chooses a subset of the most important features that will fit into the next iteration.
The iteration plan will often be verified by breaking the stories into development tasks and estimating them with finer grain units. At this level use cases could also be created. This greater level of detail is permissible because iterations or sprints are kept very short.
The third level is the daily plan. A daily plan isn't usually represented by any artifacts. At the daily scrum or stand up meeting everyone will announce their plan for the day and then act on it. Even greater detail is allowed because the plan's duration is one day and no more.
When you slip your schedule you acknowledge how far you have come and make a new plan based on the new information. Trying to catch up only puts you further behind long term. Even if you can make it up in a short time the

strain on the team puts them behind schedule next week. Keep a sustainable pace going.
When you get ahead of schedule you make a new plan. Being ahead of schedule does occasionally happen. Keep your pace steady. Some slack time is nice, but you need to keep your team challenged or they will challenge themselves in ways you wouldn't have chosen.
When your customer learns something important about requirements or a competitive advantage you make a new plan. Changes to requirements are welcome because we have already decided we will be making new plans anyway.
The changes we get late in a project are usually the most valuable because that is when we know the most about our problem domain and solution. Consider every dollar spent on development as also being spent on learning about a better solution. The last change request is always the one you paid the most for, so use it to your advantage.
Iterative planning is exactly what you think it is; make a plan, build some software, and then make another plan based on what you learned. Agile processes are based on the idea that planning throughout the project is just as important as having a plan. Things change, plans must either be short in duration or very sketchy in details to remain useful.
How do we know how much we can get done in an iteration or sprint? We need to talk about creating honest plans.