KANBAN
Scott VandenElzen
[email protected]
Credits
• Kniberg, Henrik (2009), “Kanban vs Scrum”
http://www.crisp.se/gratis-material-och-guider/kanban
Methodologies
What 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.
Methodologies
An 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 nutshell
Split your organization into small, cross-functional, selforganizing teams.
Scrum in a nutshell
Split 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 nutshell
Split time into short fixed-length iterations (usually 2-4
weeks), with potentially shippable software demonstrated
after each iteration.
Scrum in a nutshell
Optimize 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 nutshell
Split 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 nutshell
Limit 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 Background
Kanban, 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/Contrast
Both 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 practice
Visonex 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 boards
There are other boards for other teams:
• System Administration
• Operations
• First & Second tier support
• Marketing
• Sales
http://dl.dropbox.com/u/1638038/publikationer/10%20kanb
an%20boards%20and%20their%20context/10%20different
%20kanban%20boards%20and%20their%20context%20%20mskarin.pdf
Other resources
Crisp consulting resource page
http://www.crisp.se/gratis-material-och-guider/kanban
Crisp’s Blog
http://blog.crisp.se/tag/kanban
Cartoon - Henrik
http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
Book - David Anderson – Kanban
http://www.amazon.com/Kanban-David-JAnderson/dp/0984521402/ref=sr_1_1?ie=UTF8&qid=129375080
1&sr=8-1