Software developers are often focused on crafting beautifully-engineered, bug-free code. At XTRF, we turned this on its head. We challenged our developers’ priorities. We asked them to adopt a collaborative, iterative, example-based approach. It wasn’t easy. But, by doing this, we were able to manage expectations, save time and money, and ultimately, provide you with a better service.
Before my team and I adopted this new approach, we were struggling with a number of challenges. Often, the specifications we received from clients or business analysts were vague, and the terms used were ambiguous. Naturally, many of our clients didn’t have a technical background which meant they didn’t understand the implications of what they were asking for. All of this proved fertile ground for miscommunication. Sometimes, it wouldn’t be until a feature was ready for delivery, that we discovered it wasn’t achieving what the client had hoped. In turn, the resulting time pressure meant we were forced to take shortcuts.
For a developer, there’s nothing more frustrating than spending hours perfecting code, getting it all ready to deploy, only to have to go back to the drawing board. From a client’s point of view, it can be incredibly frustrating to invest in the development of a new feature, only to end up with something that doesn’t do what you asked for. We knew we had to make a radical change. Adopt a different way of working.
Agile – not just a buzzword
Agile has become a bit of a cliché these days. It’s often used to market businesses to potential employees or clients and has little to do with the company’s modus operandi. But the actual methodology it refers to holds a lot of merit. So what does agile really mean? It refers to an approach to software development that prioritizes collaboration and cross-functional teams, to ensure all necessary skill sets are represented. It is iterative. This means that requirements and solutions evolve, work in progress is tested regularly, and projects are delivered incrementally rather than all at once.
But if agile software development is so great, you might wonder why everyone isn’t doing it. The truth is that implementing and adhering to agile methodology requires a real commitment. You need to resist the temptation to be swayed from your course. The short-term benefits offered by other approaches don’t outweigh the long-term benefits agile can deliver.
Using acceptance tests to communicate with our clients
Acceptance tests are a useful tool for helping communicate our ideas to clients, ensuring we’re designing the features they want. It involves testing to check whether the product or feature we’ve been working on does what the client wants it to. Traditionally, this might have been a tick box exercise completed internally using abstract statements. With our new approach, we’re applying it to real-life scenarios. Because we want to make sure it satisfies our client’s business requirements.
Testing is not just carried out by our team of developers. We also ask our clients to validate the tests, confirming whether the feature meets the original requirements. This way, we can spot and solve problems early on, and be sure the development is headed in the right direction. This process also involves creating an SSOT (single source of truth) which details the change implemented. This SSOT can then be used by business analysts, UX designers, developers, and QA engineers, avoiding the problem of duplicate and conflicting documentation, and making sure everyone is on the same page.
Testing based on realistic scenarios
An important part of acceptance tests is creating examples that represent real-life scenarios applicable to your business, otherwise known as living specifications. This process is referred to as specification by example (SBE). SBEhelps present specific business requirements in a format that is easy for developers to understand and test.
Essentially SBE involves dividing the software into features and separating these further into scenarios or examples. Each of these is concrete use cases that detail what should happen in given situations.
Different tools can be used to create these specifications, but don’t worry, you won’t have to do this all on your own. It’s best developed collaboratively. And we’re always here to give you a helping hand if you get stuck.
How you benefit from this approach
This new approach has many advantages. Not only is it a more enjoyable way for us, as developers, to work, but you can also reap the rewards. Expectations are better managed on all sides, and the scope for miscommunication is significantly reduced. More detailed and consistent specifications ensure developers understand what is expected of them. Acceptance tests help development stay on track, which saves you time.
We’re also able to estimate the cost of projects more accurately, thanks to the detailed specifications. In fact, before implementing SBE, our accuracy ratio (monthly average of estimated hours versus hours spent) was 30:70. Following implementation, we’ve managed to achieve an outstanding 45:55 – meaning we’re fast approaching the golden perfect ratio of 50:50!
At the end of the day
In the software development world, we like to use the ironic expression: ‘weeks of coding can save hours of planning’. It’s a tongue-in-cheek way of saying that if you take the time to clarify your requirements and specifications, you won’t end up wasting time developing the wrong feature. This sentiment is certainly applicable to our work here at XTRF, and we bear in mind in everything we do.