I just got the chance to listen to this interview with Arlo Belshee about Naked Planning ("Kanban Simplified"):

http://cdn2.libsyn.com/agiletoolkit/Agile2008_Arlo_Belshee.mp3

Highly recommended. My summary of Naked Planning:

• Teams work toward delivering Minimum Marketable Features - usually chunkier than User Stories but more relevant to customers. Think "administrator can set user permissions" vs what you might break that down to in terms of finer-grained stories.
• The dev team breaks MMFs into tasks as appropriate.
• Teams work on MMFs in a ratio of about one MMF to every two pairs.
• There is no estimation (it's usually wrong, there's no particular reason why the time before you start a story - when you know very little - ought to be when you assess cost). Instead a pure yesterday's weather approach is taken: you write down the date you start the MMF, and the date you finish it, and keep a rolling average days to complete an MMF - that becomes your "velocity" (no need for that word though).
• "Done" means everyone - customers, developers - determine that the MMF is done. That means development is finished, any follow-on discovery or bug fixing is done, support staff are trained up, and the feature is really ready to go out into the world and be used by users and create value.
• The MMF backlog is somewhere between 5 and 9, because beyond that prioritization (remember, we're talking about something chunkier than a User Story) is mostly useless. If it takes, say, 15 days to finish an MMF, on a two pair team with a 7 MMF backlog, you're out about 6 weeks - this is when any backlog typically starts to degrade a bit. At the outside you're planning for an entire quarter.
• One slot, that you try to keep empty, is reserved for fires. The customer can put in a fire card that the team immediately works on. You can only work on one fire at a time - others go into the backlog with the MMFs.

This is a sort of Lean/XP/Kanban fusion that Arlo created and refined on a project he heads up. It drops some of the weirder parts of XP-style planning and distills down to its more interesting ideas, and addresses many of the beefs I have with point estimates, velocity, and iterations in practice. At the very least it's food for thought.

And here's a video in which Arlo explains the planning board.

This thread on the Agile Systems Administration group is particularly good:

http://groups.google.com/group/agile-system-administration/browse_thread/thread/7c32b729aaa1079b

There's some great stuff in here about planning in a highly interrupt-driven environment, and I particularly like Allspaw's breakdown of ops work at Flickr (the "MumbleMumble" process). Anyone who's wondering what's generally involved in making webops go ought to have a look.