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.
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.
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.
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:
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.
