Kanban

Kanban

Kanban is a method for managing knowledge work which balances the demand for work to be done with the available capacity to start new work. Intangible work items are visualized to present all participants with a view of the progress of individual items, and the process from task definition to customer delivery. Team members “pull” work as they have capacity, rather than work being “pushed” into the process when requested.

Kanban in the context of software development provides a visual process-management system that aids decision-making concerning what to produce, when to produce it, and how much to produce. Although the method originated in software development and IT projects, the method is more general in that it can be applied to any professional service, where the outcome of the work is intangible rather than physical. Kanban came out of lean manufacturing techniques made famous by Japanese automotive manufacturer Toyota who used it to manage their workloads. In Japanese, the word “Kan” means “visual” and “ban” means “card”.

Kanban is a lot more laid back than Scrum; There’s no set time for sprints, no assigned roles outside of the product owner, and a zen-like focus on only the task at hand. You could have meetings about your overall projects, or not: it’s up to your team’s needs.

There are four pillars of the Kanban philosophy that can help make sure your projects get shipped. These include:

Cards (Kanban translates to “visual card”): Each task has a card that includes all relevant info about it; this makes sure everything to complete the tasks is always at hand.

Cap on work in progress: Limit how many cards are in play at once; this prevents teams from over-committing.

Continuous Flow: Move down the list of backlogs in order of importance, and make sure something’s always being worked on.

Constant improvement (otherwise known as “kaizen”): Analyze the flow to determine how efficiently you’re working, and always strive to improve it.

While developed for software development and software teams, the Kanban method (as distinct from Kanban in lean manufacturing) has been applied in many other areas of knowledge work. As a visualization and control mechanism, any repeatable and consistent workflow can be tracked, regardless of complexity or subject area. Business functions that have applied Kanban include:

Human resources and recruitment teams

Sales and marketing teams

Organizational strategy and executive leadership teams

Audit teams

Contracts to project execution process

Accounts receivable & payable processes

Kanban Strengths

Like Scrum, Kanban fits best with a highly cohesive team that knows what it takes to keep the flow going but, unlike Scrum, it’s designed for teams that are self-motivated and don’t need as much management or deadlines. It’s great for those who lean toward seeing the entire project at a glance. While the two-week Scrum rule is absent and subprojects can take however long they’ve been given, you should still have an overall focus on efficiency, which should help save resources. If you’re careful to follow Kanban rules and only assign as much work as a team can handle, projects are less likely to go past deadline and team members are less likely to juggle other distractions. And because the product owner can change tasks that aren’t currently being worked on along the way, it allows for flexibility without frustration.

Kanban Weaknesses

If only one of your team members has a certain in-demand skill, the individual can hold up everything. Kanban is ideal for teams that have members with overlapping skills, so that everyone can pitch in and help decrease the backlog list. It’s also best for places where time on the overall project isn’t quite as crucial; if you must ship by certain deadlines, Scrum gives you the time management structure you need.

Pull System

Kanban is a pull system. This basically means that it is up to each team member to pull work items from one column/state to the next. However, if a card is held in a buffer column and there is spare capacity in the next column, Kanbanara will automatically push the top most card into the next column. In Kanbanara, the only card that is automatically pushed regardless of work-in-progress limits is an expedite one residing in a buffer state.

Continuous Delivery

Although Kanban was primarily developed for continuous delivery, Kanbanara has borrowed sprints, implemented as releases and iterations, from Scrum. A project may support multiple releasesa and each release may consist of multiple iterations. The filter bar makes it easy to switch between the previous, current and next release.

Scrumban

A combination of the two great Lean approaches may lead to an ideal one. Scrumban combines Scrum and Kanban and contains the best rules and practices of both methods. On one hand, it uses the sanctioned nature of Scrum to be Agile, on the other it encourages teams to constantly improve their processes along with Kanban’s aim of continuous improvement (Kaizen).

Scrum works by dividing the team into small multi-functional teams, assigning certain numbers of jobs into sprints and committing the team to complete them by the end of the sprint. It is mainly optimized by looking back at previous experiences.

Kanban concentrates on visualization of workflow and putting a limit onto how much work can be completed at any given time. The prime source of improvement possibilities comes from measuring the lead time, analyzing the cumulative flow diagram and aiming to do better in the future.

The crucial difference in running a Scrum and Kanban board is in the items pull order. In Scrum - once the Sprint was planned and the tasks were placed in the queue, all the team can do is.. to pull. Meanwhile, in Kanban, after the tasks were placed in their appropriate columns, it’s up to the team members which items they prefer to work on first (as long as they pull from the correct column). So, Kanban is more flexible in this respect.

The Scrumban solution promotes an increase in the system’s capabilities, allowing to process more items. Monitoring the lead time is easier, thanks to balancing the team capacity versus the demand.

Since Kanban is fitting in nicely with Scrum - demanding simply more visualization and the appliance of WIP limits, there are no reasons not to try it. What can be gained, is the possibility to always be perfecting the process, and in a slightly more pleasant manner: one could say, that Scrum works much like a shock treatment, whereas Kanban applies a long-term, steady build-up of an evolutionary improvement.