Delivering to a set of requirements may be contractually sound but it’s no longer good enough
In the consumer market, companies launch beta products to generate user feedback and drive effective software development. However, this isn’t always easy in the public sector with Government customers. Often, user needs are passed to procurement departments to go out to public competition. Proposals from potential suppliers are then assessed along procurement-led criteria including price (or Most Economically Advantageous Tender – MEAT) which is understandable to allow fair competition and the best deal for the public organisation. But, there is risk that essential user-needs are diluted during the procurement process if those very needs are not at the centre of the process, including how those needs are to be met.
Thereafter, those user-needs are at risk of further dilution if the successful supplier has a supply chain where a list of deliverables is flowed down to the smaller, more agile companies. These companies soon become completely detached from the end-user without an ability to truly understand the end-user experience and the user story.
So how do we bridge the gap between understanding the user, understanding why a problem exists (based on business outcomes), and agile development? How do we prevent delivering to a set of requirements that are technically functional but do not solve the problem the customer faced in the first place?
Behaviour Driven Development
Behaviour Driven Development (BDD) is an agile software development process (based on the test-driven development principles) that encourages collaboration within a project through continuous, example-based, communication between the end-user community and the development and QA teams. This process, with its enhanced levels of communication, enables the technical team and the customer to reach their end-goals more freely as the customer’s desired outcomes are more definitively discussed and outlined. Put simply, there should be no misinterpretation of objectives or outcomes, with a potential cost of translation, between technical and business stakeholders.
Of course, this requires increased and continuous engagement with the customer from the beginning, and at regular intervals, to provide feedback on assumptions so that corrections can be made before each sprint cycle rather than accentuated by the end of the development.
Benefits to the Customer
The benefits are proven with no surprises at the end of the process and no ambiguous assumptions or “grey areas”. That increased investment through continuous engagement from the customer in the sprint cycle is well worth its return on investment. After all, who in the public sector does not have experience of programmes failing to deliver what was required, leading to lengthy contractual negotiations to find a compromise to fix the problem with a project already late and over-budget.
Benefits to the Development Team
BDD also means that the focus is on getting a clear understanding of how the software needs to behave for the needs and wants of the customer, and why. The development team can then maintain their own focus on why certain sections of code are required, hopefully avoiding the tendency for a fixation on technical details. This is a faster and prevents redundant code.
Our Approach at Envitia
As one of those agile software companies at the end of a supply chain, we risked not understanding the user story with clear business-driven case studies that drove the business case for project approval in the first place. A prime contractor may not have sufficient domain expertise to assist (one of the reasons why we might be on their team to begin with). The BDD approach allows us to really understand our end-customers and ensure that we meet their needs and not just their technical requirements.
Written by Simon, Integration & Test Engineer
