The Right Way to Shift Left? Start with Requirements Gathering
We all know that the earlier a defect is found, the more time and money is saved. A wide range of innovations in processes and tools have been adopted, including test automation and automated deployment suites. But we can and should do more.
The data behind the Shift Left quality movement is, at this point, well accepted. We all know that the earlier a defect is found, the more time and money is saved. A wide range of innovations in processes and tools have been adopted, including test automation and automated deployment suites. These are positive developments that are certainly contributing to better software. But we can do more.
The earlier a defect is caught, the more time and money is saved. The software development lifecycle begins with requirements gathering. It follows, then, that the greatest impact a software development team can make is in finding defects during the requirements gathering stage. In fact, if a defect is NOT caught at this stage, and automation is applied at a later stage, the affect is that the defect gets to production faster, and ultimately cost the team more. Like a Trojan horse, it moves undetected through the SDLC because it wasn’t identified at the first stage. To quote Bill Gates: “automation applied to an efficient operation will magnify the efficiency….automation applied to an inefficient operation will magnify the inefficiency.”
In my work with software teams in the education sector, I often find that shift left initiatives are initiated by engineering and QA managers and only go as left as the development stage. This makes sense – organizationally, the people who are responsible for requirements gathering – product managers – typically report to a different department. Getting involved with requirements gathering can be perceived as overreaching or stepping on toes. But as I’ll explain, this type of cross-department collaboration is exactly what’s required.
Finding defects in requirements requires cultural change
Creating solid requirements requires many perspectives. End users provide a view of the current workflow and where there are pain points. Sales people provide insight on the strongest reaction (good or bad) from buyers. Developers provide perspective on how various technical solutions could be applied to the solution. Quality assurance engineers bring the perspective of what types of solutions have generated defects in the past or what test cases have been most effective. Customer service folks can identify current problems that are related to the problem being solved or similar solutions that have failed when brought to market.
The product manager is often expected to solicit of these perspectives and synthesize them into a succinct, elegant set of user stories. However, this rarely happens and, when it does, there isn’t always sufficient time for the product manager to gather all of the necessary feedback. There is a simpler way.
Collaboration in requirements gathering has a multiplier effect
In the last fifteen years, I’ve worked with multiple products and teams to build a culture of collaboration around what I believe is the most important aspect of software development – requirements gathering. The way to achieve this is both simple and complex. Complex because it requires managers to overcome stereotypes about how “engineers think”. It requires departments who don’t normally collaborate to do so. It requires all teams to take ownership of the requirements. Simple because, when it happens, teams typically embrace the concept.
When the entire team – product management, sales, engineering, QA, and customer service – collaborate on and take ownership of requirements, the result is better software. Not just less defects. But software that solves customer problems in fundamentally better ways.
8 Steps to build collaboration in requirements gathering
- The first step in accomplishing “extreme shift left” is making the case. As I mentioned earlier in this article, it’s not hard to find data proving that finding a defect earlier will save time and money. If you’re looking for this research, here’s a few examples:
- Qualitest Enables a Seamless Digital Transformation for a World-Leading Weather App
- Qualitest Enables World-Leading News Agency to Shift Left and Offer Top-Notch UX
- Qualitest Helps Global Market-Leading Retailer Engineer Massive Automation Transformation
- Testing Automation Accelerates Global Reward Brand’s Time to Market
If you need more ammunition, look for defects from your application that have been found in production due to poor requirements – most products have these. With this data in hand, suggest a proof-of-concept. Most POCs are hard to object to if they are small in scope and backed by research. To measure the success of your POC, it should:
- Result in more thorough requirements
- Take the same or less time for the team to develop the requirements
- Better prepare dev and QA to write test cases and code the requirements
- Result in less defects than similar-sized projects
- Cause the team to feel more engaged in the development of the software
- Find a good feature to prove the concept. It should be relatively meaty and nuanced in nature.
- Explain to the team that, for this POC, writing requirements is everybody’s responsibility. Each member must contribute and bring their unique perspectives.
- Using Google Docs, Confluence or similar collaborative documentation tool, the product manager should briefly describe the problem and proposed solution. The product manager then shares the document with a sales representative, developers, QA engineers, and customer service representative with instructions to make suggestions and ask questions within the doc. The more the better. By a deadline. No exceptions. The product manager should follow up with team members who have not contributed as the deadline gets closer.
- The product manager then incorporates suggestions, facilitates getting answers to questions and if necessary, calls meetings to discuss further. This continues until the entire team fully understands the problem and believes the solution is solid.
- The product manager then creates brief user stories in your project tracking tool and simply links the requirements document to the stories for context. There is no need to document further as every member of the team is deeply familiar with the context at the point.
- For each user story, the QA team writes test plans. If your team is using behavior-driven tools like Cucumber, Zephyr and others, great. If not – excel works fine. These test cases are shared with the product manager and developers for feedback. Is anything missing? Is anything redundant? Will this impact other aspects of the app that we’re not considering? This iterates until all agree that the test plans are solid.
- At this point, development can begin. Developers write their code and unit tests exactly to the test plans. Components are not turned over to QA unless unit tests have passed.
I often compare shifting left to scraping and sanding a house before painting. While it seems arduous, if you take the time up-front, you actually save time and money while creating a better product. Shifting left in requirements gathering is no different. If you can build this process into your culture, it can result in a more engaged, collaborative team and fundamentally better product.