Kanban is a relatively recent approach to software development, which aims to create a development pipeline that continuously delivers constant value. Before delving into the use of Kanban with software development, a brief explanation of the history of both Kanban and software development techniques will provide the context for why Kanban is an important methodology.
What is Kanban?
Kanban is a concept that originated from the Japanese manufacturing sector during the late 1940s, and then became more widely used in the automotive sector during the 1950s when Toyota wanted to streamline its production process.
The literal meaning of Kanban in Japanese is “signal” or “flag.” Taiichi Ohno, the “father” of Kanban, developed the concept because he realized a rather simple principle: no company should start producing any product until one or more customers at the end of the supply chain indicated they needed another product.
Instead of creating queues in a process in which more parts, products, etc. are produced than the next stage needed, Kanban helps to create a smooth flow through the production line, and also reduces costs. An expected benefit was that the production staff would experience less stress as its members could now work at a steady rate.
Kanban enabled the “just-in-time’ manufacturing approach to become the standard it is today almost everywhere and worked so well that it was soon adopted outside of manufacturing.
Read more about Kanban
Software Development Approaches Before Kanban
How software is developed has changed much from the past. Initially, developers wrote code they thought users wanted and shipped it. This approach delivered small amounts of functionality quickly but wasn’t robust enough for large-scale developments.
The answer was to introduce formal techniques, such as Structured Systems Analysis and Design Method, (SSADM). This involved several different teams: business analysts to capture user requirements; systems analysts to develop specifications, designs and models; programmers to produce code; and testers to check it all worked according to specifications. The time required for all these tasks varied for each delivery, and was measured in months and sometimes years!
By the time the new code was deployed, users often wanted new and/or different software. This approach was sometimes known as “waterfall,” as progress flowed in one direction in sequential stages from analysis to deployment. The best practices for IT service management (ITSM) were designed to align this approach with software development.
User frustration with extended delivery times led to the concept of Rapid Application Development (RAD). This allowed code to be developed in parallel but lost much of the controls from SSADM, and soon resulted in a reputation for many companies of delivering bad code quickly! A new approach was needed, which provided the speed of delivery, but with sufficient controls to deliver working software, which led to Scrum.
Scrum concentrates on separating work into small developments that can be completed in short, 2–4 week, fixed-length development cycles, known as “sprints.” The code is released to users in a regular “heartbeat.” Functionality is delivered incrementally during a series of sprints.
The developers are organized into small teams of 3–9 multi-skilled members, and perform the design, coding and testing themselves. Each team also has a Scrum Master who manages it and a Product Owner who gathers requirements and prioritizes the work. Each team has a daily 15-minute “standing” meeting with everyone present, known as a “Scrum,” where progress is tracked and plans are updated.
At the end of each sprint, the entire team reviews what has been finished or “done,” and releases it for deployment. The Scrum approach results in much happier users who receive new and working items delivered much faster than with waterfall.
The Problem Kanban Fixes
Scrum is a great improvement on waterfall, but there are problems. How do you address issues that can’t wait until the next sprint cycle, such as urgent fixes or urgently required new functionality? Scrum provides only one option: to interrupt the sprint and work on urgent matters. This often requires a technique called “swarming.”
Some members of the team are pulled from their current work to focus on the urgent item. It might be completed sooner than waiting for the next sprint, but, meanwhile, their previous project/task is now at risk of not being finished by the end of the current sprint.
Hence, using Scrum and swarming can be a headache if urgent fixes must be regularly developed because of the deployment of flaky code, or, as is increasingly the case in today’s digital age, the business regularly demands urgent changes to remain competitive. Now, however, Kanban is a new concept for software development.
How Is Kanban Applied to Software Development?
The principal distinguishing feature of Kanban’s application for software development is the development of each item is started as soon as a team member is available, and deployed as soon as it’s completed. Unlike Scrum, the development cycles are not fixed.
With Kanban, multi-skilled developers can still design, code and test. Usually, just one person works on each individual development, but small teams can still work on it together. Who will work on delivering each requirement is decided at the daily (or more frequent) standing meetings, when new work items are allocated.
The use of Kanban limits the size of each individual development so it can be delivered quickly, ideally hours or days rather than weeks. Large segments of work are condensed into smaller components with incremental delivery of functionality.
Each team or individual works on just the assigned item until it’s completed and deployed. Waiting until other items are finished is not necessary. The concept may seem similar to swarming, but Kanban eliminates the urgency, and team members don’t have to be pulled from their current work.
Making Work Visual
Kanban software development uses a visual management technique known as a Kanban Board. It uses cards to show the status of each individual development and its progress.
A Kanban board has a number of columns, each representing a stage in the development workflow, such as work waiting to be started, work in progress and work completed. A visual card or sticker represents each unique development.
The card or sticker includes the name of the development and who has been assigned to work on it. The card is moved from left to right on the Kanban board as each unique development progresses through the stages. All members of the development unit use the same board and gather around it at their daily standing meetings.
Advantages of Using Kanban for Software Development
New functionality and fixes are delivered with a much shorter lead-time. Kanban is a fundamental component of the technique known as continuous delivery. Instead of releasing a group of small changes at regular, fixed intervals, each change is released as soon as it’s done. This can be as often as every minute if that’s what your business requires.
It seems counterintuitive, but the risks to the business actually decrease if many small changes are regularly and individually deployed instead of grouping them.
Using Kanban eliminates the need to estimate how much time each development will require for completion. Using Scrum can result in large overhead costs, and If Scrum is used incorrectly, then users will become annoyed they didn’t receive what was promised or developers will have nothing to do.
Kanban essentially eliminates those two possibilities. If each requirement is kept small, then it should be provided relatively quickly. Development cycle times of single minutes can be achieved with Kanban.
Using a Kanban board stops developers from accepting multiple items, which results in work overload – a phenomenon known as “over promised, under delivered.” The number of development items in progress can never exceed the number of developers available.
Hence, no work is started unless there is the capacity for it. Users won’t be disappointed, and by keeping developers focused on one small item at a time, the risk of delivering bad code is reduced.
Separating work into very small items increases the flexibility of your development team, as its members aren’t spending weeks working on the same item.
What Can Go Wrong?
Kanban isn’t a magic solution and errors, wasted time, etc. can still occur.
Developers must be multi-skilled and happy working alone, as all the responsibility is now on their shoulders. Each developer should only work on one task or item at a time, so there has to be enough capacity for the expected workload, including urgent fixes. If there isn’t, then either queue of work increase or people must be pulled to work on urgent tasks, projects, etc., leading to the same issues as Scrum.
Success with Kanban relies on having comprehensive, automated tests to check that every change works and doesn’t stop any other systems, processes, etc. working before it is deployed. Due to the large number of small changes, trying and doing this without automation adds considerable risk and overhead. Strong control of version management is also necessary, with automated “check in/check out” capabilities to stop two people working on the same bit of code at the same time without realizing it.
ITSM change-and-release-management processes and activities will probably need to be updated to align with the continuous and rapid delivery of developments. Approaches, such as weekly change advisory boards, are fundamentally at odds with the principles of Kanban software development.
Can Kanban co-exist with Scrum?
Using both Kanban and Scrum in the same development team is unlikely to succeed. Scrum relies on the fixed development cycle, Kanban has no such concept. Scrum can use Kanban boards to visualize the workflow, but that’s not the correct approach for using Kanban software development.
If your development team says it is using Kanban, then you must check it is doing more than just using a Kanban board to manage the sprints and backlog. If you want to start using Kanban for software development, then it’s best to introduce it one team at a time.
Cover image by Sharmila