The main line of the talk is a series of diagrams. Each explains how a set of practices work.

For example, the linear-log cost/benefit graph shows how estimate-free, greedy-algorithm planning generates more business value per unit time than does traditional iteration planning - and how that does better than big-bang planning.

Also, we show a math model behind the Promiscuous Pairing results, and then show other practices - planning, TDD, retrospectives, etc - where this model applies.

In all, we’re trying to lay down a few visual diagrams that people can use to guide their own self-discovering Agile experimentation process. These diagrams, and the ways of thinking they encourage, don’t help people do TDD. Instead, they help people understand what it is to design and test, various process-level axes that define the solution space, and how to identify directions to go which have a high likelihood of working. In other words, how, given whatever their current design and testing practice, to iteratively discover better and better ways to do it - passing right through TDD (and other practices) on the way.

I have already developed some of the diagrams; I will be finalizing a couple more before the conference.

Here’s a very rough schedule:

10 min: intro. Scope the session; state learning objectives.

20 min: the linear/log cost/benefit graph. What this means for planning. What it means for scoping and prioritization.

15 min: the graph that emerges from varying pair-swap time & its components (exponential decay * approach to an asymptote). Map this back to possible causes. Map forward again to suggest further experiments in how to pair. In the talk, this diagram will be in teh form of an equation (graph = graph x graph). For now, here’s all 3 on the same chart: http://svn.arlim.org/arlo_papers/Diagrams/performance%20by%20increment%2... .

15 min: Show the same model w.r.t. planning, code reviews, testing, the proces improvement process, and perhaps some other activities. Outline a process for testing the model’s applicability to a process, back-mapping to find forces, and forward-mapping again to develop experiments likely to result in discovery of significant process improvements. Uses, as an example, a mapping of code reviews that leads directly to pairing (provides a basis for how pairing works as continuous code review).

20 min: the third diagram. Not fully specified yet. We have a couple of rough ideas, and will be discussing and refining them between now and June.

10 min: wrap up. Discuss methods of thinking; how to use this sort of thing to guide experimentation to discover improvements for arbitrary processes. Invite to Open Space where we’ll work on this more, during the conference.