How Kanban Enables Continuous Delivery: Planview AgilePlace’s Perspective

On a business level, how does continuous delivery benefit Planview AgilePlace?

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 Planview AgilePlace works as an organization?

It changes the outlook of the entire organization — especially for a product-focused company. At Planview AgilePlace, 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 Planview AgilePlace?

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 Planview AgilePlace 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 Planview AgilePlace, 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 Planview AgilePlace’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.