The technology world is changing fast, faster than ever. A few years ago, we thought that only the Amazons or Facebooks of this world would be able to do continuous delivery. Now, the phenomenon is getting traction, starting to become mainstream and before we know it, it will be commoditized. Everybody will do it.
Why? Because the ability to release often gives organizations a great competitive advantage over their competitors with slower turnaround times. In order to practice continuous delivery, teams have to build quality into everything they do. This means that the actual product not only reaches the customers faster — it’s a better product, too. Learning to build quality in with Kanban helped my development team reduce waste, deliver faster, and communicate better with the organization around us.
Keep reading to learn how my development team changed our infrastructure, development practices, and culture to enable continuous delivery.
How Quality and Continuous Delivery Relate
I’ve had the luck of being part of a team working on improving our organization’s ability to deliver fast, so I’ve experienced the turmoil that comes with going from one release a month to multiple releases per day.
Applying traditional testing approaches might make the challenge seem impossible, and in fact, without completely changing the way we build and test software, we can’t expect to aim at reaching sustainable continuous delivery.
Our adoption of Kanban and the Kanban method was fundamental for the direction we were going. By adopting the method, we were able to identify our bottlenecks, make wait time visible and maximize the benefits of small batches and continuous flow.
We soon realized that if we wanted to have any chance of being able to release continuously, we needed to reduce rework. In the old world, testers and business users would take two weeks of the iteration for their quality control activities. A lot of the time was not spent testing, but identifying and logging large numbers of defects and dealing with unstable environments.
We attacked this problem on three fronts: Infrastructure, development practices, and culture.
Infrastructure: Reduce Human Errors
To reduce rework in our infrastructure, we developed a brand new delivery pipeline that carried both code and context. We also created on-demand test environments, to reduce the amount of time wasted setting them up manually and reworking incorrect configurations.
This meant a drastic reduction of manual steps in build and deployment. While initially this was implemented only on our test environments, it gave us immediate benefits. The ability to test on reliable environments, created with a repeatable process, reduced our test time significantly.
Development Practices: Better Communication, Smaller User Stories
Behavior Driven Development (BDD)
We adopted Behavior Driven Development (BDD) to reduce the misunderstandings between business stakeholders and the development team and as a consequence, reduce rework caused by miscommunications.
BDD gave excellent results very early. We soon realized how much we had left to individual interpretation — and the extent to which this had caused most of the defects we found in quality control activities. Thanks to BDD, defect rates went down dramatically. The more we improved the collaboration within the teams, the more the business knowledge grew within its members. This allowed for easier decision making; decisions that had previously required long, frustrating meetings now became quick conversations.
Smaller User Stories
Another approach we found extremely beneficial in reducing rework was vertically slicing our user stories, hence reducing their complexity. This often meant that the logic in the new code would include a single code path. Lower complexity meant fewer defects and reduced rework.
Balanced Test Automation Strategy
At the same time, we defined a strategy that involved high usage of automation tests at the unit level, a consistent layer of API level automated tests, and a very thin layer of UI-driven tests in line with Mike Cohn’s automated test pyramid. This allowed our regression suite to stay fast and stable, something that’s absolutely fundamental if you want to be able to deliver customer value each time your development team pushes some new code.
Using BDD and implementing test automation didn’t mean that we stopped executing exploratory testing, but that the activity became less and less time consuming due to the reduction of defects and the smaller size of the stories.
Building Quality In
I worked, for a couple of months, on a product that involved the transformation of a stream of data into a different data structure to be consumed by a client, I remember that I never exploratory tested anything for more than 10 minutes, and I never felt as if I was leaving something behind. This was liberating for me, to feel as though I could produce quality work at a fast pace without sacrificing anything.
Our customers didn’t encounter problems either. We were inspecting the application an order of magnitude less than before, but the quality of our output was higher. We were building quality in.
Culture: Encouraging Collaboration
This type of transformation is not too difficult from the technical point of view. It’s far more complicated from a cultural point of view. When I joined the company I am referring to, I found extremely skilled developers that were not used to testing. They had been spoiled by the testers running after their messy code and never grew any interest in the discipline.
Culture is hard to change. Our strategy was to encourage healthy behaviors rather than punish bad ones. For example, we encouraged and praised developers that were willing to test, and we also praised people who worked in pairs. We encouraged and recognized every sort of collaboration. We knew the team had to become a unit of people who trusted each other and not only a group of people with all the skills necessary to deliver a complex solution.
Sharing Knowledge and the Creation of a Test Tribe
We needed to reach a work cohesion that brought the ability to collaborate and removed bottlenecks while keeping work flowing. One key to success was the focus we put on building t-shaped skills by learning from each other and offering help at all times.
One successful initiative was the creation of the Test Tribe. The Tribe was a voluntary and fully autonomous group of people that cared about software quality. After a while, this group of people, which met every week to have Lean Coffee-style conversations, was becoming large, with the majority of its members being developers. I don’t have enough space to mention a number of experiments and improvements that started at this level.
One notable success was the design of a tool that greatly improved testability of our main app, which reduced the time for exploration from hours to minutes. The tribe also contributed to changing our process, removing unnecessary steps, and in one specific instance, identifying a change that reduced lead time by 30% with little effort.
The tribe was thriving and its successes quickly trickled down to the different teams where tribe members existed. Teams started experimenting more and more and improving their systems stepping beyond quality only improvements, it was great to observe.
Build Quality In: Final Thoughts
Any organization can practice continuous delivery — and they should, if they hope to compete in the modern marketplace. Continuous delivery helps organizations not only deliver faster than their competitors, but with higher quality, too.
I’ve seen this work on my own development team, through a series of incremental changes that resulted in a major shift in how we operated — helping us transition from one release a month to multiple releases per day:
Infrastructure: We changed our infrastructure to reduce the number of manual steps in build and deployment. This allowed us to have more reliable testing environments with significantly shorter test times, which meant we could deliver faster with fewer bugs.
Development Practices: We changed our development practices to improve communication up and across the organization. This helped us reduce rework due to miscommunications. We also made user stories smaller and simpler, which reduced complexity and thereby made it easier to deliver frequently. We implemented a balanced test automation strategy, which allowed our regression suite to stay fast and stable.
Culture: Finally, we changed our culture, in the same way we changed everything else — quickly, but incrementally, so that the changes were sustainable. We encouraged healthy behaviors, ones that promoted testing and collaboration between teams. We created a Test Tribe, a group of testing enthusiasts, whose influence spread throughout the organization and helped solidify our new culture: one that was built around collaboration, communication, and quality.
All of these efforts resulted in a system that was designed to deliver fast, with quality built into every step of the process.
![A Global Collaborative Work Management Blueprint [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
