The essence of BDD is a change in how we think about what we’re going to build and deliver in thin slices. The increase in communication around that and increase in collaboration across an organisation can be hard work and expose conflict. Along with a little strife, adopting BDD helps us drive iterative delivery, which fosters more humanity and enjoyment in our work. To achieve results we should expect each BDD installation to be freshly prepared and constantly renewed through team reflection.

At Unruly, we work in the fast-moving market of social media advertising. Like BDD practitioners, we always want to be working on the most valuable changes to our systems, in the smallest slices possible. We practice a radical approach to this which is not based around tools or testing. Instead we've made a shift around who drives story discovery and planning. Our approach is radically different from BDD but we hope it might inspire you to break out the "pickle factory" of canned solutions.

This is your opportunity to fire questions at the conference speakers, plus voice your own opinion. If you want to do this in advance, use the twitter hashtag #cukeup.

As Inigo Montoya continually chides his companion Vizzini in The Princess Bride: “You keep using that word. I do not think it means what you think it means.”

In this talk Dan North attempts to unpack the popularity of these anything-but-agile methods and proposes an alternative that might just work in the enterprise. A combination of lean thinking, hypothesis-based change and giving people control of their own workplace could be the solution. It’s harder to sell certificates though.

Requirements:

• A laptop with Node.js 0.12 installed.
• Git installed
• Your favourite text editor
• Basic JaveScript knowledge, previous experience with it recommended

Pair programming (a.k.a. two people working on a single computer) is recommended!

The approach taken to understanding the problem, the target goals and ultimately the solution is often flawed from the beginning and those flaws weave their way into the DNA of the product development cycle. In this talk we’ll do an armchair retrospective of some of these high profile failures and we’ll take some ideas from the agile toolbox to discuss a more iterative and collaborative approach to product development that might have saved these organisations a lot of time, money and the goodwill of their customers.

This talk describes and critiques our experiences with using visual presentations of specifications-by-example for achieving client consensus on a recent project with a large healthcare provider in the UK. In the process, we describe a technique of using rich visual representations that parallel the textual specification-by-example scenarios. This allowed us to present the requirements to the stakeholders so they can understand, validate, and agree on them quickly and effectively. We illustrate the talk with practical examples from the project, and welcome discussion on the methods and approaches we have used.

She’ll also explore the limitations of BDD, and how the nature of innovative industries can defeat its best intentions.

What if we have it backwards and they were actually together all along? What if most of the misunderstandings and challenges we face in implementing BDD are spawned from the very simple mistake of us separating something that was created as a whole? In this talk we'll delve into BDD as it was meant to be done from the beginning and look at its clearly-stated objective of delivering software that matters.

Imagine instead transforming the room into a cheerful, creative place where team members and stakeholders are laughing and working together. Imagine remembering details about scenarios months after they have been implemented.

By illustrating your scenarios instead of writing them, the examples become easier to remember and overview, fun to create and also trigger our creative side.

We’ll cover how to start small, guiding development through use of incremental examples, giving the whole team a laser-like focus on the outcome, and helping the learning process start as early as possible.

We’ll explore ways of breaking the giant boulder down into small manageable pieces, using meaningful real-world data at every level of detail to facilitate great collaboration and feedback.

We’ll demonstrate the value of collaborating with real examples, driving conversations all the way to specific data from the start, identifying and solving domain problems early, and transferring this understanding into the design and implementation.

Exercises will help you use BDD practices in context, aiming to give the whole team some useful techniques to start using straight away, whatever your in-house development methodology.

This workshop is limited to 40 on a first come first serve basis.

ShouldIT? tries to make it simpler to communicate tasks that need to be done.

Playing on semantics that many spec’ing frameworks give you, a relationship map of your features can be made. Then with ShouldIT? visualisation you have a clear view of your entire project.

This can give you a clear indication of delivery progress that you can share.

• As a BDD enthusiast
• I want to use ShouldIT?
• So that I can have simpler feature files and can test in any language

In this talk we'll provide the audience with distilled tips that works for us, on how to approach user stories, acceptance criteria and scenarios. We are aiming to involve the audience with a couple of practical exercises.

In this talk Lukas will explain all, using code as the basis, but using ideas that transfer to other realms.

Then he will investigate how a small amount of math can demonstrate why bankruptcy comes more quickly than most would expect. He pulls together ideas from Organisational Change Management and Metcalf’s Law and connects them to the quality of the code base, and how easy systems are to change.

Be prepared for some novel, innovative and challenging ideas, whilst getting an intuitive sense of how complexity in multiple dimensions affects the ability to make changes over time. And keep your ears open for a reference to the Iraqi Army.

I'll share some experiences from recent projects and thoughts on the essential nature of TDD and BDD.

Many start using Cucumber as a testing tool, but fail to realize its true value as a team collaboration tool. What essential team skills might be lacking? If you are wondering why your team is struggling to put BDD into practice, perhaps they lack crucial skills they need to succeed with BDD, and may not even know it. Or if your team is doing BDD but unable to take it to the next level, what is missing? This workshop explores critical, but often overlooked, skills teams need to practice and master in order to move forward in their BDD journey. It is open to all those operating in software - developers, testers, BAs, products owners - all are welcome!

*All workshops are limited. The sessions are on a first come first serve basis.

When Woody Zuill first started using the hashtag he sparked a debate that has caused tempers to flare and blood to boil, but Woody himself doesn’t think that estimates are inherently bad:

“If our response every time we reach the end of a project is to say ‘we must produce better estimates’ then we’re in a cycle of continuous ‘no improvement’”

In this session we’ll cut through the #NoEstimates rhetoric and sketch out the dysfunctions at the heart of software development that gave rise to the hashtag in the first place. We’ll investigate some possible ways that we can turn this around, so that we can improve the outcomes for customers AND development teams. We might even find out how to use estimates effectively.

We’ll work in small groups, in 3 Amigos style, using detailed examples, to demonstrate the value of delivering small, low-fidelity pieces of work early rather than prematurely focusing on fully-polished final versions.

By the end of this session, you’ll see that small IS beautiful, and understand just how small, small can really be.

You will come out of the workshop with a working knowledge of good & bad hypotheses, some pitfalls & how to build the right things and not just build things right.

*This workshop is first come first serve and limited to 35

For more information on concepts explored in this session, head to dannorth.net.

noun de·test·ta·tion: intense hatred or abhorrence of gherkins

noun de·gus·ta·tion: the action or instance of building a taste for gherkins through a series of small portions

Do you think all tests taste the same? Can you tell a Michelin starred test from a greasy spoon, roadside café test? All tests may fill you up but what about the subtle tastes, the gastronomy, the outcomes of the testing? This session, through a number of courses will aim to build your palette, to help you identify the tastes and smells of well structured tests, tests which deliver more than just removing your hunger.

This workshop is limited to 30 and is first come first serve.

We'll then split into pairs and see who can build the best new formatter for Cucumber-Ruby in the time available - voted for by the workshop participants.

Steve is a member of the Cucumber-Ruby core team, and will be on-hand throughout the workshop to offer help and guidance.

Prerequisites

Attendees will need to bring a laptop with a reasonably modern version of ruby (2.0+) and a text editor. You are encouraged to work in pairs.

We'll then split into pairs and see who can build the best new formatter for Cucumber-Ruby in the time available - voted for by the workshop participants.

Steve is a member of the Cucumber-Ruby core team, and will be on-hand throughout the workshop to offer help and guidance.

This workshop is limited to 30 attendees. Attendance is first come first serve.

- The Good (BackLog)
Middle managers should be ensuring that you adopt the right approach to filling the backlog. We will introduce the Cynefin Framework to identify the appropriate approach to filling the backlog for your context. There is a fun exercise to make this real!

- The Bad (Risk)
Middle Managers should be the "Catcher in the Rye". Instead of imposing process, they should identify risks that need to be managed, and then coach the teams to acquire the skills to manage the risk. You will get practice at this in this part of the session.

- The Ugly (Culture)
Culture eats Strategy for Breakfast. It also eats Change initiatives, Good intention and the Will to live in many of us. The problem with Culture is that it is invisible to us. Play a game called Given-When-Then to help you see your culture, and to decide on what needs to be done so that your Manager can house train it so that it doesn't ruin everyone's fun.

*All workshops are limited. The sessions are on a first come first serve basis.

But I have also seen how BDD done really well transforms the way teams work together, building trust and camaraderie between different disciplines, increasing morale, productivity and staff retention. This is the real business value that BDD brings, building high performing teams with a lasting effect well beyond the delivery of the code to production.

Quite often we apply established economic trade off’s taken directly from manufacturing to knowledge work without questioning their validity in this different context.

Given that our work systems are complex in nature (as opposed to complicated cynefin fans) the relationships between variables that we can affect are not clear and often contrary to what we might expect.

In this highly interactive and practical session (bring your gym kit…...only joking), Ben and Tom will take you through an experiment driven approach that will highlight why we often need to stop starting and start finishing.

We will uncover relationships between;
1. Local and Global WIP levels
2. Batch size
3. Bottlenecks
4. Utilisation
5. Arrival rate
6. Push versus Pull
7. Quality

Thousands of companies around the world rely on Cucumber to tell them whether their software works or not. Yet for years the codebase for Cucumber carried the same scars as your codebase probably does: a top-heavy test suite that was brittle and took too long to run and a domain model that lagged behind our current understanding of the problem.

That was then, and this is now. Learn how Cucumber 2.0 has solved a lot of these problems. Learn what we’ve learned from the project: about releasing into the market early, about slow software, and about how having a good domain model fixes everything.

It is hard to get up to speed with Behaviour Driven Development, although the concepts are explained easily enough. To do it right, you have to learn how to interview your business users, choose your examples, properly write them up as scenarios, choose a framework, and only when you’ve got all that covered, you get to code to your scenarios. For this dojo we’ll be sure to arrange all these preparations for you, so you can hit the ground coding.

We will prepare for coding in Java. Please bring a laptop with IDE.