Jeff Patton opened his presentation with some advice on giving speeches: start late, finish early and don't discuss anything you don't understand. True to this advice the session started a little late, but proved to be well worth the wait.

His premise was that while XP teaches you to question your practices we nevertheless seem to be moving towards a unified agile process - process rigour or rigour mortis? He conceded he was unsure, but that it left him jittery. And he then expanded with an example: accompanied by Pink Floyd, he introduced Roger, a PO who believes he gets this agile thing - each story is just another brick in the wall on the path to completion. He needs to deliver a complete feature set to a client on a given date. Luckily, he works with Melanie, a developer who is confident that they can deliver.

All starts well, with the burn-down chart tracking a smooth line towards completion, until a few iterations in where problems are discovered. No problem - new stories are placed on the backlog to address these. Suddenly, though, there are more stories but the same velocity - it's going to take longer to complete.

Roger has made a common mistake and confused iteration and incrementing. Jeff referred here to Fred Brook's No Silver Bullet and the concept of essential vs. accidental complexity. Essential complexity is the werewolf - there's no way to kill it and you need to learn to live with it. But determining that essential complexity is hard, perhaps the hardest part of software development.

Jeff also emphasised that the snowman model does not help in understanding this. The model shows each iteration as producing a potentially shippable product increment. Unfortunately, potentially shippable means different things to different people. He suggests instead extended the snowman to a four level construct - a product is made up of multiple releases, each of which contains multiple iterations, which are in turn made up of multiple stories.

An incremental model lets you build the solution piece by piece. The problem is that you may be building the wrong thing. Iterative processes allow you to grope your way towards the desired outcome, starting with a light sketch and filling in the details. However, this creates a new problem: how do you deal with the uncertainty of not knowing what you'll get, especially in an environment where a software release may just a pre-requisite for effort elsewhere in the company?

Jeff suggests three solutions:

Focus on business value

Software is built to serve business objectives. Instead of cutting stories when you find your date moving out, remove business goals. One business goal will map to an entire set of stories which rarely work in part. Software that only completes a section of all your goals is useless, whereas software that solves a subset of goals completely adds immediate value.

Don't choose the solution too early

The are many ways to crack a nut. There's no need to decide if you want a Porsche or a Mini immediately - instead, scope both solutions and choose those that will best fit your priorities and timeline.

Build the base and then polish

You can't build a bus without wheels, even if the engine is perfect. So start with the minimum and build an end-to-end system. Then revisit and add features, robustness, security, performance and polish. A system the customer can see working allows immediate feedback and, unlike modules built in isolation, can be delivered if required. It's better to deliver a system missing features than some perfect modules you cannot use. And there's even less point in building these features if you're not yet sure you're building the right thing.

Don't know what I want but I know how to get it

His closing thought echoed Johnny Rotten - we don't know what we want, but we know how to get there. Don't run agile projects like waterfall - not every iteration will produce high quality, shippable software. But you might just end up building the right thing instead.