If you are currently applying agile principles and run into situations where the team’s outcome occasionally deviates from the business needs, you might consider applying Behavior-Driven-Development (BDD).
BDD is a mechanism for fostering collaboration and discovery through examples.
– Dan North
BDD is a way to “shift left” the validation of the work, ensuring it will meet the business needs. That means having an open conversation between empowered and invested team members at the planning stage, when the team first starts to break features down into sub-stories, acceptance criteria and tasks. It creates true shared understanding at the onset, leading to a highly successful outcome. In contrast, it is too often the case to only discover a missed or misunderstood requirement at the end.
Team members gain a deeper understanding of the business needs. Developers work with less stress and more productivity, knowing they have a map that will guide them through a sprint. Testers spend less time playing catch-up and more time on the creative and interesting aspects of their work, leading to both increased personal satisfaction as well as seeing positive effects on feedback loops and software quality. Business owners develop a higher confidence in the team and see the outcomes meeting and then exceeding their expectations.
Is it a here-today-gone-tomorrow fad?
BDD is not a passing fad. It is a natural extension of the agile principles and values, and is contributing to the increasing gap between the high performers and all others. At first blush these techniques may seem simplistic, but there is an underlying subtlety to seeing it succeed. It does best when applied to a properly working agile team that is empowered to make the best decisions for themselves.
Using these techniques can uncover some hidden flaws in your current process, which by its own merits may be very valuable. For example, discovering a lack of an open line of communication between the development team and the business, or discovering that the team lacks a sense of psychological safety (a key ingredient of high-performing teams).
How does it work?
Simply stated, the core of Behavior-Driven Development is the collaborative meeting held between developers, testers, and business, at the planning phase of a sprint. It is necessary that this planning is focused on a short time frame – say, two weeks. That makes it possible to have deep conversations that explore the furthest reaches of the intended functionality – because whatever functionality is being added will have to fit within a short time frame, which necessarily requires it to be small and therefore easily comprehensible.
Following the agile principle of “Working software over comprehensive documentation”, BDD sets its target to be working software that can be validated by the business in realistic scenarios.
By enriching the sprint planning session with empowered collaboration and invested team members, participants find themselves contributing in ways they would not have thought possible. For example, the developers can suggest differing technological approaches than had been originally specified. Testers can dissect the requested changes on a quality basis, and can suggest acceptance tests (which the business can decide are valid or not). These conversations may even lead the business to change their tack, which is an amazing outcome – consider the value of *not* having spent weeks working on the wrong thing!
A nice side-effect is that the examples discussed during this meeting can be implemented as automated tests, which removes the need to have slow manual testing of your regression suite – a common recurring pain for testers who have switched to Agile practices.
How can we transition to it?
Here is a suggested approach for adjusting paradigms to start incorporating BDD in your practices:
- Choose a team of innovation champions to spearhead a first BDD project. Insure that they are all highly capable, innovation-oriented, and (most importantly) are motivated to attempt a novel approach. We’ve found that the when an organization is preparing to make a significant change, the shared experience of having all team members take the same training ensures that everyone is on the same page. Our new foundational course can provide a common vocabulary and establish a baseline of mutual understanding.
- Choose a small project for which they may use BDD practices. To make these pilot-type projects most successful, we recommend the guidance of an experienced coach. By incorporating the assistance of experienced practitioners who can provide initial education and coaching to your teams as they encounter new scenarios, you can avoid veering off the beaten track and becoming discouraged when initial eagerness turns to frustration.
- Allow them to become acquainted with the thought processes and patterns. Once they recognize the value of using BDD, they may transition into assisting other parts of the company learn these approaches. Use their knowledge and skills to share knowledge with other teams, building a majority who have adopted and benefited from the new techniques.
Take a little time to do some research on this exciting and well-founded approach for building quality into your product. Look for upcoming classes on this topic at TechWell’s spring conferences or by reading articles and viewing presentations at AgileConnection. You may find that this is just what is needed to take that next step towards becoming a high-performing team.
