Among software services and solutions providers, “industry-leading” speed-to-market is a commonly parroted value proposition. The underlying promise of speed is to offer business value, sooner. But as we’ve discussed in past articles on agile methodology and accelerated software delivery, if you’re not building something that produces value, how fast you’re building it is irrelevant.
To illustrate this point, we need to look no further than to an industry that knows a lot about speed: automobile manufacturing.
By the late 1970s, the once-mighty U.S. auto industry was faced with a choice: evolve or die. The ideas of famed management consultant W. Edwards Deming had helped elevate a once-inferior Japanese auto industry — in particular, the Toyota Motor Corporation — into an industry disruptor.
Deming’s philosophy was simple: Continuous, incremental improvements result in a quality product. By incorporating quality control principles throughout the production process, companies could produce the highest quality at the lowest overall cost over time. At the beginning of the post-WWII packaged goods era where the focus shifted to quantity over quality, U.S. business leaders initially rejected this idea. Rigorous quality control was viewed as overkill that slowed production time.
Deming’s focus on quality offers many insights on how we can build better software products that provide value, faster. Revisiting these ideas from the software development point of view offers great insight into how companies can improve their software delivery strategy. Deming’s work helped pioneer lean manufacturing and transform the auto industry. The same principles guided the beginnings of agile software methodology and, specifically, quality control in the software delivery cycle.
Before diving into Deming’s theories, it’s important to discuss why having a quality product is important in the first place. We live in a time of rising customer expectations and declining brand loyalty. If a product doesn’t meet a customer’s quality standards, people move on to one that does. Even if the customer sticks around, low-quality products are burdened with an increased cost to fix and maintain.
High-quality products don’t just happen magically. They are the result of rigorous testing, feedback, and corresponding adjustments throughout the product life-cycle.
Quality comes not from inspection, but from the improvement of the production process.
Dr. William Edwards Deming, an American engineer and author
Since we’re throwing around several buzz-wordy terms, let’s briefly define what each of them means and where each fits within the larger picture.
Value-driven development is the vision that should guide what teams build next. Agile methodology empowers software delivery teams to smoothly execute their day-to-day activities with a clear goal (measurable value) in sight. DevOps is the culture and organizational structure that creates the optimal team to deliver on that defined value.
With each of the above practices in place, the next goal should be the creation of a “continuous” pipeline:
Take a deeper dive: Video: Continuous Performance Testing in DevOps
Building a quality product, no matter the industry, is the key to both long-term growth and increased productivity. What elevated Japanese auto manufacturers from being synonymous with poor-quality Datsuns (see the 25-horsepower Datsun 113 below) to gold-safety-standard Toyota Camrys was continuous improvement — small, incremental changes to design and process over time.
Here are a few steps to implementing continuous software quality assurance for better processes, explained:
In software, quality control practices occur through quality assurance (QA) and testing. Until fairly recently, the dominant software development model was the waterfall workflow, wherein development follows a linear path: design, code, test. In the waterfall process, each phase in the path can take months, creating an enormous gap between building and testing.
The waterfall approach is similar to those adopted by major American automakers — the one that Deming criticized: testing occurs after the product is built, meaning that any bugs or incorrect assumptions aren’t discovered until the final stages of production. This makes problems more difficult to detect and fix and can severely slow (or even halt) production.
Agile methodologies tighten design-code-test development cycles, usually into two-week sprints. This narrows the testing gap, but a gap of two weeks between building and testing is still too long. To fully incorporate quality control into the development process, testing and QA must occur at each stage.
Read also: Metrics that Matter: How you should be measuring agile
This is best achieved by breaking down walls between departments and creating an environment where testing and coding information is freely shared throughout the team. In software delivery, it’s a feedback loop referred to as DevOps, the fusing of development and operations.
DevOps and agile are not competing ideas, but rather complementary ones. The agile manifesto lays out practices that enable cross-functional teams to iteratively deliver working software to users. All assumptions are validated by user testing in an environment that embraces flexibility rather than a predetermined roadmap.
DevOps methodology takes this approach one step further, creating a team structure that eliminates barriers between departments. In DevOps organizations, teams operate as a cohesive unit rather than disparate silos. Developers, testers, administrators, and even users work as a unified team that shares responsibility for building, testing, and deploying products.
Read also: How to pair your DevOps and continuous performance testing strategies
Namely, at Toyota, each member of the team was responsible for the quality and outcome of the final product. This created a sense of ownership and pride in the car that rolled off the assembly line.
As we’ve established, when testing occurs at the final stage of a production cycle, testing becomes a bottleneck that results in lower quality and longer production times.
That’s where test automation and continuous testing comes in. Building an automated testing platform requires an up-front cost that many organizations balk at. However, consider a construction analogy: If the product you’re building is a skyscraper, an automated testing platform is the scaffolding that must be built before a single brick is laid.
With that “scaffolding” in place, organizations can deploy code every 10 minutes rather than every two hours or two months. This produces feedback and results faster, making it easier to identify mistakes. Since testing can occur in real time, it allows the DevOps team to focus on developing new features and lower the cost of testing in the long run. Over time, the process streamlines, resulting in continuous, incremental improvements that create quality and efficiency — ultimately, a better product.
But to view automated testing as merely an efficiency and speed play misses the point. When mundane tasks like testing checklists are automated, the team is freed up to focus on a higher level of quality in development and customized manual tests. The results of optimized, automated QA and testing influence how the development team writes new clean code that can easily fit into the testing structure.
Many organizations have adopted DevOps and a CI/CD pipeline but have yet to realize any benefits of quality assurance or valuable outcomes. Consider these questions when evaluating why a CI/CD pipeline isn’t producing results:
A CI/CD pipeline produces feedback almost instantly, which offers tremendous potential in accelerating development. However, the success of the system is dependent upon leaders that champion a culture that embraces the free flow of information, tolerance of failure, and a focus on value.
Deming’s work in optimizing auto manufacturing gives us a historical context on how to build quality software products or services. Even 70 years later, his ideas are as relevant as ever. Still, software services and solutions providers, as well as IT enterprises, have been slow to adopt this second wave of Deming-inspired philosophy.
If speed-to-market is your only goal, it’s easy to slip into the quantity mindset that caused U.S. auto manufacturers to fall behind. A better approach is to create improved systems of quality — a well-oiled continuous delivery pipeline. Build it right. Speed will follow
Editor’s note: The article was first published on February 7, 2019, and was updated for relevancy and accuracy on April 21, 2021.