As a business analyst on a software-development team I consider my responsibility that the software we deliver brings value by doing the right thing.
Even if your agile team delivers in small chunks, you better want to be sure the new increments do what you want them to do. Succeeding in hitting a moving target is more likely if everyone knows what the target is. Agile or not, most adjustments which result from misunderstandings turn out to be more expensive than expected.
Projects fail not because teams cannot product code — they fail because the code does not bring value. “The technical part of building software is no longer a problem.” stands in the opening chapter of Bridging the Communication Gap. “The hardest part of building a software system is deciding precisely what to build.”
This sounds a lot easier than done — this is why the book written by Gojko Adzic in 2009 is still relevant in 2020. After reading the book one should not only realize that building shared understanding among people involved in software delivery is the key to success, one should also be equipped with know-how to create such understanding.
If you have heard about Behaviour-Driven Development (BDD, Dan North) and this sounds familiar, you are right. Agile acceptance testing as a way to work better as a team, is a synonym. Like BDD, agile acceptance testing is not a programming technique — it is a communication technique that brings people involved in a software project together.
Agile acceptance testing has nothing to do with testing that traditionally comes only once the code has been written. On the opposite, agile acceptance testing means making quality control an inherent part of the development — making sure we first of all prevent issues from happening rather than allowing them to happen and fixing them afterwards.
Agile acceptance testing (like BDD) brings people together, makes them discuss requirements and come up with realistic examples to test the requirements. As an outcome team members get a better, refined set of requirements (expressed as examples) and the team members build shared understanding of the domain. This means all team roles can contribute even better during the next discussion because they understand what the topic (domain) is about. This is a major paradigm-change compared to ways of working based on handovers and specification sign-offs where developers just get instructions what to code and testers just get tasked to test test the system once development is done.
Agile acceptance testing consists of the following five principles:
- User real-world examples to build a shared understanding of the domain.
- Select a set of these examples to be a specification and an acceptance test suite.
- Automate verification of the acceptance tests.
- Focus the software development effort on the acceptance tests.
- Use the set of acceptance tests to facilitate discussion about future change requests, effectively going back to step 1 for a new cycle of development.
How agile acceptance testing (like BDD) shifts the role of development team members:
Business analysts — They are expected to be the drivers and facilitators of the change. Analysts should no longer be interpreters between business and developers — two parties historically viewed as incapable of understanding each other. The opportunity and challenge for analysts is to bring people together, promote discussions, and build shared domain understanding. Analysts should view themselves as bridge builders, not ferry operators.
Testers — With agile acceptance testing testers stand in a completely different light. Their primary role should be to help the team prevent problems, rather than just find them at the end. Testers with their mindsets are expected to excel at pointing out to edge cases and pitfalls already during the specification workshops. They help to make the quality control a part of development — bugs should be prevented, not found.
Developers — They are expected to participate in the specification workshops to learn about the domain and provide indispensable technical expertise. These two things go hand in hand — the more a developer understands the business domain, the better feedback s/he can give. Understanding of the domain should also be mirrored on the code level by using for variables, functions, etc. the same names which are used all across the team — a ubiquitous (shared, common) language. Developers are expected to support the team by writing (in cooperation with other) the acceptance tests. Having acceptance tests in addition to unit tests brings confidence the code works not only as individual units but also that it fulfills the expected behavior — brings value.
Bridging the Communication Gap is a valuable read for anyone involved in software development. Even though some chapters are already outdated (Tools of Today, Tools of Tomorrow), the core message of the book is timeless. If you consider yourself experienced in agile and software delivery, or you are just completely new to the field, the books offer a lot to learn or at least to remind yourself of. Definitely worth reading in 2010, 2020 and most likely in still 2030 as well.