Agile Management is a nice idea, but as Ivar Jacobsen acknowledged in his recent talk, agile approaches just don't fit some business conditions.  Many contexts are challenging for agile methodologies:
•    Large systems where no single customer can represent
      all stakeholders.
•    Customers who don’t have time to be “on site” with the
      development team full-time during development.
•    Customers who want (or who are required!) to only sign
      contracts where they know what they’ll be getting.
•    Many/large development teams.

If an agile method won't fit your business, Ivar said that companies can often usefully adopt "30%" of the agile practices.  One of these, and a key practice in agile approaches, is iterative development.  Even if you can't reach some idealised nirvana of "Agile Management", you might still get some benefits by being more agile.

Trouble Iterating with the Waterfall Lifecycle
Adopting an iterative project management lifecycle isn't always easy.  In particular, it's hard to use an iterative approach if you think you're using the waterfall lifecycle model.  Pictures of the waterfall model often show "back links" connecting later phases back to earlier phases, but if you follow those links you'll end up with a "spaghetti" projects, not a simple or systematic approach for iterative project management.
Ivar presented the waterfall lifecycle as a strawman "unsmart practice" in his talk.  He asked how many people in the audience were using it, and hands shot up all over the room.  I was surprised, because in my experience what most companies use is more like the "V" lifecycle.

Simple Iterations with the V Lifecycle

The Classic V Lifecycle, shown at left with three levels for illustrative purposes, helps visualize how test planning should progress as a parallel activity along the dotted lines. The well-known advantages of the V lifecycle are that it shows how testing lines up with planning at each level of abstraction, and shows how you can progress test planning early in development, concurrently with implementation.
So, how do you do iterative project management using the V lifecycle?  You can use the abstract structure of the V lifecycle to provide great flexibility for iteration. Normally people think of the V lifecycle as a “big V”, spanning an entire development project.  The first obvious way to have an iterative V lifecycle is to have lots of sequential “little Vs” - each cycle up and down could be done as short V sprints.

But the naive, whole-cycle iterations of the V Lifecycle shown in Fig. 2 exposes the customer to each iteration.  Customers don’t usually want to run an acceptance testing and sign-off process every 2-4 weeks during development!  To address this, you can use a less obvious approach, which here I’m calling the Fractal V Lifecycle. I use the term “fractal” because it reminds me of the Sierpinski Triangle.  The Fractal V Lifecycle is really only quasi-fractal, because there’s only a finite few levels of recursion in a development lifecycle, and because the internal iterations don’t have to be regular or symmetric over the course of the development lifetime.

Flexible Iterations with the Fractal V Lifecyle

Let’s work our way there in small steps.   So to start with, consider that instead of iterating the whole V in each iteration, you can instead iterate some of the lower parts of the V more frequently.  So if you had two low level iterations, you’d have a W lifecycle!

Fig. 4 shows the generalization to the full Fractal V Lifecycle, where you can see that it’s possible to have many internal iterations at various levels of design abstraction.

When Do You End an Iteration?
One thing that the Fractal V Lifecycle doesn’t explicitly decide for you is when your iterations should finish!  This is a major difference between iterations in agile and traditional plan-driven methodologies: agile approaches have time-boxed iterations (usually between 1 and 4 weeks long), but traditional approaches have iterations defined by scope.  Your choice will probably be driven by commercial conditions - a scope-driven approach is a better fit with fixed-price contracts, whereas a time-boxed approach can fit with time-and-materials contracts.  The Fractal V Lifecycle is consistent with either approach.

For Project Management - Not Just for Software Development
The waterfall lifecycle and the V lifecycle have a heritage in software engineering methodology, but they are more broadly applicable. The V lifecycle represents a repeated pattern - Planning at one level of abstraction, Doing the implementation at the next level of abstraction, and Checking that the implemented solution satisfies the goals from original plan.  The following diagram shows this abstract view of one level of abstraction in the V lifecycle. (This is adapted from a diagram in a research paper.)

The abstract activities of Planning, Doing, and Checking in the V lifecycle are relevant to most project phases.  The principle of checking what's been done is fundamental to most systematic project methodologies for review and governance. An upshot of this is that you can apply the V lifecycle very early in the project lifecycle - arguably even before the formal commencement of a project.  The Fractal V Lifecycle lets you have lots of high level iterations before later on descending into detailed implementation during the project proper.

The Fractal V Lifecycle solves a problem - it lets you do iterative development when your customers only want to be involved at large infrequent milestones.   It gives you the flexibility to adapt your iterations to suit your business conditions and technical environment.   But it also retains the shape of the V, which lets you keep using your existing project management disciplines for process assurance and project governance.