Introduction

The most challenging part of a project is always how to start, prioritise, and when to finish a project. Introduced by the Japanese in the automotive industry to manage the workflow, Kanban is a workflow process that assists in running a project. It helps start, analyse, improve and finalise projects using a workflow method. The Kanban method is a visual tool to see what is being worked on during a project. Kanban also manages the Work in Progress limits (WIP).

Kanban workflow

A basic workflow in Kanban looks like this:


Kanban
Figure: Kanban


Kanban values, principles and agenda

Like Agile, Kanban also has values and principles.

Kanban values


Kanban values
Figure: Kanban values


Kanban principles


Kanban principles
Figure: Kanban principles


The general practices of Kanban

As Kanban is a workflow system, general practices are used to make the workflow visible and manageable. The general practices are as follows:

  • Visualise
  • Limit work in progress
  • Manage flow
  • Make policies explicit
  • Implement feedback loops
  • Improve collaboratively, evolve experimentally

Kanban roles

Kanban has two specific roles, namely:


Kanban roles
Figure: Kanban roles


For example, imagine a Toyota Corolla workshop installing ten new doors onto various cars. When you only have five doors left in a pack, you use a Kanban card to write an order for another ten doors. By the time you have reached your last door in your first pack, you can be sure that you will have a pack of 10 new doors manufactured and ready to be used.

In this way, no spare parts are lying around, creating cluttered warehouses for weeks or months. Kanban has allowed for the ability to scale down the amount of work in progress.

Differences between Scrum and Kanban

Scrum and Kanban are both iterative processes which rely on workflows to manage and prioritise projects.

However, there are a few differences between Scrum and Kanban, which are shown below:

  Scrum Kanban
Roles & Responsibilities Predefined roles No predefined roles. Everyone assists as they’re available
Due Dates & Timelines Project is divided into sprints with a set time to deliver Projects and work are delivered continuously
Delegation & Prioritization Work is completed in batches, and not as the need arises Work is only assigned when the last task is completed
Changes & Modifications No changes mid-sprint Changes happen as need arises, thus creating iterations
Best for… Best for teams whose objectives change over time Best for teams with stable and well-set priorities that hardly change over time

User Stories, Epics, Themes and Features

When planning a project, we must understand what needs to be done and why, which requires both a high-level and low-level view. Using Themes and Epics allow us to get a high-level view of our tasks, while features and user stories let us get more specific and detailed about exactly what must be achieved.

User story

We covered user stories earlier when discussing functional specifications. In short, a user story is a short description - usually from a user to the system - describing what needs to be enhanced or fixed by the system. The user will describe it as:

  • Role of the user
  • What they want
  • Why they want it

User stories are normally written down on sticky note-sized sheets. They are stuck on a board for everyone to see and are then discussed in detail.

Theme


Theme
Figure: Theme


A Theme is a collection of stories within a category and often has organisation-wide importance, and is generally quite broad in its focus. An example of a Theme might be ‘customer contact’.

This theme can then be broken down into Epics.

Epic

An epic is a large user story. The full requirement needs to be broken down into smaller parts for development. An example of an epic would be:

“As a customer, I can get in contact with the business via the website so that I can find out about the product.”

Feature

A Feature is a distinct element of functionality that can provide business capabilities.

Our Epic of getting in contact via the website can then be broken down into features like including a contact form or adding a live chat widget to the site. It generally takes many iterations to deliver a feature.

User Story

A user story is a part of the Feature. By splitting a Feature into smaller stories, the user can give early feedback to the developers on issues quickly. The user stories can then be broken down further into tasks that the developers need to complete.

Understanding the language

It should be noted that you may find some discrepancies online between user stories, epics, themes and features. Some refer to Features as the same as Epics, whereas others see features and user stories as the same. Ultimately, every individual or company will have a slightly different interpretation, but the above is a basic understanding of each concept.

Continuous Integration

Continuous Integration (CI) is a development practice that developers use to integrate code into a shared repository several times a day. Usually, this is done within a testing environment. Once the developers check in their code, the check-in is verified by an automated build. This verification allows for problems or bugs to be detected early on.

The benefits of CI are as follows:

  • No more time-consuming and tense integrations and builds
  • Increased visibility enabling better communication with the development team
  • Early detection of build problems and bugs

📄 DOCUMENTATION

AWS docs: Continuous integration.

Continuous Deployment

Continuous deployment is deploying the latest, successful build into production - making it available to the users. Once a build has passed and is successful and user-tested, it can be deployed to production. This ensures that bug fixes to the users are dealt with quickly and will not slow down business processes.

📄 DOCUMENTATION

IBM docs: Continuous Deployment.

Feature Branching

Unlike continuous integration, feature branching is where a branch is created from the master branch for a new feature. All developers will then code their separate tasks using this branch. You cannot merge a feature branch to the master branch if all developers are not done with their code. This will result in merge conflicts which will then have to be resolved.


📄 DOCUMENTATION

IBM docs: Manage your work by using Kanban.



Activities

💻 WATCH


Lesson Task

Brief

Gain a better understanding of Kanban by relaying its definition, values and practices in your own words.

Level 1 Process

  1. In your own words, define Kanban.
  2. List the values and the agenda of Kanban.

Level 2 Process

  1. Discuss the general practices of Kanban and include all role players, if any are involved.
  2. Draw a diagram of a simple workflow in the software development cycle.
Tags: