How transformation works in practice

by Joseph K. Clark

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 straight away.

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) and 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.”

transformation works

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 figure out how much work each of them requires. We then prioritize, which means we might only work on a few of them.

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 in a far more efficient manner 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 amount of 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’re looking to automate their testing to release more quickly and with higher quality. But there’s no return on investment. In fact, 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, meaning to 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

When delivering software at speed, it’s not enough to develop the required software. You need 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 make sure we’ve got 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 functionality required by the business.

Start With Documentation

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 that you’ve been shipped. Anyone who works in software has dealt with clearly incorrect documentation. It may have been correct once, but it’s not accurate anymore. 

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 because the documentation is outdated. Whatever the reason, you’re automatically notified when they divide. Then you can act, rather than needing to proactively schedule time every week, or every release, to review the documentation and work out 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’s potential time and cost savings for customers who adopt business language and tools that support BDD.

Related Posts

Leave a Comment