Kanban overview

Kanban

Introductions

Connie Barton – TD Ameritrade Dan Carroll – Microsoft Julie Weitzel – Ascend One

Agenda

One company’s adaptation from Scrum to Kanban Our Challenges What is Kanban? Setting up Kanban Board Scrumban

Time-boxed iterative development has challenges

Common problems include:Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smallerSmaller development items are often too small to be valuable and difficult to identifyQuality of requirements suffers as analysts rush to prepare for upcoming cyclesQuality of current development suffers when busy analysts are unable to inspect software or answer questions during developmentQuality often suffers as testers race to complete work late in the development time-box

What is Kanban?

kan·ban [kɑhn-bɑhn]

看板 – Kanban literally means “visual card,” “signboard,” or “billboard”

Developed more than 20 years ago, by Mr. Taiichi Ohno, a vice president of ToyotaA method of inventory control, originally developed in Japanese automobile factories, that keeps inventories low by scheduling needed goods and equipment to arrive a short time before a production run beginsA visual signal that’s used to trigger an actionA simple-to-operate control systemFits nicely into an Agile SDLC

Properties of Kanban

Visualize what you do today Limit the amount of work in progress Improve flow Pull not push Request In, Value Out Minimal Marketable Feature

Kanban Board

Setup Kanban Board

Need to identify Team Goals Need to identify limit for On Deck Need to identify limit for each phase Move highest priority stories onto On Deck Setup TFS for workflow And Go!

Lead Time vs. Cycle Time

Lead Time Starts when story goes On Deck Ends when story is Released to Production

Cycle Time Starts when story goes into Analysis Ends when story moves into QA Done

Customized to our teams

Kanban Board

Kanban Board

Analysis Phase1. Cycle Time starts2. Number of stories in this phase is limited3. Team member will pull from On Deck when work is needed

Kanban Board


Development Phase1. Number of stories in this phase is limited2.Team member will pull from Analysis Done when work is needed3.Development tasks with hours are created

Kanban Board



QA Phase1.Number of stories in this phase is limited2.Team member will pull from Dev. Done when work is needed3.QA tasks with hours are created4.Cycle time ends when story leaves QA

Kanban Board



QA Phase1.Number of stories in this phase is limited2.Team member will pull from Dev. Done when work is needed3.QA tasks with hours are created4.Cycle time ends when story leaves QA

Ready to Deploy Phase1.No limits 2.Team will decide when to release stories in RTD3.Proposed 2-week release schedule

Work In Progress (WIP) & Limits

The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritization (i.e. having things sitting in the queue for too long before they are begun).

WIP limits are designed to reduce multi-tasking, maximize throughput, and enhance teamwork.


To improve cycle time there are two options: reduce the number of things in process improve the average completion rate

By having fewer work items in progress, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork


Limiting WIP like this can seem unusual for teams, and there is often a worry that team members will be idle because they have no work to do, but are unable to pull any new work. The following guidelines can be useful to help in this situation: Can you help progress an existing story? Work on that. Don’t have the right skills? Find the bottleneck and work to

release it. Don’t have the right skills? Pull in work from the queue. Can’t start anything in the queue? Is there any lower priority to

start investigating? There is nothing lower priority? Find other interesting work.

Scrumban

Team will decide when to release stories in RTD

Proposed 2-week release schedule Conduct daily stand-ups Retrospectives conducted on an as need

basis, minimum of one per month

Remains The Same

Product Backlog Business Prioritization of Product Backlog Release Definition of Done Demo Retrospective

Daily Standup

Identify bottlenecks – Congestion or gaps? Blocker not handled? Working within process limits? Are priorities clear? Did yesterday? Plan for today? Post-standup

Update charts Remove done items

Backlog Grooming / Estimating / Planning

Planning, Grooming, and Estimating occur at the same time

Planning occurs when On Deck phase has a few stories left

The team will groom the new stories as added to On Deck

Estimating will consist new size chart: Small / Medium / Large (<4 week Cycle Time)

Bugs/Defects

Bugs found in Staging environment during testing of a story in QA Phase Work type item “Bug” will be created in TFS and

linked to a story The Bug will go to ‘On Deck’ and Assigned To

story developer; story remains in QA phase QA can continue testing or work on another story

Developer will pull Bug into Analysis or Development phase when ready to take in work

Bugs/Defects (cont.)

The Bug will flow through the workflow similar to a story On Deck > Analysis > Analysis Done >

Development > Development Done > QA > QA Done > Closed

Bug will not go to “Ready to Deploy” or “Released”

Production Bugs A story will be created and prioritized

Implementation

Team Foundation Server Process Template Based on http://techdayskanban.codeplex.com/

by Adam Gilmore User Story and Bug customizations with

workflow Separate customizations for each Team

Project. MVC3 KanBan Board website Excel Reports

Other Guidance

VS ALM Rangers Practical KanBan Guidance http://vsarkanbanguide.codeplex.com/

Closing

Questions?

Thank you!

Kanban overview

Documents

Transcript of Kanban overview