In past articles, we talked about the importance of shifting left to uncover defects early in the software development process. We also talked about the three main impacts to achieving high velocity. Now, let’s discuss how shift left improves velocity.
High velocity is generally accepted to refer to the ability for a development team to concentrate on cranking out new features without being in constant break-fix mode. The more time the development team spends on fixing current and prior sprint defects, the less time they have to develop new features. Let's face it, the name of the game in this day and age is for new features to be delivered fast.
If the core concept of high velocity is to keep the team focused on developing new features, any time spent fixing defects— even those related to the current feature— slows down velocity. The first, and main, objective is to prevent defects in the first place. If defects are present, the next objective is to fix defects as early in the development process as possible.
Testing the Requirements
Our first shift left begins with the requirements. Users and product owners are notorious for giving incomplete specifications. Whether you have traditional requirements, user stories, or use cases, they are almost always incomplete. Users and product owners are great at defining the main business transactions. However, they tend to not think in terms of alternate paths and error conditions.
Developers are better at thinking through alternate paths and error conditions, but they are trained to “converge” on a solution and get the feature written. It makes much more sense to let your trained “code breakers” review the requirements. They are trained to be “divergent” thinkers. They see a requirement and immediately start thinking of alternative paths and potential errors. With that said, your first shift left is to let your QA team review the requirements before they are sent to the developers. This is commonly known as “testing the requirements”. Try it and you will uncover vague requirements that could lead to potential defects later.
Regression Testing
Our second shift left is a daily regression test. Most high velocity teams have daily code check-ins and daily builds. This is a great time to run a regression test to find any unanticipated defects in “unchanged code”. Most teams run the build at the end of the day. You can use your CI/CD tool (e.g., Jenkins, Azure Dev Ops, etc) to run an automated regression test after the build. When you come in the next day, the regression test results are in your test management system showing either that all tests ran successfully or some new code caused a regression test defect that needs to be corrected. The offending code can then be reviewed and corrected that day to keep the defects down and the feature count up.
Frequent & Timely Load Testing
Our third shift left is frequent and timely load testing. Today’s apps are moving to the cloud and interacting with other cloud-based apps. This means multiple infrastructures with multiple choke points. We encourage our clients to run load tests at strategic times to uncover any potential load issues before features get released. We recommend running load tests when any of the following occur:
There is a change in the underlying infrastructure – server configuration change, operating system upgrade, a system upgrade in an inter-related system, or a system architecture change.
There is a change in the data base layer, or the database management system.
There is a change in an SQL statement within the code.
There is a new hosting vendor introduced into the technical stack, or the entire stack is re-hosted to another environment.
Any of these changes could have a severe negative impact on system performance. We recommend clients run load tests as part of their pre-release testing to prevent performance errors showing up in production. At that point, there is little time to fix the errors and requires help and oversight from upper-level management.
Each of these alone can reduce defects and improve velocity, but when implemented together, they can move your team towards achieving high velocity.
For more information on how you can eliminate velocity drag and consistently achieve high velocity, contact an expert at Stonemill Consulting today.
