Alistair marches into the room behind a bagpiper: excellent entrance strategy. He then riffed on the funeral speech from Shakespeare's Julius Caesar ("I come not to bury Agile, but to praise him..."), incidentally mentioning Waterfall and Kanban as "honourable men", and launching into a really good keynote.

Basic premise: this agile stuff isn't anything special any more, it's common sense cherrypicked from good practice over the last 30+ years and is now dissolving gently into the mainstream. We're not the new kid on the block any more, and it's not all about small teams doing their stuff, but is opening out into new areas: life-critical systems, vast projects, etc.

He then went back to the roots of what we're all about - "people making ideas concrete in an economic context" - and likens software development to:

• A game, with positions, moves and strategies. Not an infinite game (where the point of the game is to keep playing it), though organisational survival, a product line, or a career path might be seen as such; not an open-ended game (like, say, jazz improvisation or IT systems); but a finite, cooperative game like theater (an analogy considered closely in Artful Making) or rock climbing. The game has two conflicting goals (deliver this round, and set up for the next), three possible moves (invent, decide or communicate), and always changes, with situations never repeating themselves. So what must we do? Set up projects so you can tell what's wrong with them as soon as possible, make sure people care, and ensure they can pass on information smoothly. These are the "people issues" of a project;
• A craft, with discipline envy of "proper" engineering (which in turn has discipline envy of applied physics). So we need to pay attention to our skills and the medium - at this point Alistair talks about Shu-ha-ri (the number of folks sitting in the intersection of the Aikido/Agile venn diagram is starting to scare me);
• Lean processes, with the unit of inventory being the unvalidated decision, whether that being at the feature level, a UI decision, a style choice or untested code. In manufacturing, rework is troublesome, in software, less so. Alistair talked about rework leading to 2 queues of stuff-to-do - in our world this would be features and bugs. In such a situation work can get disruptive or batched up - so minimise outgoing bugs and aim for continuous flow of minimal features.

A few other choice nuggets:

• The role of a tester is to check and clarify requirements, a test being nothing more than a highly refined requirement;
• The role of software architectures is to sequence technical risk such that it's spread appropriately throughout a project;
• Alistair worries about kanban leading to a continuous flow of work which humans can find depressing - "we need peaks and troughs", he says. I think anyone who's lived in the Fens might agree ;) He talked about use of R&D and Gold Cards to achieve some of this, or at least break the monotony of constant development.
• Retrospectives aren't post-mortems, they're tools for steering the project throughout its life