Optimize Your Agile Life-cycle With Powerful Defect Prevention Techniques

The level of planned defect prevention activities across the software development industry today is still relatively low. Contrast that with the level of software testing that happens on most projects, which is reaching all-time highs with the growing adoption of agile and the blurring of testing responsibilities across teams.

We have come a long way advocating for appropriate testing coverage on software projects; this has been particularly helpful to those of us who have dedicated our careers as QA practitioners. But, for those that have recognized that most defects are preventable, no matter how complex the project, there is a high degree of frustration. That frustration is around the many wasted man hours of effort on our projects hidden under the guise of a lengthy find-fix-retest lifecycle that has become completely normal and acceptable, even expected. If time, money, and quality were limitless, this would be moot. But, in the real world, this wasteful rework is keeping armies of testing teams employed.

The reality of all this for many projects is a defect repository that numbers in the thousands. Tens of thousands for many major enterprise transformations. Typically these numbers are built up after a year or two of releases. Unfortunately, very few people pay attention to the treasure trove of information that exists in those repositories. That data set is ripe for intelligent analytical scrubbing that can reveal hidden gems about how to get to market faster, with higher quality, and at much lower cost. When was the last time you observed an organization apply analytical analysis to their defect repository, if ever? I have seen it happen twice in the 25 years I have been in the industry. Neither effort brought about changes to the behavior of the development process relative to defect prevention.

I don’t have to explain the many benefits of preventing defects from occurring in the first place. The huge cost savings alone should be enough to convince senior leaders to examine why so few prevention activities are taking place across their projects.

This is not an impossible wall to breach; we just have to start slowly and demonstrate the value each step of the way until prevention activities become second nature for our project teams. Within the Agile Life-cycle, there are many opportunities to practice defect prevention. Focusing on developing user stories that unambiguously satisfy business requirements is an excellent place to start.

It doesn’t take that much work to formalize the development of high quality user stories. So, how exactly do we define high quality in a user story? Simple. If two different developers can interpret the needed business functionality of a story exactly the same way, it is high quality. One of the biggest culprits of a low-quality story is ambiguity. Ambiguity in requirements is systemic across the industry; most companies never measure it so they are completely in the dark on how systemic the issue is. It is perhaps the single biggest cause of project failure/delay, cost overruns, and poor quality.

There are many techniques available to help you eradicate ambiguities. It will require an up-front investment of your project time to analyze the quality level of your stories, or better yet, to devise a high quality story development process that prevents them from being introduced in the first place. But, I recommend starting slowly and putting in place a static testing process that will help you identify and remediate them first. You can do this manually, or you can do this with the help of automated tools that are available in the market for this purpose; there are several.

Also, remember that user stories are interactive and incremental in nature. That is the beauty of agile; we do not have to have every requirement in place up-front prior to coding. Because of this, you need to check for high quality as you increment throughout a sprint. Just be sure to apply the same quality tests with the same rigor as the story changes and evolves.

A quick Google search will help you locate some of the automated Natural Language Processing tools specifically developed for ambiguity scanning. Several are open source. Or, you can opt to create your own with an NLP engine and customize the language processing for your specific needs. See the following link for some open source NLP engines: https://opensource.com/business/15/7/five-open-source-nlp-tools.

Another very effective (but more involved) process you can adopt is Behavior Driven Development (BDD). This is a proven way of preventing defects from entering the user story development process. The BDD methodology will require much more planning and subsequent change in your organization than implementing a static ambiguity testing process, but it will help you prevent a broader range of requirements defects than ambiguity testing alone.

BDD will help ensure:

·        What is to be delivered is valuable to the business.

·        What is to be delivered is required.

·        What is to be delivered is within scope.

 Fundamentally, BDD techniques encourage more effective conversation with customers, users, and domain experts. A ubiquitous language was developed as part of BDD to capture behavior consistently across stories. The defect prevention mechanism lies in the development of a consistent vocabulary for analysts, testers, developers, and the business. This helps eliminate some of the ambiguity and miscommunication that occurs when technical people talk to business people.

There are plenty of articles written on BDD, so I won’t get into how to get started with it, but I have experienced its defect prevention power first hand and it is worth some research if you have the time; you may just become inclined to introduce it into your team after learning more.

Preventing defects is not easy. It takes a deliberate effort and investment up front, but the power of preventing defects from entering the lifecycle is far too valuable to ignore. I hope these few suggestions are useful for you. Please let me know if you are already using either one and what your experiences have been; I would love to hear from you.