Chapter 10. Specify Collaboratively
Traditional software specifications come with one problem: They need special care to do them well. Once you have nailed them down, though, they quickly become obsolete for different reasons that you may be able to influence or not. For example, if a competitor releases a new feature in its software, your requirements may change in an instant in order to keep your market share. Since this is clearly a nontechnical decision, someone with a business background has to at least participate in that decision.
The more diverse opinions you can get in your requirements process, the clearer the picture of the application gets. In general, there are at least three different perspectives that you should include. On the one hand, there is the business perspective. On agile teams, this perspective is usually represented by a customer representative, a customer proxy, or in Scrum it’s the ProductOwner.
On the other hand, there is the technical perspective. On more traditional teams, a lead programmer or technical leader might represent this viewpoint. On agile teams you may want to include at least one team member who knows the code base from working with the source code.
Finally, you need someone to mediate between the two perspectives. In traditional projects you will find business analysts bringing in this viewpoint. An experienced software tester can bring the same value as well.
Meet the Power of Three
But why do these three different perspectives help in specifying the application? Designing a software system comes with many decisions between two aspects: the business functions and the technical constraints. Our software code bases are full of trade-off decisions between these functions and constraints. Our bug databases, on the other hand, are full of reports where the decisions were plain wrong.
Some of these decisions are hard to change during the software development process, and some of them are easy to fix. By getting the two different viewpoints of business functions and technical constraints together early, we help to find the right trade-off decisions early so that as few as possible of the always hard-to-fix bugs as well as the always easy-to-fix bugs are introduced. Incidentally, we can also avoid all the bugs in between these two extremes.
The functions for a software system span a solution space [GW89]. In this solution space there are many possible designs that fulfill the required functions. They also explain how you can explore the solution space with different attributes for the functions like performance or load behavior. These attributes constrain the amount of possible solutions to the space of solutions that is desired by the customer.
On the other hand, there are constraints to the technology that is used to realize the software. These constraints restrict the amount of possible designs that fulfill the functions and attributes.
Bringing the business functions and attributes together with the technical constraints early helps the participants with exploring the space for possible designs. This is one of the key ingredients for the approach of acceptance test-driven development that make it work. And it turns out that testers can facilitate this exploration process with their ability to question and challenge functions, attributes, and constraints of the software.
But what about the independent viewpoint that a separate test team can bring to the table? Through decades of testing training we have learned and taught that programmers and testers should work completely independently from the same basis, the requirements document. This avoids the phenomenon that modern psychology coined confirmation bias. A tester should be unbiased by the viewpoints of the programmer and critique the product when appropriate. Some teams interpret this rule to the degree that programmers and testers are not allowed to talk to each other at all.
Specifying the software together with a programmer does not make the tester preoccupied. Instead programmers and testers work together with the business experts to trawl the requirements for the software. If you think this biases the opinion of a tester, then you should start to wonder whether reading the same requirements document biases your testers as well. Specifying examples together with programmers and business experts is the same as attending a requirements workshop—something that most testers dream of for all their professional career.
In fact, the teams that Gojko Adzic interviewed for his book Specification by Example [Adz11] reported that the added viewpoints of at least one programmer and one tester lead to a better understanding of the requirements right from the start. As we saw in the airport example, the conversation led to situations in which the programmers contributed through technical questions of the business process, and also questions from the tester supported the understandability and visualization of the requirements with the table structure.
During the iterations both programmers and testers work from the same basic understanding of the feature. The examples identified as acceptance tests serve the team as verification of their progress.
For the best results these three different roles should be included: a business expert like the ProductOwner or an on-site customer, a programmer, and a tester. Based on the number of roles involved, Janet Gregory and Lisa Crispin call this the Power of Three.
The Rule of Three Interpretations [Wei93, page 90] reminds us to think of at least three different possibilities before concluding upon something that we received.
If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.
The Power of Three helps in overcoming this shortcoming of imagination. By bringing three different perspectives to the table, your potential to have thought enough about the requirements of the feature or story rises dramatically. That’s what makes the Power of Three so powerful.
The Power of Three goes beyond functional requirements as well. The programmer knows the performance liabilities of the code base and might ask for clarification on this. The testers are usually aware of usability shortcomings. Programmer, tester, and business representative can get clarification on the quality attributes of the upcoming features—these are sometimes referred to as the nonfunctional requirements. Remember to consider the gaps you leave with your automated tests and build a complete testing orchestra (see Chapter 9, “Build Your Testing Orchestra”) using the testing quadrants (see Figure 9.2). Most of the performance, load, and stability requirements can be checked using test automation as well.
Hold Workshops
As we saw in Part I, a workshop can help the whole team to reach a shared understanding of the functionality that it is going to implement. There are some things you will have to keep in mind in order to make these workshops a success for everyone, regardless of whether they are participating.
Participants
First of all, you should make sure that you pick the right participants. For some teams this may mean involving the whole development team as well as customers from different companies. These teams usually have a larger meeting, but will meet for a workshop every other iteration.
On the other hand, there are teams that just include three roles in the workshop, leading to a small meeting of three persons. In any case, you should include diverse viewpoints. Usually this means including someone who is familiar with the business side of the product. You also want to have easy access to an expert user [Coc06].
As I showed in “Meet the Power of Three,” you should include at least one programmer and one tester as well. A programmer knows the code base. Based on the discussion that arises at a specification workshop, the programmer will ask questions regarding the technical implementation of the functionality at hand. By their very nature, programmers will be concerned about how the function can be implemented and have the domain model already in place in their head. The workshop brings them the benefit of reaching a common understanding of the business domain for the new functionality.
Testers with their critical mindset can find gaps in the business rules quickly. Another unique ability testers put into a specification workshop is their ability to make business rules transparent through tables. Whether they have been using a so-called Agile-friendly automation framework before, an experienced tester knows about decision tables and how to describe complex business rules using a tabular representation. If you develop such a representation in the specification workshop together, programmers, testers, and business experts reach agreement on the discussed functionality even before any source code is touched.
Goal of the Workshop
For specification workshops to become a success, it’s relevant to know your primary audience. The development team—that is, programmers and testers—are the primary audience, while the domain expert brings in the necessary knowledge about the upcoming features. It’s essential to keep in mind that customers and external business experts are probably short on time [Adz09]. If you invite them to a meeting where your programmers fight for whether to use the latest web server technology, and which one that should be, you are probably not going to get their participation for the next workshop.
Rather than discuss technical issues in your implementation, you will need an experienced facilitator who focuses the attention on the features. The goal of the workshop is to reach a common understanding of the business rules. You can still discuss all the technical issues later when the business representatives are not attending. The time spent in the specification workshop should be used to reach a common picture.
Frequency and Duration
This leads to the question of how often you should conduct such a workshop. Of course, this depends heavily on the availability of your domain experts. If you need access to some business representatives, you may find out that these are rather busy. On the other hand, you may have an onsite customer whom you can ask additional questions on a daily basis.
Depending on your particular context, you can set aside time for a specification workshop once in a month, or once shortly before the next iteration starts.
Based on how frequently you run specification workshops with your domain expert, you will set aside different time frames. If you run your specification workshop less frequently, you may either want to discuss more features, and therefore set aside more time for the discussion. On the other hand, if you want to leave the meetings short and still meet less frequently, you may either choose to discuss fewer features, or to do some up-front preparation.
In case you want to discuss fewer features, you should work through your backlog of planned features according to the most current priorization. The features that you will most likely include in the next iteration should be discussed first. You may also want to leave out features that are clear for the team, such as a login function or a comment text field for a web page. This leaves you more time to discuss challenging business rules in more complex features.
In case you want to do some up-front preparation, you can work through your backlog of ideas before the workshop and come up with questions for the business expert to answer. You can create a list of open questions during a backlog grooming meeting, which most Scrum teams hold. You may also set aside a separate meeting to discuss upcoming features in brevity a few days before the workshop. Another way to generate some ideas and open questions for the business rules are meetings that create a visualization from the understanding up front, and collect open questions in a mindmap. Although you should keep in mind that once you turn on the video projector in the specification workshop and start to collect the answers in the mindmap as well, your meeting will suffer dramatically while you force everyone to sit silently watching at all of your typos on the video projection. Usually, technology on a lower level, such as index cards, whiteboard, or flipcharts, prevent you from such inefficient meetings if you pick one facilitator to record the answers for you.
Trawl Requirements
Requirements are usually not gathered [Coh04]. Customers and business experts think they know precisely what they want. But when they see the end results, your team finds out that they wanted something completely different.
This is where the metaphor of gathering requirements does not hold. You could gather requirements if they would be lying obviously for everyone to pick and take away in order to produce the desired piece of software. Unfortunately, requirements do not lie around waiting to be picked up. Most teams have to learn this the hard way.
Mike Cohn suggests to use a different metaphor instead. Since requirements are not lying around waiting to be gathered together, we need to do something to get a hold of them. There are techniques that help you do that on different levels, just like a fishnet can have different netting sizes in order to catch different sorts of fish while letting others swim through. This analogy holds wonderfully for the different techniques of specification by example.
In the examples earlier we saw two widespread ways for working with specification by example. The first was to have a separate testing group that can work in parallel with the programmers on a given feature for the software. In this scenario our fishnet consists of reaching a common understanding on the features before starting any work to incorporate these features into the existing product.
The team got together and trawled for the requirements of the parking lot. Since everyone had a basic understanding of parking a car, team members could reach a common understanding for parking costs at the airport by asking questions. These questions served to fish for examples. Tony, the tester, quickly found out that he can illustrate the understanding of the business rules with written examples. While writing them down, Phyllis and Bill could see, in terms of their discussion, what their fishnet was still missing.
Later the team reduced the examples to a minimum. During this discussion those examples helped everyone to understand what really is necessary. The reduction of the examples helped those to make the size of the fishnet more coarse and let more fish pass through.
The result is a fishnet for requirements that lets some uninteresting requirements through, like mackerel fish while catching all the barracuda. On the other hand, the net makes sure to catch the carps and pickerels if you are more interested in these.
In the second example we saw that collaborative settings are not the only opportunity to trawl for requirements. In the traffic light example we dug for additional information on the business domain before starting to implement anything. Since we were the only ones working on the codebase, we could apply a different way to trawl for requirements. We used a method I deliberately call just-in-time requirements trawling. While the code base grew and grew more, we could think the requirements through once we ran out of examples.
This is a pattern that not only works when you develop code on a two-person team, but also on multi-person teams. While you may have an initial understanding of the domain, I found thinking through concrete examples to express my understanding a big help in digging deeper. More than that, the thinking process helps you see different implementations and design solutions for the domain model in the code.
As the code base grows, my understanding of the problem domain evolves as well. I learn about the application and its intended use. Indeed, we procrastinated on designing the domain model in our code in order to make a more informed decision about the domain model.
One could argue that we could have seen that design right from the start of the discussion. A well-experienced designer could have foreseen where the code base would be going. This is true to a certain degree. At the point where I had the impression that we were up to something, we stopped in order to reflect on the current code base. This reflection helped us pick the right net for the trawl of requirements. As the design for the crossing controller later showed, we also may find that we caught all the jelly fish instead of the carps. Taking a step back from this experience, and learning from it, is a sure way to let experience teach you anything at all.
Reflection also helps you to pick the right netting for your nets when trawling for requirements. Most successful teams started with a basic simple approach [Adz11]. During the first few months of implementing the first approach, the teams noticed a shortcoming in the process. They reflected on it and adapted it to match their particular situation.
In order to find the right granularity for creating your requirements trawling nets, you will have to start with an approach, gather experience while applying it, and reflect on the experiences you had in order to learn and adapt from it. If your team does retrospectives regularly, then you might have experienced the learning and adaptation process.
Summary
Three different perspectives on the requirements will help you to find the right ones. Customers, programmers, and testers can come up with great decisions for this. If you organize your requirements trawling in workshops, you will gain the viewpoints from all the different roles in your team. Also, make sure to try out your current net and learn from the experience that you will get.