In the past, at Aquila Heywood, we followed a very traditional approach to software development. The requirements were primarily gathered from the users by consultants and refined by business analysts, then converted into a 'cast-in-stone' specification and handed over to the development teams. The benefit presumably was that everything was written down and a two-level approach of verification could be applied. This meant that developers and testers followed a single specification and reached the same desired conclusion: the product deliverable.
It works in theory, but the problem in practice is that things get lost in translation. Ask two people to describe the same problem and they will explain it in completely different ways. When it comes to complex solutions, a lot more needs to be communicated than just a specification. Additionally, when using a traditional approach, the feedback loop is too long. By the time the user receives the final product, it is often too late and costly to change things.
I'm sure you have all come across the below image on the Internet. The creator probably intended it as joke but, if you think about it seriously for a second, you will realise that it depicts the reality of traditional software development very closely. All six pictures show the same product from a slightly different perspective. Each perspective is based on the same basic components and features (swing mechanism, a rope, support from the tree) and yet the final product is entirely different and - dare I say? - not suitable for purpose.
As Aquila Heywood shifted towards Agile, we introduced and adopted a Behaviour-Driven Development (or BDD) approach. This is a software development process that promotes communication - lots and lots of it. Unlike a traditional approach, there are no strict roles for developers or testers and no designated business person who is the only communication channel between the developers and the user. BDD blurs all the lines that were traditionally considered good practice. And yet it somehow works!
So how does it work? The BDD approach uses a series of examples or 'behaviours' (also called 'features') to explain what the final product should do. It all starts with a simple description of the behaviour. This is refined – a process where all the stakeholders are involved. The value in this is that communication with the end user happens at all stages of the process. The feedback loop is, therefore, very short and ensures that the user gets the product they want, rather than a distorted interpretation. The product is potentially shippable at the end of each sprint. The user is able to see the product quickly, so any changes or enhancements can be incorporated through a system of 'inspect and adapt': a big improvement over our earlier practices.
Here are a few BDD highlights that we at Aquila Heywood have come to admire particularly: