Book Club: Behavior Driven Development – Discovery (Chapter 5)

The following is a chapter summary for “BDD Books – Discovery” by Gaspar Nagy and Seb Rose for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on BDD Discovery

DISCOVERY

“Explore behavior using examples

Written by the creator of SpecFlow and the author of The Cucumber for Java Book, this book provides inside information on how to get the most out of the discovery phase of Behaviour Driven Development (BDD). This practical guide demonstrates good collaboration techniques, illustrated by concrete examples.

This book is written for everyone involved in the specification and delivery of software (including product owners, business analysts, developers, and testers). The book starts by explaining the reasons BDD exists in the first place and describes techniques for getting the most out of collaboration between business and delivery team members.

This is the first in the BDD Books series that will guide you through the entire development process, including specific technical practices needed to successfully drive development using collaboratively-authored specifications and living documentation.”

BDD Discovery

Chapter 5

In this chapter, the author’s share their experiences of how to get business representatives fully involved in the BDD approach and what kind of challenges they might face.

“Collaboration means that team members with different roles work together to deliver working software. A team will include both the business (product owners, project sponsors, business analysts, etc.) and technical personnel (such as developers, testers, UX experts and operation staff).”

Chapter 5 – How to Get Business Involved

5.1 Learn From Your Peers

The key benefits typically attributed to BDD are:

• Reduced cycle time
• Reduced rework/rejections
• Reduced number of production issues
• Keeping the implementation costs of new features under control

5.2 The One Where Business is Not Involved

Challenges in getting the business to adopt BDD include:

• Have a default resistance against new methodologies
• See this approach as an overhead
• Be afraid of learning and infrastructure costs
• Have formal or legal distance from the team (e.g. the business Representative is a part of the customer, not the vendor)
• See BDD as a testing or a development technique

BDD should not be a developer-only or tester-only activity. Without business, consider the following options: (1) the situation is a temporary step towards full collaboration, (2) envision the scenarios as business examples with the business explaining the story, (3) focus the detailed requirement discussions as examples, and (4) present the results & methods to the business regularly.

“Without the business involved, unless the team is very business-focused and disciplined, the scenarios become technical, data-driven and dry. This removes the possibility that the scenarios will provide a constructive feedback loop between the business and delivery team – so the scenarios become an overhead.”

Chapter 5 – The One Where Business is Not Involved

5.3 BDD is for Solving Problems

BDD has no value unless it is helping solve problems, improve development efficiency, and produce better results. In order to get business engaged, pain points (or opportunities) must be found that exist in the current process.

Product Owner is Overloaded

BDD can help reduce the Product Owner’s workload. BDD improves communication efficiency by focusing on early, direct communication with the business, ensuring fewer misunderstandings and less rework.

BDD product owner activities:

• Participate in requirement workshops (e.g. Example Mapping)
• Review the scenarios
• Give feedback about the implemented application

Comparison to classic product owner activities:

• Writing specifications
• Presenting the stories to the team
• Discussing ad-hoc questions during implementation
• Collecting deviations from the expected result in the Sprint review
• Managing and prioritizing requirement-related bugs

Production Issues are Common

Production Issues are not only costly to fix, but can result in customer dissatisfaction and mistrust. BDD helps prevent production issues being introduced during requirement analysis and detailed specification.

The resulting reduction in production issues is the most easily measurable benefit of applying the BDD approach.

Challenge to Get the Product to a Deliverable State

There is and underestimated gap between implementing a feature and bringing it to a releasable state. Side tasks include: creating deployment packages, updating user documentation or verifying performance requirements.

To ensure that the application can be reliably released at short notice, the team should follow the continuous delivery (CD) approach. Continuous Delivery requires a team to work on the product in short cycles, where each cycle contains all the necessary steps to make the application deliverable. A high level of automation is required to perform the necessary verification and packaging steps.

• NOTE: The process that automatically builds, tests and packages each product increment as a potential deliverable is called continuous delivery. The process that also automatically releases each deliverable to end users is called continuous deployment.

To move towards continuous delivery, stories should be sliced up into very small chunks. Sometimes teams adopt an approach called horizontal slicing, where tasks are defined along the different layers of the application. Vertical slicing is a functional breakdown where each scenario represents a portion of the expected behavior and makes sense on its own.

Customers are Not Engaged with the Product

Customers who do not like or do not use the product often indicate a development process that does not focus on value. BDD encourages the team to focus on realistic examples of application behavior, so the product evolves according to the users’ viewpoint.

The collaboration techniques used by BDD can help UX expert involvement earlier.

Deadlines are Often Missed

Deadlines are set based upon an estimate of how long to deliver the set of required features (the scope), which can be missed. The key to the successful management of deadlines is to allow more flexibility in the scope: “Try to implement as much value as we can for the given deadline.”

BDD will not tell you how to cut the scope, but it does provide a framework for enabling functional cuts, even within a user story. Scenarios provide a functional breakdown of the story, and allow the reduction of scope by identifying and deferring lower priority behaviors.

Difficult to Get an Overview of Progress

Having a good overview of progress is essential to good project management. Delivered scenarios are an excellent indicator of progress.

The traditional approach of calculating an arbitrary percentage of work completed is not as effective.

Introduction of New Features Causes Side-Effects

The success of a great new feature in the application can easily be overshadowed by a bug that gets introduced at the same time. As the code-base grows the chance of a change producing unwanted side-effects increases.

Adopting BDD encourages good automated test coverage, where automated tests and scenarios are tightly connected to the requirements.

Once a change causes a failing test, it is easy to diagnose whether this problem is related to contradictory requirements or defects in the code. Automation test coverage acts as a safety net.

Not Being Able to Quickly React to Market Changes

In order match competitors in a changing market, the product development model must keep the cost of implementing new features low, while maintaining the quality of the application.

Experiments are valuable at the code-level and specification-level. The behavior framework for the product can be used by the product owner or the business analyst to investigate how the system behaves with different parameters or different user workflows.

Bug versus Feature Debate

Developers and testers build up their own solutions independently: the developers write the application code and the testers write the test cases. The redundancy might result in conflicts at the point when the two parallel worlds meet: when the test cases are used to test the application.

The rework and frustration can be avoided by reducing developers and testers to work on understanding the details of the requirements together.

Changes Regularly Requested at Sprint or Feature Reviews

The iterative development concept of agile is based on the fact that feedback for a feature occurs when business stakeholders actually see it demonstrated. If changes are discovered regularly during the review, then the details in the requirements are not being described properly.

BDD supports the detailed requirement analysis in many ways:

• By focusing on examples, ambiguities can be recognized and cleared up
• Since scenarios document the specification in a common language, misunderstandings are less likely to occur.

Product Owner Never Reads the Scenarios

A common situation is a product owner that never reads the scenarios. Scenarios specify how the application should behave. Confirm the Product Owner has access to the living documentation, whether it be stored in source control or a project tracking tool.

Integrate the publishing process into the continuous integration pipeline and make the result easily accessible (by adding a link to the project dashboard, for example). Improve how scenarios are tagged. Take time to regularly reflect on how the living documentation is being used by the business and what changes might make it more useful.

5.4 What We Just Learned

BDD depends on collaboration. Getting the business involved is key to success. The authors presented some tips based on experience to adopting BDD within organizations. There are two follow-up books to BDD Discovery: Formulation and Automation.

Outside Resources for Further Reading

Books:

• Adzic, Gojko. Specification by Example: How Successful Teams Deliver the Right Software. Shelter Island, NY: Manning, 2011.
• Nagy, Gáspár, and Seb Rose. The BDD Books: Formulation. In preparation. http://bddbooks.com/formulation.
• Nagy, Gáspár, and Seb Rose. The BDD Books: Automation with SpecFlow. In preparation. http://bddbooks.com/specflow.
• Adzic, Gojko. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. London: Neuri, 2009.
• Wynne, Matt, and Aslak Hellesøy. The Cucumber Book: Behaviour-driven Development for Testers and Developers. Dallas, TX: Pragmatic Bookshelf, 2012.
• Freeman, Steve, and Nat Pryce. Growing Object-oriented Software Guided by Tests. S.l.: Addison-Wesley Professional, 2009.
• Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Upper Saddle River, NJ: Addison-Wesley, 2009.
• Hendrickson, Elisabeth, Ward Cunningham, and Jacquelyn Carter. Explore It! Reduce Risk and Increase Confidence with Exploratory Testing. Dallas: Pragmatic Bookshelf, 2013.
• Kniberg, Henrik, Mattias Skarin, Mary Poppendieck, and David Anderson. Kanban and Scrum: Making the Most of Both. United States: InfoQ, 2010. Print/Web. https://www.infoq.com/minibooks/kanban-scrum-minibook.

Publications:

• J.-C. Chen and S.-J. Huang, “An empirical analysis of the impact of software development problem factors on software maintainability,” Journal of Systems and Software, vol. 82, pp. 981-992 June 2009. Dallas: Pragmatic Bookshelf, 2013.

Online:

• BDD Addict
• Liz Keogh
• Dan North
• SpecFlow
• Cucumber
• Example Mapping Introduction

Book Glossary

Behavior Driven Development (BDD) is an agile approach to delivering software.

Continuous Delivery requires a team to work on the product in short cycles, where each cycle contains all the necessary steps to make the application deliverable. A high level of automation is required to perform the necessary verification and packaging steps.

Continuous Deployment is the process that automatically releases each deliverable to end users.

Example:

• Context: describes the state of the system before the action takes place.
• Action: the event that causes the behavior to take place. It might be some action by a user, the system, a scheduled job, or any other stimulus that can cause the system to react.
• Outcome: description of the state of the system after the user or system behavior has taken place. It should contain enough detail to measure the behavior against expectations.

Horizontal Slicing are tasks or user stories defined along the different layers of the application.

Living Documentation is a form of documentation that represents the current state of the application, which is updated in real-time.

Kanban optimizes end-to-end delivery (“lead time”) by visualizing the workflow and limiting work in progress (WIP) to be able to detect and fix bottlenecks more easily.

Persona in user-centered design and marketing is a fictional character created to represent a user type that might use a site, brand, or product in a similar way.

Requirement Workshop is an activity where the team meets regularly, the purpose is to explore a user story, the scope of the story is discussed, the story is illustrated with examples, and questions are documented that no one in the workshop can answer.

Structured Conversation is a facilitated exchange of ideas that conform to a predefined form.

Test-Driven Development (TDD) helps speed up the feedback loop by demanding that teams write automated tests before they write the code.

Vertical Slicing is a functional breakdown where each scenario represents a portion of the expected behavior and makes sense on its own.

Series Navigation

<< Book Club: Behavior Driven Development – Discovery (Chapter 4)