KANBAN

The process of “just-in-time” stock replenishment was originally seen in grocery stores when shelves were restocked:

• based on the gaps in the shelves.
• not based on the supplier inventory.

It inspired Taiichi Ohno to develop Kanban which applied on the main manufacturing facility of Toyota in 1953.

Kanban is created in first time for operations.

So, in lean manufacturing (which is operations), Kanban is a system for scheduling and controlling the stock replenishment of industry facilities.

Later, based on lean thinking principles, Kanban method was developed to deliver projects.

The idea of Kanban is to:

• allow continuous flow of:

- work by the teams.

- delivered value to the customer.

by pulling items to be addressed rather than receiving them when needed.

• visualize the work progress to all team and key stakeholders.

The Kanban Method is less prescriptive than some agile approaches; so, it is less disruptive to be entered for implementing in organizations that do not use Kanban method.

They can easily begin partially applying Kanban methods in their projects then gradually increase application toward fully implementing as per the business requirements.

In management, Kanban is a multi-teams process method that used to manage product development.

The method originally consists of Kanban roles, artifacts and rules.

When it is applied to project management, events emerged but without consensus.

Kanban is used in not complex processes and projects.

Usually, the increment in Kanban is small and not complex.

This reduced the implementation the Kanban events such as sprint planning meeting and retrospective meeting.

Kanban uses sprints approach to deliver working product.

It is run on sprints of timeboxes that NOT equal.

The sprint is a stage where a potentially releasable increment of product (working product) is produced.

KANBAN ROLES

Despite these roles are not common when use Kanban in operations, the "Agile Practice Guide - PMI" defined these roles for Kanban in projects.

1. Service Request Manager:

He is an individual that is responsible for:

• defining and maximizing the value of the product.
• creating, prioritizing and communicating the product backlog.
• ensuring that the product backlog is transparent, visible and understood.
• approving requested changes to the product backlog.
• communicating the project objectives to internal and external stakeholders.
• participating in demos for stakeholders meetings and retrospective meetings.

Service Request Manager better be specialist in the project discipline, not just a client representative.

2. Service Delivery Manager (AKA Flow Master):

The coach for a team and service request manager working in a continuous flow or Kanban context.

He is the servant leader who is responsible for:

• ensuring the Kanban process is appropriately performed and is effective by ensuring that the Kanban team adheres to Kanban practices and rules.
• coaching the development team members in self-management and cross-functionality.
• removing impediments and obstacles that face the work.
• protecting the team and the process from disruptions.
• facilitating the Kanban events to ensure they are effective and within the timebox.
• explaining agile to internal and external stakeholders as required.
• helping the Kanban team to focus on creating high-value increments.
• helping the service request manager in managing the product backlog such as creating, prioritizing, communicating, grooming and changing it.

3. Development Team:

It is a group of individuals that:

• comprises a team that is:

- cross-functional

- self-organizing

• are committed to creating shippable working increment each sprint.

The development team should have everything the team shall need to deliver working products without depending on others outside of the team.

The development team is responsible for:

• developing a plan for work that defines actionable plan that contains activities for delivering each increment.
• creating a shippable working increment each sprint.
• continually adapting their actionable plan towards sprint objectives.

KANBAN EVENTS

Despite these events are not common when use Kanban in operations, projects nature required to implement some or all of these events when use Kanban in a project as required.

1. Sprint:

It is timeboxed stage where a potentially releasable increment (working product) of the project product is produced.

The increment is produced during the sprint by one or more teams.

Kanban does not use the term "Sprint" but it uses the term "Cycle Time" for the duration of the sprint from pulling the story till it be described "Done".

2. Sprint planning

A collaborative event conducted by:

• service request manager
• service delivery manager
• development team

where they plan the work of the current sprint.

The sprint planning includes:

• The Sprint objectives. It is identified by the whole Kanban team.
• Items from the product backlog to be developed in the sprint. They are selected by the development team.
• Actionable plan that contains activities to develop the increments. It is prepared by the development team.

These three items are referred to as the sprint backlog.

Sprint planning is timeboxed to maximum eight hours for a one-month sprint.

3. Daily Standup:

A brief, daily collaboration meeting conducted by:

• service delivery manager
• development team

In this meeting they:

• review progress from the previous day.
• adjust the sprint backlog and work plan as necessary.
• present the works to be performed on the current day.
• highlight any obstacles encountered or expected (not discuss the obstacles nor how to remove them).

The service delivery manager and development team can hold other meetings as required during the day to discuss:

• adjusting the sprint backlog and work plan for new arising reasons.
• in more detail, the adjustments on the sprint backlog and work plan that discussed in the daily standup.
• in more detail, the obstacles that presented in the daily standup and how to remove them.
• the technical aspects of the development.

Usually, the daily standup is held every working day at the same time and place.

The daily scrum is timeboxed to 15 minutes.

4. Sprint review:

It is a meeting conducted by the:

• service request manager
• service delivery manager
• development team
• selected key stakeholders

at the sprint end.

In this meeting:

4.1. the service delivery manager and the development team review the sprint outcome by:

4.1.1. inspecting it.

4.1.2. determining future adaptations to it.

4.2. the service delivery manager and the development team present to the service request manager and selected key stakeholders:

4.2.1. the sprint outcome (the increment) with analysis of:

4.2.1.1. items that done as planned

4.2.1.2. items that not done considering their mandatory deadlines.

4.2.1.3. incorporated changes

4.2.1.4. overcame obstacles

4.2.2. the progress toward the project outcome.

4.3. the attendees validate the sprint outcome and decide:

4.3.1. what items to be categorized “Done”.

4.3.2 what remain categorized “Not Done”.

4.4. the attendees suggest:

4.4.1. adjustments and updates to the product backlog if required.

4.4.2. changes on processes or team if required.

The meeting outputs may affect the product backlog.

The sprint review is timeboxed to a maximum four hours for a one-month Sprint.

Usually, this meeting conducted to discuss more than one increment that developed by various sprints.

5. Sprint retrospective:

It is meeting that conducted by:

• service delivery manager
• development team

after the sprint review where they plan ways to increase quality and effectiveness of the:

• development processes.
• development tools.
• development team performance.

The development team discusses:

• what done well during the sprint.
• what not done well during the sprint how they were (or were not) solved.
• what would done better if somethings were different.
• the delivery performance of development team
• what can improve the processes, tools and team performance.

The meeting outputs may affect the:

• product backlog.
• sprint backlog for the next sprint.

Sprint retrospective is a lessons learned workshop.

It should be conducted in trust atmosphere without blaming or judging.

The sprint retrospective is timeboxed to a maximum three hours for a one-month Sprint.

Usually, this meeting conducted to discuss more than one sprint.

KANBAN RULES

1. Kanban Board Use:

It is a project management tool that is board consists of:

• agreed columns (such as ready, analysis, development, test, done)
• names of work items in progress in each column which be transferred to the next column when the work on it on the current column is completed.

Kanban board should have:

• criteria of transiting values between states.
• expected duration for work item (story) in each column. It is known as Service Level Expectation (SLEs).

Kanban board:

• visualizes the work for the development team and stakeholders.
• facilitate limiting the WIP.

These two ultimately enables identifying the inefficiency point and maximize efficiency.

Kanban boards can range from low-tech (low human interaction) to high-touch technology (high human interaction).

The board acts as an information radiator to anyone who sees it, providing up-to-date information on the status of the work of the team.

2. Work in progress limit (WIP):

WIP limit is the maximum allowed amount of work (measured in stories) in each column in a task board.

The WIP limit for a column covers the "Doing" and "Done" works under this column.

This column is applicable to reach its WIP limit if:

• the team of this next column does pulls to "Doing" many items from the previous column.
• the team of the next column does not pull from "Done" in this column.

Typically, the development team determines and agrees the WIP limits for each column then revises it as the project progresses.

The WIP limits are determined and revised, in a manner that guarantees the maximum work flow, based on the:

• number of members in each column.
• team member capabilities and skills.
• nature of the stories.
• available development and testing resources.

WIP limits target to encourage the culture of "done" by enabling the team to identify "nearly done" tasks and focus on them.

WIP limits make blockers and bottlenecks in a team's workflow visible; so they are urgently resolved which ultimately reduces the development inefficiency.

The development team is responsible for ensuring that all WIP limits are not reached.

If a column reaches its WIP limit, the development team immediately:

• should NOT pull from left column any work item to this column before it is relieved from the WIP limit.
• should swarm this column to complete some work items to relief this column.

If more than one columns reaches their WIP limits, the development team should relief these columns starting from the right-most overloaded column going to left.

Limiting the amount of work in progress makes it easier to identify inefficiency points in the workflow.

KANBAN ARTIFACTS

1. Product backlog:

It is a prioritized list of work items that the development team shall develop during the project.

It is derived from the product requirements by the service request manager in collaboration with relevant stakeholders such as the:

• business analysts
• end users
• development team
• subject matter experts

It is the single source of:

• work to be undertaken by the development team during the project.
• work items to be selected for development in the sprints.

Outside the sprints, the product backlog continually be updated as necessary by adding, eliminating, refining, splitting and/or reordering the work items.

The product backlog update should be upon the service request manager approval.

This process in also known as grooming.

2. Sprint backlog:

It is a list of work items identified by the development team to be completed during the sprint.

It also includes actionable plan that contains activities for delivering the Increment (the sprint plan).

However, it accepts swarming to remove bottlenecks.

It is prepared by the development team.

It can be updated during the sprint the development team but without adding new tasks from the product backlog.

3. Increment:

It is a functioning, tested and accepted product that is a subset of the overall project outcome.

It is described as shippable working product.

KANBAN STEPS

The following steps are the ideal steps for developing a product by Kanban method.

As Kanban was originally developed for operations, Kanban did not include all these steps.

But when applied to a project, some or all of these steps are applied as per the project nature.

As Kanban focuses on continuity, they are not typically implemented for each sprint.

In many situations, some steps of number of sprints are joined such as sprint review meeting and spring retrospective.

And in other situations, they are omitted.

The following steps are performed by more than one development team.

But always, in Kanban, it is more important to complete work than it is to start new work.

Step 1:

The project sponsor selects the followings from his organization or contracts with a contractor to provide them:

• service request manager.
• service delivery manager.
• development team.

Step 2:

The service request manager:

• defines the maximum values that the project outcome shall provide (define project scope).
• develops the product backlog from the product requirements in collaboration with relevant stakeholders.
• prioritizes the product backlog.
• communicates the product backlog and the project objectives to the service delivery manager and the development team.

Step 3:

1.? The development team in collaboration with

• service request manager.
• service delivery manager.

agrees on:

• team capacity.
• composition of the development team and specialization roles.
• management and technical tools.
• total efforts to deliver all items in the product backlog.
• Kanban board columns.
• criteria of transiting values between states.
• expected duration for work item (story) in each column (the SLEs).
• WIP limits.

Step 4:

The:

• service request manager.
• service delivery manager.
• development team.

conduct a sprint planning meeting for the first sprint to plan the work of the sprint such as:

• defining the sprint objectives (by the whole team).
• selecting Items from the product backlog to be developed in the sprint (by the development team).
• setting actionable plan that contains activities to develop selected items considering scope, time and cost of the sprint (by the development team).
• organize these three items in the one document called sprint backlog (by the development team).

Step 5:

The:

• service delivery manager
• development team

conduct the daily standup meeting for the sprint to:

• review progress from the previous day.
• adjust the sprint backlog and work plan as necessary.
• present the works to be performed on the current day.
• highlight any obstacles encountered or expected.

Step 6:

The development team:

• develops and tests the items in the sprint backlog.
• adapt the actionable plan:

- to better delivery.

- towards sprint objectives.

The service delivery manager:

• ensures that the work processes are appropriately performed and are effective.
• coaches that the development team members in self-management and cross-functionality.
• removes the impediments and obstacles that faces the work and development team.
• protects the team and the process from disruptions.

Step 7:

The:

• service delivery manager
• development team

can hold more meetings as required during the sprint to discuss:

• adjusting the sprint backlog and work plan for new arising reasons.
• in more detail, the adjustments on the sprint backlog and work plan that discussed in the daily standup.
• in more detail, the obstacles that presented in the daily standup and how to remove them.
• the technical aspects of the development.

Step 8:

The:

• service request manager
• service delivery manager
• development team
• selected key stakeholders

conduct a sprint review meeting at the sprint end.

In this meeting:

• the service delivery manager and development team:

- inspect the sprint outcome (sprint increment)

- present the sprint outcome (the increment).

- present the progress toward the project outcome.

• the attendees:

- validate the sprint outcome and decide on what items considered “Done” and items considered “Not Done”.

- suggest adjustments and updates to the product backlog, project team and processes if required.

Usually, this meeting conducted to discuss more than one increment that developed by various sprints.

Step 9:

The:

• service delivery manager
• development team

deliver the sprint outcome (sprint outcome).

Step 10:

The:

• - service delivery manager
• - development team

conduct a sprint retrospective meeting after the sprint review meeting.

In the meeting they plan ways to increase quality and effectiveness of the:

• development processes.
• development tools.
• team performance.

by discussing:

• what done well during the Sprint.
• what not done well during the Sprint how they were (or were not) resolved.
• what would done better if somethings were different.
• the delivery performance of development team.
• what can improve the processes, tools and team performance.

Usually, this meeting conducted to discuss more than one sprint.

Step 11:

After the sprint completion, the service request manager:

• return the “Not Done” work items to the product backlog.
• review product backlog, update it by the considering feedback and reprioritize its items as required.
• if requested, approves/disapproves the requested changes to the product backlog.

Step 12:

The development team calculates the team velocity in (stories/sprint) or (story points/sprint) by dividing the:

• actual completed stories or the story points of actually completed stories in all previous completed sprints.

by

• number of these sprints.

The team velocity is a factor for assessing the duration of the next sprint.

Step 13:

The:

• service request manager
• service delivery manager
• development team

repeats the steps from step "4" for another increment till all teams complete all work items in the product backlog.