BDDX 2012 Take Aways

This year’s Agile Testing and Behaviour Driven Development Exchange, BDDX, took place last Friday, 23rd November. It was full of great insight and I wanted to record my take aways from the event.

A central theme of the day was of stepping back, looking at how we see the world and testing to see whether it is still the required fit for what we were aiming to achieve.

In the opening keynote, Dan North started with Chris Argyris and the concept of ‘Double Loop Learning’ which Benjamin Mitchell has done so much work in bringing to the Lean/Agile community. Dan North summarised it as

“Double Loop learning is about stepping back and saying ‘is that even the right process? Are we even on the right track?’

He set us the homework to go and find out more about Argyris and Double Loop Learning.

Dan North and Gojko Adzic then proceeded to draw a model of software development, Mike Cohn’s picture of software delivery in Scrum and then move from that to a picture of a continually shipped product which starts off ‘rubbish’ but improves via feedback from the business.

This is in line with Guy Kawasaki’s rules of “Don’t Worry be Crappy” as long as you ‘Churn Baby Churn’ from his Rules of Innovation.

My key take away from this talk was that existing models of software delivery “declare success to early” to use Gojko Adzic’s phrase. That is, all to often we model the delivery of capability which has the potential to affect change rather than the impact of the change itself.

Saying we are done before that potential has been realised is premature, we are not answering the fundamental question of why we did the work in the first place and whether it was the right thing to do.

This is where Impact Mapping comes in, taking the focus away from ‘what’ has been delivered and shifting it to ‘why’. This is not a million miles away from John Seddon’s Purpose, Measures, Method.

This systemic view of the world was reiterated in there being a number of references to Kanban in the talks. Andrew Burfoot & Walter Badillo from Go Viral talked a lot about their Kanban systems, and their adherence to the rule of “value trumps flow, flow trumps elimination of waste.”

Chris Matts in his talk described Feature Injection as being a pull system, with the customer pulling value from the system through the value chain of features.

Just as the keynote urged us to step back from our view of software delivery and ask questions of it, so Chris Matts in his description of Feature Injection showed us how to do this at the scale of individual requirements.

Using specific examples, a model of the world is built up with each new example either confirming or breaking the model.

Like Dan North, he too set us a homework, to play ‘Break the Model’ with Lego bricks.

Lego

When I got home, I had a go at this and was struck by how deciding whether a piece fits the existing model is by no means black and white. You have to probe a bit. I started by modelling the bricks as being flat rectangles, then extended the model to include colour, then adding depth.

I then came across this piece which I really struggled to fit into the model. As I thought of how to describe it in terms of geometry, it dawned on me that I was only using a geometric classification by default and that it didn’t have to be the only way of modelling the bricks.

If the purpose of the model was to identify all the lego bricks that could be joined together to make something then did the size and dimensions matter at all? Children rarely care if their Lego models are uniform in colour. Could we instead just group together all bricks that can be joined to each other?

The shape of the model and the level of detail it contains is determined by the reason you are building it in the first place. We are back at “Why”

This put me in mind of Eric Evans’ Domain Driven Design. I was lucky enough to do Gojko Adzic’s two day Specification by Example course earlier this year. The lightbulb moment for me on that course was when Gojko referenced Evans “Refactoring to deeper insight” when we found that the model in one of the exercises did not adequately fit the behaviour we wanted it to support. The new behaviour had broken the model and we needed to change it for it to continue to be of use.

Having a model which we apply and make use of until it is superseded by one which is a better fit, either because the world has changed, our understanding of the world has changed or what we need the model to do has changed is a pattern we see throughout software development, from the processes we use down to the individual features we develop.

It is also one we find far from the world of software development. Throughout the day at BDDX I kept finding myself thinking of a book I read about twenty years ago, back when I was studying Art History in the early 1990s.

In his book Art and Illusion, subtitled “A study in the psychology of pictorial representation”, the Art Historian E H Gombrich opens his chapter “Truth and Stereotype” by quoting Immanual Kant

“The schematism by which our understanding deals with the phenomenal world…is a skill so deeply hidden in the human soul that we hardly shall guess the secret trick that Nature here employs.”

In a chapter which takes in the Bayeux Tapestry, Cezanne’s views of Mont Sainte-Victoire and Durer’s Rhinoceros he describes how the selective preferences, tools and mediums of artists affect the information images convey, and that over the years, the information pictures were expected to provide “differed widely in different periods”

When encountering something new, artists have selected an existing schema to apply to its representation and then adjusted and adapted from there. “The familiar will always remain the likely starting point for the rendering of the unfamiliar”

He concludes by saying:

“What matters to us is that the correct portrait, like the useful map, is an end product on a long road through schema and correction. It is not a faithful record of a visual experience but a faithful construction of a relational model.

Neither the subjectivity of vision nor the sway of conventions need lead us to deny that such a model can be constructed to any required degree of accuracy. What is decisive here is clearly the word ‘required’. The form of a representation cannot be divorced from its purpose and the requirements of the society in which the given visual language gains currency”

Again we are back to “Why” What is required?

What I find exciting about both the Lean/Kanban community and the BDD community is that both are actively engaged in encouraging and accelerating the breaking and correction of the models we use to underpin our work and so always be looking to improve what we do and how we do it.

This entry was posted in BDD, Kanban, systems thinking. Bookmark the permalink.

Comments are closed.