This category is human-system related, a category which we can roughly define as us not understanding the problem and includes:
- Miscommunication and mis-understanding
- Lack of knowledge
- Making assumptions without validating them
- Not knowing what we want until we see it
One mindset shift that might help with this is to consider everything we do to the point where we deliver our software as design; this includes writing the code. This thinking will help us understand that in each step toward delivery we should be asking "Are we building the right thing?"
As we discussed back in Chapter 1, The Software Industry and the Agile Manifesto complex problems tend to hide details that we don't uncover until we start building, delivering, and using our software. These details often don't make themselves visible until we start to tease them out and are what NASA referred to as unknown unknowns.
We can fix these by paying attention to the human aspects of software delivery, for example, having our Product Owner co-located with us will significantly improve our feedback loops and decision-making process.
Here are some other techniques we can use to get a better understanding of what our customer needs:
- User Experience: Techniques that help us uncover what our user wants or needs include user story mapping and impact mapping (both discussed in Chapter 10, Using Product Roadmaps to Guide Software Delivery). Both of these techniques are designed to form high-level objectives plus an initial breakdown of features. From there, our user experience specialists can help tease out further details by creating various forms of prototypes, from paper-based mockups through to actual screens that have limited, but real-life interaction capabilities.
- Behavior-Driven Development (BDD): The great thing about BDD is the way that it encourages us to work collaboratively with our customer to determine the requirements for our software. We use scenarios as a way to tease out acceptance criteria for User Stories.
The following is an example of a simple autoplay feature on a video player, which automatically plays a video unless our user is on a touch device:
The scenarios are written in familiar language as we need to formulate scenarios in a way that everyone on our team can understand them; non-technical people shouldn't be an afterthought, they should be the main focus.
We then take these scenarios and automate tests around them, and because these scenarios represent our acceptance criteria, this means the tests we build represent our acceptance tests.
This automation represents a significant step in shifting left (that phrase again, which means doing it early and often in the life cycle) because user acceptance testing (UAT) is usually left until the end of the process. Writing acceptance tests with our Product Owner before we implement the code to fulfill them means that we are much more likely to build the right thing without over-elaborating. Hopefully, this helps us adhere to the Agile principle—Simplicity- the art of maximizing the amount of work not done - is essential.
Of course, sometimes people just don't know what they want until they see it or use it. While all of the preceding techniques mitigate this happening, we should still expect a degree of rework after our customer finally gets to use our software. This is why incremental delivery of working software is key to ironing out bugs.
Each of the preceding suggestions is a way for us to take our understanding one step closer to the real thing. It's important that just like our software we incorporate these techniques into our incremental delivery adopting the Goldilocks approach of not too much, not too little, but just the right amount of work to take us forward.