Victoria Holland – Java Developer

On Tuesday 21st October I attended the Behaviour Driven Development (BDD) Workshop facilitated by Seb Rose at the King’s Centre in Norwich.   Although I have some experience of Agile development techniques, I came to the workshop with no previous knowledge of BDD.  I chose to attend the day-long course as part of my continuous personal development objectives for 2014, as I was interested in gaining an understanding of BDD and seeing if it’s something that can be implemented in my team’s day-to-day work.

Introductions and objectives for the workshop

For the first activity of the day, in order to find out about each other, each of us interviewed the person sitting next to us (asking name, job title/company, previous experience with Agile & BDD, and goals for the day) and fed this back to the rest of the attendees.  Seb then outlined the objectives for the workshop:

• understanding what BDD is
• practising and identifying examples
• building consensus about when to use these techniques within your team.

History and aims of BDD

Seb then talked about the history and reasoning behind BDD.  The Agile software development manifesto was created in 2001 and BDD was devised soon afterwards. It is designed to address the weaknesses of existing development methodologies such as the waterfall method. Depending upon which academic study you read, the failure rate of large systems projects is reported as being between 50%-80%.

The main advantages of BDD are that you get continuous feedback from your customers, and you have predefined criteria for the success of a project.  Getting continuous feedback is crucial since the cost of changing your requirements increases dramatically as the project progresses.

BDD builds upon test driven development (TDD).  In TDD, you work from the outside-in, use examples to clarify requirements and develop and use a ubiquitous language (ie a language without ambiguity).  In BDD, you also focus on value, discover examples collaboratively, and create living documentation.

Seb explained the problem domain and solution domain in software development.  Stakeholders, customers, users, business analysts and project managers are focused on the problem domain.  Programmers and testers (including tech leaders and solutions architects) are focused on the solution domain.  BDD is key towards getting these two groups of people to communicate across the divide.

Deliberate discovery

For the second interactive task of the day, we split into several groups where some of the members were regular users of Twitter and others were non-users (or not so regular users).  The idea was to talk about how Twitter works and the less experienced users could ask questions of the more regular users.  In BDD, this type of process is known as “deliberate discovery”.

Everyone in the group learnt something, including the experienced Twitter users. For example, in my particular group we discussed why the maximum length of a tweet is 140 characters.  I knew that the character limit for SMS messages was historically 160 characters (although modern smartphones concatenate longer messages seamlessly), but although I am a regular Twitter user I wasn’t sure why the tweet character limit was 20 characters shorter.  It turns out the reason is that Twitter usernames can be up to 15 characters long, and 5 additional characters are reserved for the “RT @” at the beginning of an old-style retweet. So this ensures that a tweet could fit comfortably within the SMS character limit.

The “3 Amigos”

In BDD, deliberate discovery takes place during a “3 Amigos” workshop.  This consists of a product owner, a developer and a tester, although it is permissible to invite more than 3 participants to the meeting – for example you could also have a user experience expert and a facilitator.  As long as there is at least one representative of each of the aforementioned groups, that is fine. Thus, it involves bringing together people with different views and asking them to discuss user stories, acceptance criteria and examples.  Everyone has to participate in the discussion and challenge the current understanding of the project requirements.

A user story describes what a user does or needs to do as part of their job role.  Acceptance criteria are the high-level rules and requirements for a project or product.  Examples are intended to illustrate the rules and to explore the acceptance criteria.  The advantages of concrete examples are that they help to clarify misunderstandings, identifying one example helps us to see others, and they also help us to explore the scope of a project.  Furthermore, examples are ripe candidates for creating automated tests.

Seb recommends using colour-coded cards during the 3 Amigos workshop:

• Yellow for user stories
• Blue for acceptance criteria
• Green for examples
• Red for open questions

Rules vs Examples

Before breaking for lunch, Seb set us a task which involved splitting into teams to play a “Rules vs Examples” game (also known as the passwords game).  The scenario was that we were working for a bank, and each team had to devise 3 rules for users to create a password.  For example, one rule could be that the password must be at least 8 characters long.  Then we had to write down 3 sample passwords on a card – 2 of them were valid according to the criteria, and 1 was invalid.  Then we passed the card to the team on the neighbouring table (letting them know which passwords were valid and invalid) and they had to try and reverse engineer the rules using a process of deduction.  Then once the rules had been deduced, they had to create a new password that meets the criteria.

The task was very difficult as we were relying on the examples alone.  The purpose of the exercise was to demonstrate that we need both rules and examples when defining project requirements.

A 3 Amigos workshop in action

In the afternoon, we all split into groups of 4 or 5 to participate in a sample 3 Amigos workshop.  We were all given the scenario of working for a startup building a Twitter clone called Squeaker, and each group was given a separate feature to discuss.  My team’s task was to brainstorm the features related to following users.  Our fundamental user story was “As a user, I want to be able to follow a user”.  The acceptance criteria for this story was being able to successfully follow a user after searching for their username, and one of the examples was that when you search for a user named Fred (assuming this is a unique username), you will then be successfully following him.

This particular group discussion became much deeper than I originally anticipated.  One user story and acceptance criterion would lead to another – for example, we ended up discussing what should happen if a user is on the website and their internet/3G connection drops out just as they click on the Follow button – should an error message be displayed, and should the follow request automatically be resubmitted once the internet connection returns?  For some of the more open questions, you may need to ask someone else in the business for clarification and come back to it later.

Discussing how BDD could fit into your team

In the final task of the day, Seb asked us to split into groups depending on what company we work for, and discuss how BDD could fit into our day-to-day work.  There were large numbers of people from both Aviva and Proxama, who split into their own groups.  The remainder of us (which included me, as I was the only attendee from Archant) formed an “independent” group where we agreed by consensus who (eg, developers, business analysts, testers etc) should do each part of the BDD process and the timescales for these processes.

Final thoughts

In summary, I found the course very interesting and I have plenty of new knowledge to take back to my department.  I liked that the workshop was very interactive and I had the chance to speak to people from a variety of companies and backgrounds.  I found the last task of the day (working out how BDD can fit into your team) quite difficult as it seemed to be aimed more at project managers/business analysts than developers.  Overall, I feel that I now have a much clearer understanding of BDD and how it can be put into practice.