KANBAN

Scott VandenElzenScott.VandenElzen@LoanSifter.com

Credits• Kniberg, Henrik (2009), “Kanban vs Scrum” http://

www.crisp.se/gratis-material-och-guider/kanban

MethodologiesWhat is a software development methodology and why do we care?

An Software Development Lifecycle (SDLC) methodology is an organized way of designing, developing, & deploying software that allows you to build a quality product in a repeatable fashion.

MethodologiesAn SDLC is both a set of tools, artifacts and work practices an organization uses to create software

AND

It’s the workflow process within an organization to get the requirements gathered, the software built, the testing done, and the bugs fixed.

Examples - Agile, Scrum, Kanban, Waterfall, Rupp, TSP, TDD, Spiral, SSADM, Rad, Lean, Crystal, XP, and more!

Scrum in a nutshellSplit your organization into small, cross-functional, self-organizing teams.

Scrum in a nutshellSplit your work into a list of small concrete deliverables. Sort the list by priority and estimate the relative effort of each item.

Scrum in a nutshellSplit time into short fixed-length iterations (usually 2-4 weeks), with potentially shippable software demonstrated after each iteration.

Scrum in a nutshellOptimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.

Optimize the process by having a retrospective after each iteration.

So… instead of a large group spending a long time building a big thing you have a small team spending a short time building a small thing repeatedly.

Kanban in a nutshellSplit the work into pieces - write each item on a card and put it on the wall

Use named columns to illustrate where each item is in the workflow

Kanban in a nutshellLimit Work In Progress – assign an explicit limit to how many items can be in each workflow state

Measure the cycle time - the amount of time it takes an item to flow through. Optimize the process to make this lead time as small and predictable as possible. Implicit in this – keep the work items small

(very brief) Kanban BackgroundKanban, the Japanese word for “signboard’ has become synonymous with demand scheduling.

“Toyota created Kanban in the early 40s and 50s to help control production processes and implement Just in Time (JIT) in their Toyota manufacturing plants in Japan. By using kanbans, they reduced WIP between processes and the associated cost of extra inventory” (Gross, 2003).

This aligns with lean manufacturing and development closely through elimination of waste/time wasted AND increase in efficiency.

Which should I use?Sounds like a great thesis idea!

Which should I use?There are frameworks for evaluating which SDLC might fit best for an organization that take into account complexity, uncertainty, quality criteria and the weight / importance of each phase of the product lifecycle.

CuQuP -- Yusof, Shukur, & Abdullah

Which should I use?It Depends!

You should use the tool (or SDLC in this case) that fits the job and organization. Remember no tool is perfect.

Which should I use?

There is a range of formality even among “agile” methodologies.

Which should I use?“Remember no tool is perfect” – But you can add stuff!

Just because Kanban doesn’t have a product owner doesn’t mean you can’t add one to your process. In any methodology you can add whatever roles or ceremonies your organization needs.

Common Trap – we sent developers to scrum training and when they came back they discovered we had extra steps in our workflow. I heard “But that’s not Scrum” – my feedback “SO WHAT! It works for us.”

Compare/Contrast• Scrum prescribes roles• Scrum prescribes timeboxed iterations• Kanban limits WIP per workflow state, Scrum limits WIP

per iteration• Both need fine tuning

• Who should be on the team• How long between releases• How big should my WIP be in each state

• Scrum board is reset between each iteration• Scrum prescribes cross-functional teams• Scrum backlog items must fit in a sprint• Others…

Compare/ContrastBoth are Lean & Agile• Scrum and Kanban are pull scheduling systems. This

means the team chooses when and how much work to commit to, they “pull” work when they are ready, rather than having it “pushed” in from the outside.

• Scrum and Kanban are based upon continuous and empirical process optimization, which corresponds to the Kaizen principle of Lean.

• Scrum and Kanban emphasize responding to change over following a plan.

Kanban

Can I use more than one?YES!

At Visonex they use Scrum for our standard product development. They do 6 sprints 2 week sprints per quarter and released quarterly. The quarterly release dates are planned a year and advance so the team and the clients know when updates are coming.

They have a 2 scrum teams of 8 developers and testers that works together for the quarter.

AND…

Can I use more than one?They use Kanban for our maintenance work that is released every 2 weeks.

2 developers work the maintenance queue along with a part time tester.

The advantage: standard work continues un-interrupted and released on schedule. Bug fixes can be pushed out without interrupting the flow.

Kanban in practiceVisonex runs 2 or 3 scrum teams. Sprints start/stop every 2 weeks. They run a Kanban queue with 1 or 2 developers. The Kanban has an express lane for critical stuff. If something is in the critical lane, other work is paused.

Kanban in practice• Their board limits the WIP to 2 items in development and

2 in test per developer. A developer might “jump over” to test the other developers work if a testing resource isn’t available to keep things flowing.

• 2 week releases are planned a year in advance• Stakeholders (development, support, operations) meet

weekly to prioritize the backlog. They set the top 10 items each week. Business analysis makes sure these items are ready for development.

• Business analysis keeps the backlog prioritized so the developers just need to ask for the next item.

Kanban in practice• Critical items can come in and the work in the regular

board stops until the critical item is deployed.• Right before the release, all work is rolled up in a final

deployment test, tested, and then the package is released.

• They rotate the developers who work the maintenance queue quarterly so everyone has a chance. It’s a good training opportunity.

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boardsThere are other boards for other teams:• System Administration• Operations • First & Second tier support• Marketing• Sales

http://dl.dropbox.com/u/1638038/publikationer/10%20kanban%20boards%20and%20their%20context/10%20different%20kanban%20boards%20and%20their%20context%20-%20mskarin.pdf

Other resourcesCrisp consulting resource pagehttp://www.crisp.se/gratis-material-och-guider/kanban

Crisp’s Bloghttp://blog.crisp.se/tag/kanban

Cartoon - Henrikhttp://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

Book - David Anderson – Kanbanhttp://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402/ref=sr_1_1?ie=UTF8&qid=1293750801&sr=8-1