How transformation works in practice

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 transformation can start to be delivered straight away.

The goal is to find a way of producing the software that’s needed at an affordable cost with high enough quality that it stays useful 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 they need to do. Discovery, the first practice of BDD, helps you work in a more effective way and focus on the most important 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 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 if you take the time to break everything down before you start, that doesn’t seem speedy enough. 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 important features and reaching a shared understanding of them, you maximize the amount of work you don’t need to spend time on. 

So, you do less work. More importantly, you do the right work.

Customers often come to BDD because they’re looking to automate their testing so they can 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, so it has meaning to everyone who understands the business domain, and the automation gives you the opportunity to increase throughput. By applying BDD within an Agile context, you get efficiency, throughput, and quality.

Achieve Quality in Spite of 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 governmental 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 important part of that. BDD gives you automated acceptance tests that verify the software behaves correctly and delivers 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 documentation that is clearly incorrect. It may have been correct once, but it’s not correct anymore. 

With BDD, because you’re specifying requirements using business language, those specifications are the documentation. There are tools that automate that documentation, so you immediately see when the documentation and the system implementation diverge. They may diverge because someone’s introduced a defect, or they may have diverged because the documentation is out of date. Whatever the reason, you’re automatically notified when they diverge. 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 using 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 the outcome of those scenarios. 

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.

The post How transformation works in practice appeared first on SD Times.

from SD Times https://ift.tt/3lRZXHZ