#67-Shift left - Detecting Defects During Analysis

The final "shift left" I will examine is the detection of defects during the planning process, specifically requirements analysis.  It represents one of the most important and also most difficult challenges that face us when developing products.

Transcript

Shift Left: Detecting Defects During Analysis

The analysis of requirements in the context of a given domain is one of the most difficult things we do when attempting to develop a product. It is the point in time where we discover what it is we are going to build before we attempt to build it, and therefore is one of the most critical aspects of product development. 

Failures in analysis will affect literally every phase that follows.

• Design is based on the understanding of the expectations that requirements represent as understood through the analysis process. 
• The implementation of a design is similarly conducted in that context: how we understand the behaviors that those expectations imply. 
• Integration proceeds from an understanding of the domain itself, and all the internal and external aspects of the business processes we are automating. 
• Testing, in the traditional sense, is based on the scenarios implied by the requirements as we understand them. Poor analysis will miss edge cases and missing requirements, such as performance and maintainability. 
• Deployment may be difficult or impossible if certain key elements were not addressed during the analysis phase, such as regulatory requirements that we must comply with in order to be able to sell our product. Additionally, analysis should include an understanding of the customer landscape that we will be selling and deploying our product into. 
• Finally, failures in analysis can make the product unusable, or significantly reduce its value in use because of missing features, incorrect assumptions in implementation, and overall a mismatch between business processes and product development. 

Analysis must be conducted with many different points of view included. Different individuals with different expertise will supply critical information, understanding, important questions to ask, challenges to overcome, and a myriad of important aspects of the product to come that may not be adequately covered by traditional requirements. 

This wide range of points of view implies that there needs to be a way for people who are technically minded and those who are more focused on business forces to collaborate effectively. 

In my experience, the most common problem that impedes successful product development is the failure of these disparate individuals to communicate with enough depth and clarity to allow for true collaboration. 

There may be other ways to solve this problem, but the most success I have had as a consultant is in training the entire organization on two analysis techniques:

The first is commonality-variability analysis, which is a non-technical technique that anyone can do, but which will also guide the technical aspects of the product. 

The second is teaching everyone how to write acceptance tests collaboratively. Acceptance tests precede development and therefore are an aspect of test-driven development. But they are not done using technical language, like computer code.  They are created using human readable language, including all of the critical domain terms that drive the business. 

The details of these two techniques are beyond the scope of a podcast but if you examine the transcript, I will link in resources that will help you to dig into the specifics of each.

By learning these two techniques, the entire organization can learn to collaborate across the technical divide and drastically improve the success of the products we develop. It is the farthest shift to the left that I know how to accomplish. 

They are also two of the major aspects of the training that I do here at PMI and can do for your organization.

Commonality-Variability Analysis:

https://www.projectmanagement.com/webinars/863805/commonality-variability-analysis

Acceptance Testing in the context of Test-Driven Development:

https://www.projectmanagement.com/webinars/818036/test-driven-development-in-the-larger-context--tdd---atdd

Training at PMI:

https://www.pmi.org/business-solutions/agile-technical-solutions