Kanban and continuous delivery are technical practices that go hand in hand.
The goal of continuous delivery is to rapidly, reliably and repeatedly deliver new features and bug fixes at low risk and with minimal overhead. The goal of Kanban is to optimize the flow of work through incremental change. Both approaches share the common objective of delivering value to the customer faster.
Kanban and continuous delivery also complement each other with their shared objective of process improvement. Continuous delivery, which can be delayed by manual effort and human error, often uses automation to make processes more efficient.
Ideally, automation will make a good process better; but, automating a bad process can have disastrous effects. Kanban steps in by helping you mirror your process, allowing you to instantly see where work flows and where work gets stuck. This, in turn, can show you which steps to automate and which steps to improve before they’re automated.
The combination of Kanban and continuous delivery causes a fundamental shift in how work is planned and managed. Instead of batching features in big releases, continuous delivery favors frequent, small releases. Kanban, as a continuous flow methodology, associates value with finishing. As a result, software development teams are encouraged to develop, test and release new features and fixes in a continuous manner, completing work in progress before starting new work.
Here at LeanKit, we’ve been practicing Kanban and continuous delivery from the get-go. Five years in — while we’re not perfect — we thought it might be helpful to share what we’ve learned along the way. We interviewed members of our software development team to understand how Kanban enables the practical implementation of continuous delivery.
Kanban and Continuous Delivery: CTO View
Why did LeanKit decide to follow a continuous delivery approach?
Our top priority is delivering value to customers as quickly as possible, so it feels counter-intuitive to batch up new features and bug fixes and wait for the next big release. Why keep our customers waiting?
Also, given that Kanban is in our DNA at LeanKit, we’re always looking for ways to improve. One of my primary goals as CTO is to reduce the transaction cost — or overhead — associated with delivering new features. Practicing Kanban and continuous delivery together supports that goal, constantly driving us to evaluate and improve our processes, tools, methods, architecture and culture to increase operational effectiveness.
On a business level, how does continuous delivery benefit LeanKit?
The main benefit is the reduced time it takes to build new features and deliver them to customers. As a result, our feedback loops are much faster, mitigating the risk of investing too much time in work that doesn’t provide value. We’re able to quickly adjust direction based on customer feedback.
From a technical standpoint, delivering product updates more frequently also reduces the risk of something going wrong, since there is less surface area being deployed each time. And, if there are any issues, we can resolve them quickly with minimal inconvenience to our users. Overall, this results in more reliable and higher quality software.
How has continuous delivery changed the way LeanKit works as an organization?
It changes the outlook of the entire organization — especially for a product-focused company. At LeanKit, we have anywhere between two and 30 deployments per week. This pace impacts not only development, but also how we coordinate our marketing, sales, operations and delivery activities. Continuous delivery requires tight cross-team collaboration to stay informed and adjust accordingly.
To this end, it helps that our entire organization practices Kanban. Everyone in the organization has visibility into what’s being worked on and what’s coming next at any given time. This ensures that we stay aligned and can adapt quickly to changing priorities.
Kanban and Continuous Delivery: Dev Team View
From a developer’s viewpoint, what are the benefits of continuous delivery?
Continuous delivery makes us a lot more nimble as a team. We’ve all had prior work experiences where we’ve been on a rigid release schedule. The general consensus of the team is that continuous delivery is a much smoother — and less stressful — way of working.
It’s also easier to troubleshoot problems. There can be a lot of trepidation associated with a big release as there’s so much more that can go wrong. When fewer changes are made to the code base, we can quickly find the root cause of issues, and if need be, rollback with minimal disruption to customers.
We also don’t have to relearn our process every time we deploy. If you’re only releasing a few times a year, it’s more likely that things will go wrong. For us, since we’re releasing almost daily, deployments go a lot more smoothly.
What’s the impact on team morale?
It’s easy for teams to lose momentum when they spend time building features that no one sees for another six months. With continuous delivery, it’s exciting to build something and immediately receive customer feedback. It’s more rewarding and keeps us engaged with our customers. It’s similar to the gratification we get from moving a card across a Kanban board. Moving things to “done” gives everyone a sense of accomplishment.
How does continuous delivery work at LeanKit?
For us, continuous delivery starts with how we break down the work. We’ve become adept at breaking it into small, releasable chunks that we can move through our process relatively quickly.
Upcoming work and bug fixes are captured and prioritized on our team’s Kanban board. Once the build and test work have been done, we release the code in our staged environment called “dogfood.” This enables us to test with our internal LeanKit users in a real-world scenario and address any bugs before we deploy. Once the new code is in production, we constantly monitor feedback so we can quickly respond to any issues.
We also distinguish between continuous delivery and continuous deployment. At LeanKit, we have the flexibility to release code to production and control when it’s accessible to users. We achieve this by building feature enablement capabilities into our core architecture so we can easily turn features on and off.
How much of LeanKit’s software delivery process is automated?
We’ve automated some aspects of our process — such as unit testing and deployment scripts — but for the most part, we’re taking baby steps. We’re always looking to automate parts of the process to make it more efficient; but, to keep our flow consistent, we move toward more automation in small, incremental steps.
To us, it’s more important to get the underlying process right before trying to automate everything. If the cost and effort required to automate a part of our process doesn’t outweigh the transaction overhead associated with it, then we don’t do it.
What’s the biggest challenge associated with continuous delivery?
The main challenge is the pace of work. Things move quickly, which requires everyone to be in sync. If just one of us falls out of alignment, it can cause a lot of friction and slow the process down.
How does Kanban enable continuous delivery?
The ability to visualize all of our work on a Kanban board and know the latest status at any given time makes a huge difference. It provides us with a signaling mechanism that lets us know what’s coming so we can keep the work moving.
Kanban also helps us create a steadier workflow, since we can absorb unplanned work (such as bug fixes) more easily. That, in turn, helps us avoid bottlenecks. We’re constantly able to re-prioritize work and focus on finishing the work we’ve started rather than switch between tasks.
Kanban is a methodology that promotes incremental improvement, which is essential to success with continuous delivery. It takes time to figure out the best way to get things done as a team.
Can you provide an example of process improvement?
Our old process allowed developers to begin something new once they completed the build work and passed it off to QA for testing. If an issue was found in testing, then the work had to go back into the build queue to be resolved. Sometimes the work would be passed back and forth a number of times before it was finally production-ready.
When we looked at our metrics, we saw that the back-and-forth work slowed down our process and caused inefficiencies. As a result, we changed our process. Now, the Director of QA has to release a developer from what he or she is currently working on before new work can be pulled. The result is a much faster resolution of issues. There’s no wait time, so work is delivered more quickly, overall — even if it introduces some some slack time for the developers.
Tips for Practicing Kanban and Continuous Delivery
Based on our experience, we’ve discovered that it’s easier to practice Kanban and continuous delivery when you remember the following:
- Focus on your process first. Don’t try to implement a new process and automate everything all at once. Take baby steps. Incremental improvement is the key to making continuous delivery work.
- Do what makes sense. Begin by addressing the parts of your process that incur the highest transaction cost. If the effort required to automate or change a part of your process doesn’t outweigh the transaction cost associated with it, then don’t do it. Constantly re-evaluate your decisions and make incremental improvements as you go.
- Make your work visible. It’s easier to work effectively as a team when everyone knows what’s going on. If nothing else, putting all of your work on a Kanban board helps you wrap your arms around the work that needs to be done. You can’t leave it to chance with continuous delivery. Things just move too fast.
- Make sure all stakeholders are involved. With a continuous delivery model, the overall value stream typically includes stakeholders that are both upstream and downstream of the development process. It’s important to make sure that the impact on the entire organizational system is considered and communicated. Otherwise, you’ll find that you’ve implemented only localized efficiencies, which may cause bottlenecks further downstream.