Test - Yash-777/kanboard GitHub Wiki

Kanban Fundamentals - 8
Kanban boards       - 4
Understanding reports in kanban - 7
Metrix in Kanban    - 7
Manage Flow of work in Kanban - 6
Kanban Best Practices - 8

Kanban Best Practices

WIP

  • Team can breach/review its WIP limits at regular intervals. The WIP limit of ‘Code’ workstage was breached very frequently – every other day
  • Implementing WIP limits is essential for implementing a 'Pull based' system
  • WIP limit indicates the maximum number of 'in-progress' items allowed in a column at any point in time.

A workstage in the work flow can be given a number as the ‘WIP Limit’ that indicates the maximum number of work items that can be present in that workstage at any given point of time. The following points are to be noted regarding WIP limits.

  • It can be different for different workstages in a workflow
  • The value provided for WIP limit can be revisited as it continuously gets refined
  • The initial stage (ex: arrival queue, product backlog) and the final stage (ex: release, done) usually does not have WIP limits
  • The initial workstage may need a WIP limit if there is planning involved on how many items to be picked up for execution
  • The final workstage may need a WIP limit if the release is manual and the team’s capacity to handle release To help the situation, Ben decides to introduce WIP limits to workstages as appropriate.

In a team of 'x' to start introducing WIP limit at the workflow stage level.

  • X+1
  • [WRONG]WIP 2x can consider at the starting point.

Making process policies explicit

Hence it is mandatory for the team to be able to segregate inflowing work items, prioritize it and handle it accordingly inside the Kanban board.

  • Cards in To-Do list must be prioritized by product owner.
  • Card is considered as completed only after peer code review and unit testing is done
  • Cards can be moved to Done only after validation by product owner

Sign of Bottleneck

The downstream entity has completed something by consuming an input provided by upstream entity
Therefore, the upstream entity should produce a replacement input for the downstream entity for the production to continue

  • Work is getting stalled in the earlier stages of the workflow.
  • Members responsible for downstream work are often idle.

Queues in the Work Stages

  • Queues helps in identifying where the work is getting stuck
  • Shorter queue lead to shorter wait time
  • Maximum the amount of work in queues relative to the WIP limit
  • [WRONG] Minimize the amount of work in queues relative to the WIP limit

Manage Flow of work in Kanban

Bottleneck appropriate action

Increate WIP limit of the work stages present before the blocked stage until the blocked stage is free.

[NOT]Change the process to create a balanced workflow by rearranging the team composition and change the flow to create a balanced WIP limit.

HIGH WIP limit

  • Allows flexibility to take up new tasks
  • Allows a steady process in the workflow
  • Blocks item that take more time
  • Less focus on completed work

LOW WIP

  • Allows complete control to foresee any bottleneck
  • Focus on removing blocked items
  • Allows improved team interaction and frequent revision of policies.

Expedite Lane

When items are taken up in the expedite lane, the work in progress in the regular lane is put on hold, the WIP limit is breached if needed and the critical work items are attended to.

  • An expedite lane always help in accommodating high priority items like escalations.
  • Expedite lane items are worked by putting on hold the 'in-pregress' work items.
  • WIP limit breach should breached
  • An expedite lane can have multiple work items only if team has diverse application skills


Understanding reports in kanban

Bottlenecks Scenario

Suitable Solution: There is a bottleneck situation which can be solved increasing the WIP limit in stage 2 to 5

Understanding the data on a CFD Chart

The Bands are Progressing in Parallel. (CFD processing parallel over a period of Time.)

This means that your throughput is stable, and new tasks are entering your workflow in parallel to those that are leaving it. This is the ideal outcome and shows that you can focus your efforts on shortening your assignments' cycle times.

A Band is Rapidly Narrowing. (CFD Rapidly Narrowing over a period of Time.)

The number of cards that enter the corresponding stage on the Kanban board is higher than the number of assignments leaving it.

CFD Statements

Cumulative Flow Diagram (CFD) is a simple yet powerful metric that provides you rich information about your system/ team capability at a glance.

The slope of the CFD is an indicator of what your Kanban system's throughput is – the higher the slope, the greater the throughput, throughput being the number of cards delivered per unit of time. ... the Increasing thickness of bands indicates a trend of increasing lead-time and cycle times.

  • Higher the slope in the CFD, greater is the throughput.
  • Increasing thickness of bands indicates a trend of increasing lead-time and cycle times.
  • Increasing thickness of any individual bands indicates more work being pulled into the stage of the workflow.
  • CFD fives you a cumulative flow of work through various work stages.
  • If the bands in the CFD are in parallel and equally spaced, process is stable

The various color bands indicate the different stages of the workflow. The height of each band at any point of time indicates the number of cards in that stage at that point in time.

CFD Kanban system

CFD's can be created for any system where work is being done. it shows the quality of work in a given state at a given point of time. [Wrong] CFD's are only relevant for teams that need statistical process control as a part of their organisation standards

CFD Times Bcklog, LeadTime, CycleTime, WIP

Docs Mirosoft

Kanban Board Normal and expedite lane

Docs Mirosoft


Metrix in Kanban

what is the cycle time for each transaction for an online retail app which can service a 1000 customers transactions in one hour?

Parts per Time Period Cycle Time Formula

Total Parts Produced / Production Run Time = Actual Cycle Time (parts/min)
10 parts/min = 1,200 parts / 120 minutes

Cycle Time = Work In Progress / Throughput work in progress = (Backlog – Done)
Work in progress = No. of work items in progress
Lead time = Waiting time + Completion time
Avg. throughput = Work in progress / Avg. lead time
Throughput = Work In Progress/ No.of tickets

Ans: 1000/60 = 16.667 min

Cycle time = Net production time / Produced units
After working for 2 hours every day, for six days, you've made ten pieces of jewelry.
Cycle time = 2h * 6 / 10 = 72 minutes / one piece of jewelry

Example: Consider a manufacturing facility, which is producing 100 units of product per 40 hour week. The average throughput rate is 1 unit per 0.4 hours, which is one unit every 24 minutes. Therefore the cycle time is 24 minutes on average.
Cycle time = 40hPerDay * 6Day / 100 = 2400 min/ 100 units = 24 minutes

Team following kanban has 42 cards in process and a throughput of 1.25 cards/day. what is the cycle time?

Ans: Cycle Time = Work In Progress / Throughput work in progress = 42 / 1.25 = 33.6 days

Cycle/Flow efficiency

To calculate your flow efficiency percentage, simply divide the time you actively spend working with your total cycle time and multiply the result with a hundred.

Process Cycle Efficiency [%] = Value Added Time / Cycle Time * 100

Let’s suppose your team needed 10 days to deliver a feature, but has only spent two days working on it. The flow efficiency of that feature would be 20%.

2/10 x 100% = 20%

Lead Time

Lead Time: The time difference between the point of time at which request received and the time at which it was delivered

The time difference between the point of time at which request was made by the customer for a task and the task outcome was delivered to the customer, sums up the lead time. It includes the process time and the wait time spent by the work items in the queues of different workstages.

The time difference involved in a work item traveling from one workstage to another workstage in the workflow is referred to as the cycle time.

cycle time: The time difference between the point of time at which service request started and the time at which it was delivered

Consider the following statistics for the team following kanban

Work item # Day # in
ready queue
# of days taken for
completion (cycle time)
Lead time Completion rate
A1 0 4
A2 1 5
A3 2 7
A4 3 12

NOTE: The table indicates that on Day1 we have [A1, A2], D2[A1, A2, A3], and so on.

8.5 days, 8 days, 6 days, 4 days

Request Received, Finish work = Y and Start Work, Finish Work = X.

X is the Cycle time and Y is the lead time. Cycle time begins at the moment when the new arrival enters "in progress" stage and a team member is actually working on it. Lead time is the total time taken by a work item to move through the entire workflow.

Consider the follwoing metris for a project adopting kanbab. The lead time for a user story is 2 days. The number of user stories in progress is 20 on an average. what is the throughput?

Avg. throughput = Work in progress / Avg. lead time = 20/2 = 10 user stories


Kanban Fundamentals

Manufacturing principles:

  • The work is split into multiple stages
  • Minimize idle inventory for lack of warehouse space
  • On-demand production (as mentioned above)

Scrum vs Knaban

Metrics:: Scrum: Velocity, Knaban: cycle time Time-box:: Scrum: Limited by sprints, Knaban: Limited by WIP Changes cannot happen during the sprint whereas it can be made anytime in kanban

Kanban

  • It is a pull-based method(pull work rather than push work): Downstream wokstage pulls from upstream on need basis
  • Defects are never passed on to the next stages
  • Production is leveled throughout the system to prevent bottlenecks. Inventory and lead times are reduced through Heijunka (leveling of production)

Equally important, Toyota has built up a system of respect for people ingrained in the TPS concept. It puts emphasis on the points as follows: * Elimination of waste movements by workers * Consideration for workers safety and * Self-display of workers capabilities by entrusting them with greater responsibility and authority * There is continuous fine-tuning of the production process

Toyota Production System (TPS)- link

Toyota has six rules for the effective application of Kanban:

  • Never pass on defective products
  • Take only what is needed
  • Produce the exact quantity required
  • Level the production
  • Fine-tune production
  • Stabilize and rationalize the process

Agile approach of Software development

  • Respond to changes quickly with quality: WIP: Changes are easier to make even after initial planning, Scrum: No change within sprints.
  • Testing in each Iteration/Sprint ensures bugs are caught early
  • [Wrong: Final product slight vary with initial requirements] The final product is completely aligned to the initial requirements - Final product can be very different than originally intended. Welcome changing requirements, even late in development. Final product can be very different: The initial Agile project might not have a definitive
  • [Agile perspective wrong, Waterfall model write] All-at-once delivery ensures that all the requirements that were signed off are delivered

Keywords

Scrum: Velocity, Cross-Functional Team Kanban: Cycle Time, CFD(Cumulative Flow Diagram)

Kanban Principle "Start with what you do now" Start with what you have – the existing process

  • Kanban focusses on only the existing process. Organisations do not need to re-engineer the existing process and maintain a stable status quo

Start with what you are doing now: The Kanban Method (hereafter referred to as just Kanban) strongly emphasizes not making any change to your existing setup/ process right away. Kanban must be applied directly to current workflow. Any changes needed can occur gradually over a period of time at a pace the team is comfortable with.

Kanban

SWIM Lanes:

When there are different typed work items flowing across a Kanban board, the significance and hence the urgency of work items would also vary. Hence it is mandatory for the team to be able to segregate inflowing work items, prioritize it and handle it accordingly inside the Kanban board.

  • Continuous Flow of work. Continuous inFlow of work.

Kanban is useful when incoming work is continuous, teams need to respond extremely quickly to changes and tasks are very dynamically prioritized

  • Respond to changes quickly. There is a need to respond to changes.

Provides lightweight process which aids a support activity

  • Need lightweight process

  • [Not applied] Projects where scope may evolve and teams can expect changes

Kanban is not applicable in the following scenarios:

  • Task completion requires some research work (unknown requirement) or in cases where task effort cannot be estimated
  • Tasks evolve and scope is not defined
  • Too much dependency between tasks
  • If all the items across workstages need to be collated, then only deployed

Kanban Benefits of Implementing

  • Helps in Identification and elimination of bottlenecks
  • Helps in Visualizing the workflow for various kinds of work.

Not Applicable

  • Helps to work in environment where tasks evolve and scope is not defined
  • Helps in environments where the work item is new to the team

Kanban boards

⚠️ **GitHub.com Fallback** ⚠️