Given When Then – A Cynefin Case Study

Dan and I created the “Given When Then” pattern on August 23rd 2004, or rather, that was the day we realised we needed the “Given” part. On November 30th, I wrote a series of blogs explaining the format that Dan and I had created in its more familiar form. JBehave II , JBehave III, JBehave IV and JBehave and Postmodernism.

This experience report is best explored by considering it through the lens of the Cynefin framework. Although I read the Cynefin whitepaper before this time, I did not understand it until fairly recently.

Obliquity

Neither Dan or I deliberately set out to create the “Given When Then” framework. We were both working on other projects. Dan was working on BDD where he was trying to change the language of TDD using NLP to make it easier for people to learn TDD. I was trying to work out an analysis approach that would work with Extreme Programming. Dan had replaced TDD’s assert with “Should” and was having more success explaining TDD to people. A week or two before, we had traveled back from the Agile Development Conference together and we had realised that “should” was the language of specification.

On the day that Dan and I first came up with “Given”, our goal was for Dan to explain BDD with Mock Objects and Patterns to me as I was going on sales visits to clients and talking about something I had never actually done. As an amusing aside, several years later Liz Keogh told me it took her six months to remove the visitor pattern from JBehave v1.

The key point is that Dan and I were working on oblique problems. Dan was trying to create a better way to teach TDD and I was trying to learn TDD. We were not deliberately trying to create a pattern to allow non technical people to effectively communicate with Agile developers.

Activated Individuals

Dan and I did not create the “GIVEN” word. We tripped over it. It was literally a movie moment when I said something and Dan and I looked at each other realising it was something useful.

The night before I had been to see a friend researching a PhD in Historiography. Historiography is the study of Post-Modernism as applied to how history is understood and taught. Historiography shows us that the way History is taught, understood and interpreted is more a function of the context than the events themselves.

When Dan showed me the code for TDD with Mocks, my head was full of “Context” (thanks to my friend Rob) which meant I recognised mock objects as context. When I said “Mocks provide the context” Dan and I both realised it was significant as our goals had activated us to the importance of the statement.

The key point which Dave Snowden makes in his talks is that you need individuals in a heightened state of awareness to spot something important* You need experts to spot something subtle and significant.

Recipe Books and Chefs

Both Dan and I were “Chefs” in Dave Snowden’s language. I had a decade of experience of Business Analysis and was used to coming up with new approaches when needed. Dan had several lifetimes worth of experience as a developer, and in particular coaching developers.

As Chefs we recognised that “context” was a new ingredient that was missing from the meal shared between Agile developers and non-developers trying to communicate to them.

This was only possible because we had both served our apprenticeships, and had an understanding of how to combine ingredients that we knew the “GIVEN” was a new ingredient**.

Exaptation

BDD was designed for developers to more easily learn TDD. Dan and I adapted it to communicate between Non technical people and developers.

Actually, the “Given When Then” format is an exaptation of TDD. TDD has the steps Setup – Execute – Assert. Dan and I exapted the TDD form into a specification format that non developers could use to communicate more effectively to developers.

Multiple Safe to Fail Experiments.

I went off to develop Feature Injection while Dan developed JBehave and promoted BDD. Rather than focus all his attention on one BDD solution, Dan promoted and supported many open source communities as they developed tools. From JBehave, through rSpec, to Cucumber and SpecFlow, Dan has supported them.

So Dan engaged in Multiple Safe to Fail experiments in his search to realise a BDD tool that worked.

Cynefin

Thanks to Cynefin, I now have a better understanding of what happened when we discovered the Given When Then format. As a result in the future, I will have a better understanding the context I need to create in order for innovation to occur.

• GIVEN I use Cynefin to understand the world
• WHEN I look at situations going on around me
• THEN I’ll find new meaning

* I’ve watched three of Dave’s keynotes to find the point where he says this but could not find it. My wording may be wrong.

**A while later I realised that GWT was a subset of the use case. Unfortunately the Use Case is so bloated as a tool that it is not focused on specifying behaviour. The Use Case has become the jack of all trades and master of none.