My colleague and I are setting up an agile consultancy within an existing consulting firm, Qualogy. Our mission is twofold – spread the agile word, increase agile expertise among our own consultants and build and promote an agile services portfolio. I've been involved for about a year and although we have a long way to go, things are really beginning to take shape.
Because of the nature of our mission we are always looking for ways of killing two birds with one stone. For instance, we offer (agile) training to our partners and clients, but also to our own consultants, which has the double function of increasing agile expertise all round while hopefully making a name for Qualogy as an agile provider. This is easier said than done however and we're not the first to think along these lines; the market is nearing saturation point. We try and set ourselves apart by concentrating on technique over process and by getting the very best to come and offer courses not easily available elsewhere (in the Netherlands). For example, Ron Jeffries & Chet Hendrickson have been to Qualogy twice to deliver hands-on agile development training.
Recently we added Gojko Adzic's Specification by Example training to our portfolio. As is our policy, Wouter & I attended this first instance of the course at Qualogy. Due to some late cancellations from our own consultants we could only claim a tarnished victory – good service to our clients, not much penetration among our own consultants. This slight disappointment did not impinge (much, after a while :-)) on my enjoyment of the course though. As is always the case with when attending these courses, I'm not just interested in the material but also in how the course is run. Adzic was a joy to watch.
This post is not however about the course itself, or even Gojko's admirable delivery of same. As Adzic himself writes, and as was clear from how he delivered the course, Specification by Example is method/framework/etc. agnostic. He tended to use lean terminology during the course, speaking as he did of bottlenecks and/or the theory of constraints as opposed to impediments for instance, while at the same time, his explicit insistence on cross-functional collaboration smacked of agile. What I would like to share from my learning is the realisation that Specification by Example (or BDD or A-TDD) might well be the M (mashup) we so badly missed at CALM alpha!
At CALM alpha, Dave Snowden named three heuristics that seemed to offer common ground between (social) complexity, agile and lean; fine-grained objects, cognitive spread and dis-intermediation. Fine-grained objects meaning; small well-defined stories, short clearly-demarcated iterations etc, cognitive spread meaning; input and reasoning from multiple perspectives & interests, set-based design etc and dis-intermediation meaning; visualisation, no separation of design & implementation, narrowing the gap between information and meaning etc.
Back to our Specification by Example course – Gojko was prompted a number of times during the course to state that any specification which required an ever-growing list of examples to illustrate it should be split. While working on turning 'classic' requirements into specifications with examples, merge&diverge was explicitly employed to ensure the best results. But it was while examining a bunch of specifications with examples for how useful they might be as respectively, a tool for shared understanding, acceptance tests and/or documentation, that I was struck by why I had found this idea of living documentation so powerful all along.
Requirements that are tests that are documentation – no handovers, no translations, no interpretations, no esoteric jargon pitting one guild against another – that's lean, that's agile. Specification by Example is the ultimate in dis-intermediation!