Matt Wynne

Example-guided development is a suggested new catch-all term for the family of practices variously known as Test-Driven Development (TDD), Behaviour-Driven Development (BDD), Acceptance-Test-Driven Development (ATDD) and Specification by Example (SbE) that has been causing a bit of excitement in the agile community. This post aims to give you a summary of where this new term comes from and why it could make a useful addition to our industry's vocabulary.

This weekend marked the 10th anniversary of Cucumber's first release, and we decided to celebrate with an open invitation to our community to join a mob programming session.

The Cucumber Pro product team has been practicing mob programming for almost two years now. We’ve had periods where we drifted back to working in pairs, but for the last nine months mobbing has explicitly been our default behaviour as a team.

I think we’ve learned a lot from that, and I want to share some patterns I’ve noticed. As you read these thoughts, you should be aware that our mob is almost exclusively remote. We do meet up about once a month, but we tend to spend that time around a whiteboard rather than a keyboard.

I absolutely love open space.

Over the last couple of years, we've been privileged to be trusted by some of our best transformative coaching clients to run open space events in their organisations. I'm now convinced that these events are crucial in powering the cultural shift towards true agility in software development.

In this post I want give you a sense of what an open space is like and share some practical advice about how to run your own open space event.

I've never liked working in hierarchical organisations. One of the reasons we were all drawn to work on Cucumber the open source project, I think, is that we all enjoy that beautiful combination of autonomy and community. As we set out to build a company of our own, I've been searching for ideas about how to structure our organisation so that we can keep the spirit of the original open source project alive in everything we do.

One source of inspiration I came across on this search was Enspiral, a collective founded in New Zealand. They use collective decision-making, and fund ventures from within the collective using a collaborative budgeting method. Started as a small group of friends in a co-working space, they have grown to 40 members and over 250 contributors, with successful ventures like Loomio.

When I learned that Enspiral were opening their doors to share their culture and methods in a series of half-day workshops, I had to be there.

Before you pull a user story into development, it’s crucial to have a conversation to clarify and confirm the acceptance criteria.

Some people do this during their backlog refinement or planning poker sessions. Other teams have a specific three amigos meeting, specification workshop or discovery workshop.

Whatever you call this conversation, many teams find it hard; it’s unstructured, it takes too long and gets boring. The result is they don’t do it regularly or consistently, or maybe they just give up on it entirely.

I’ve discovered a simple, low-tech method for making this conversation short and powerfully productive. I call it Example Mapping.

According to E. F. Schumacher, there are only two kinds of problems in the world:

• Divergent problems
• Convergent problems

Choosing a new car is a convergent problem. You only need one new car. There are lots of options, and the solution is to whittle down those options until you've found one that meets your needs. Once you're there, problem solved.

If you've never bough a car before, you'll need to research all the different options available. You might also want to consider alternative modes of transport - why do you even need a car? Could you make do with a bicycle or public transport? This is an example of divergent thinking.

Cucumber is a simple tool. It takes phrases written in plain language, finds snippets of code that match those phrases, runs them, and tells you whether they threw an error.

How you organise the code that Cucumber finds, is up to you.

What you get that code to do, is up to you.

If your Cucumber suite is slow, or hard to maintain, that's because the code you've asked Cucumber to run is too slow, or too complex.

There are lots of names for the conversations we have to prepare user stories for development. Some people hold Three Amigos or Specification Workshops, some hold Planning Poker or Backlog Grooming sessions. Whatever you call this work, essentially you're trying to answer two questions:

• What do we want to make?
• How will we make it?

These two questions form a dynamic: when a clearly-defined requirement turns out to be complex to build, developers and product owners can usually negotiate to find a simpler what that has a more straightforward how. Similarly, product owners may not be able to clearly define what they want until they've had a chance to have it examined by the people who will think about how to build it.

I recently watched a team having what they called a Sprint Planning meeting. For this team, that meeting was their opportunity to have this conversation. As they laid out the stories for discussion--each on 5"x3" index cards--I came up with a suggestion.