One of the easiest ways to make a software project fail is to simply build the wrong thing. Every time there is a hand-off of requirements, there is the risk that they are changed in translation. It’s not always easy to work out what customers actually want, and they might not even know if you ask them. Business analysis strives to bridge that gap, extracting and validating requirements, and clarifying them as much as possible. If product owners or business analysts work in isolation from delivery teams, it adds extra hand-offs, which can be reduced by adopting what Gojko Adzic introduced in his excellent book Specification By Example as “Three Amigos” requirements analysis.
In a cross-functional software team, every member brings a different combination of strengths and skills to the table. The “Three Amigos” style of requirements analysis aims to harness 3 specific skill sets:
- The business analyst or product owner brings knowledge of the problem space, acting as a proxy for the customer’s requirements; he understands what problem the customer is trying to solve
- The developer brings knowledge of the solution space, acting as a technical specialist; she understands how to build a solution for this problem
- The quality analyst brings knowledge of how to find gaps or problems in a solution; he understands how to prove that the solution fully addresses the problem
In a traditional waterfall approach to building software, deciding what to build/building it/testing it are divided quite firmly into different phases. The big risk in this approach is that feedback is delayed. Agile methodologies encourage working in cycles, incrementally adding value. The first cycles for a story don’t have to result in built software, in fact it is normally better to target the quickest deliverable thing that can prove whether the story is on the right track. This can be as simple as a sketch, or a description of how something will work. This deliverable can then be taken back to customers, or to someone who acts as a proxy, who can validate this deliverable, and refine it. The cheaper the deliverable is to produce, the more refinement cycles it can go through; eventually the deliverable will be “good enough”, and the team can move on to the next thing. The challenge for the team is not in trying to leap from nothing to “good enough” in a single step – this is possible but highly unlikely – but in trying to iterate as quickly as possible towards “good enough” at the lowest overall cost.
In Specification By Example, Adzic advocates the use of Behavior Driven Design (BDD) as a low-level deliverable that defines the desired behavior of a feature in a format that can be executed to verify that behavior. This is often done by using a semi-formal natural language tool, like Gherkin, where a light framework of keywords is applied to describe examples of how the system will respond to a certain set of parameters. It is very powerful to involve the “Three Amigos” – BA, dev, QA – in the writing of these specifications, as each will have their own perspective, and by working together the chance of misunderstandings growing is minimized. Many teams try to apply BDD, but have specifications written in isolation by a single team member; this is a big lost opportunity.
It can be quite time-intensive (and a little tedious) to actually flesh out a full BDD specification, so my preferred way of working is not to actually do all of that as a group of three. What I tend to prefer to do is to capture scenario titles as a group, and then to go away and write a first pass of steps for these scenarios, before joining up again to verify and refine the result. All of this is without ever writing a line of code, because the cost of writing software is enormous compared with the cost of writing a block of text. The scenarios at this stage are much more malleable and can be cheaply and quickly refined with minimal waste.
By involving multiple disciplines in enriching the definition of features, more time is spent in these early cycles, but when it comes to implementation and delivery things tend to go much smoother. Misunderstanding of requirements is much less common, and the communication channel is already open when there is something to come back to. Leveraging the different mindsets can capture scenarios that would have otherwise been undefined, and can iron out conflicts or gaps in requirements.