Transformations take time. People think you can bring in a tech transformation coach, change everybody’s job title, and get them on a quick “sheep dip” of a certified scrum team member. But in organizations, transformation happens incrementally. The good news is that the benefits of change can start to be delivered immediately.
The goal is to find a way to produce the software needed at an affordable cost with high enough quality to stay valuable over time. This is where Behavior-driven development (BDD), automated testing, and quality practices come in.
Go Fast, Start Slow
One challenge to achieving quality at speed is that people want to dive into a project without knowing what to do. Discovery, the first practice of BDD, helps you work more effectively and focus on the most critical aspects of your project. Discovery ensures that we don’t start doing something and then say, “Oh, I didn’t think about that,” or, “I misunderstood what I was being asked to do, so I need to throw away what I just did and start again.”
Discovery builds on the Agile techniques of deferring detailed requirements planning until the last responsible moment. Essentially, Discovery lets us slice our user stories into the smallest practical increments and then study those in detail to determine how much work each requires. We then prioritize, meaning we might only work on a few.
Discovery Accelerates Quality
Someone might object to this process because you take the time to break everything down before starting. But in reality, you work far more efficiently after completing these steps. You begin the project by cutting out the stuff you don’t need to do before you waste any time doing it. By prioritizing the most critical features and reaching a shared understanding, you maximize the work you don’t need to spend time on.
So, you do less work. More importantly, you do good work. Customers often come to BDD because they want to automate their testing to release more quickly and with higher quality. But there’s no return on investment. There’s a cost because that level of automation is time-consuming to write, hard to debug, and costly to maintain.
With BDD, on the other hand, you start with Discovery, which means you get to a shared understanding. You prioritize just what you need and no more. You formulate it in business language, telling everyone who understands the business domain, and the automation allows you to increase throughput. By applying BDD within an Agile context, you get efficiency, throughput, and quality.
Achieve Quality Despite Risk
It’s not enough to develop the required software when delivering software at speed. It would help if you had the confidence that the quality level is compatible with your risk appetite. This is where the secondary output of BDD comes in: the automated tests.
Different businesses have different risk profiles. It’s not a disaster if a pizza order goes missing, but if your business is subject to government health regulations, getting a small thing wrong means people might die. We need to understand our risk profile and ensure we have processes in place to ensure the software we deliver matches that risk profile. Automated testing can be an essential part of that. BDD gives you automated acceptance tests that verify the software behaves correctly and provides the business’s required functionality.
Start With Documentation
Anyone who works in software has dealt with clearly incorrect documentation. It may have been correct once, but it’s not accurate anymore. Everyone who’s ever put together a piece of flat-pack furniture, or bought electronic goods off the internet, knows that the instructions often don’t appear to relate to the device you’ve been shipped.
With BDD, because you’re specifying requirements using business language, those specifications are the documentation. Some tools automate that documentation, so you immediately see when the documentation and the system implementation diverge. They may separate because someone introduced a defect or split. After all, the documentation is outdated. Whatever the reason, you’re automatically notified when they divide. Then you can act, rather than needing to schedule time proactively every week, or every release, to review the documentation and determine whether it’s still correct.
End with the Language that Everyone Uses
Industries that deal with external regulators can particularly benefit from BDD, which writes the specifications in business language. Those specifications, directly automated, verify the software is behaving as expected. Running these specifications can be helpful to non-technical people. Because it’s written in business language, people can see which scenarios are being checked and their outcomes.
The regulatory authorities are thrilled to get this in business language so they don’t have to go through hideous spreadsheets. There are potential time and cost savings for customers who adopt the business language and tools that support BDD.
