In this three-part series on Kanban for DevOps, Dominica DeGrandis, Director of Training and Coaching at LeanKit, explains three key reasons why IT Ops teams and those implementing a DevOps value chain use a lean flow approach to product development. Here’s part one.
Reason #1: The work isn’t done until it’s working right in Production.
There’s a joke in software development about being “done” and being “done-done.” Single-done is the platitude; double-done is the retort. Corks pop, banners fly, the new feature is “done” — but real work still remains. Work requiring someone from operations to stay behind to get it “done-done.”
Double-done signifies the real finish line, when everyone can relax and make merry — often quite awhile after the code is shippable or even delivered to production. By the time all the operations tasks are truly done, the party is usually over and there’s nowhere to go but home, to catch a few hours’ sleep before getting up to go to work again.
Lean flow — also known as Kanban for knowledge work — lifts operations out of the double-done muddle. As a systems thinking approach, it encourages development and operations to map the entire work stream and consider all relevant tasks, including those routinely relegated to post-production. This unified work stream increases the odds that everyone can celebrate crossing the finish line together.
Why “Double-Done” Completion Practices Exist
Before we explore reasons why Operations teams use a lean flow approach, let’s take a closer look at the business reasons for commonplace “double-done” completion practices: marketing, maintenance, and risk.
Generally speaking, customers disregard the fanfare of the single done. They don’t care if the code is in a shippable state. For customers, the new feature is not truly done until after the code is delivered to production, stabilized, and performing correctly. In the context of feature marketing, however, the single-done gives a fair signal to obtain feedback, to amp up the market buzz, and to anticipate the double-done.
To remain competitive, businesses need a certain level of confidence to ensure that the new feature is resilient—that it is being monitored and maintained. The double-done model gives businesses a window (usually too short a window) to acquire the necessary elements for resilience, such as sufficient hardware capacity, storage, and security, as user volume increases.
To avoid the risk of bungled updates, multiple team members must learn to troubleshoot and fix problems related to the new feature. To facilitate future support capability, some form of documentation is needed. Double-done practices provide a place to verify that support systems are adequate to anticipate and reduce risks.
While double-done completion practices do serve some business needs, a lean flow approach addresses all of the above and more, within a fully transparent workflow.
Kanban for DevOps: Crossing the Finish Line Together
Kanban provides end-to-end visibility of all the states the work must go through in order for the feature to be reliable for customers and safe for businesses.
Lean flow methods use Kanban boards to provide a visible connection between all the work states in the system. Blocked work that is preventing other work from being completed becomes self-evident. Dependencies between teams or with third-party vendors emerge as indisputable. And furthermore, because all the skill sets required for a feature’s completion have a voice in the process, it becomes a delightful experience for employees.
The Bottom Line
With Kanban’s end-to-end, lean flow approach, “done-done” can become truly done. When we are able to visualize and consider the entire work stream, bottlenecks previously invisible can be addressed, tasks required after code is deployed to production can become mainstream, and everyone can join the party at the finish line.
Find out the second reason why IT Ops uses lean flow — read part two in the Kanban for DevOps series.