Robert; I’m now very suspicious of any ‘my context always triumphs’ statements, because if the organisation never tried ‘x’ how do they know that their context trumps ‘x’? Of course, if you can say, yes we tried ‘x’ and in thru the mechanism of the retrospective we found that the developers said ‘Y’ so we changed ‘X’ to ‘Z’. … i say … let X=X.

Linda Rising’s “Deception” talk was one of my highlights, but Avi Bryant stole the show with ’1001 Iterations’ on the second day: A really inspiring, practical walk through of the evolution of a real project.

On naivety, I’d go one step back. When you go in with a **simpler** solution than your own minimal solution, then you have the epic win, because you *didn’t* understand the problem. You’d already overcomplicated things! Original credit needs to go to Brian Marick as well – I’m just the messenger.

A good example of a context where pairing, for example, isn’t feasible: distributed teams (like 7Signals), where the company deliberately recruits globally for people to work remotely. Conventional pairing can’t work, and tele-pairing tools are primitive enough to not be effective. Another example would be in your typical “big-business” organisation, where the devs work in narrow one-person cubicles and the management level you deal with have no authority to change the floor layout.

If you combine Mike’s message with Steve Hayes, I think you get a telling argument: context matters, but consider your choices and what you gain and what you lose. Continually look to improve, and be aware that not all attempts to improve will work.

Sounds like a good conference – wish I’d been able to set aside the time to go.