Kanban:
The Other AGILE
Mac Newbold
Vivint
OpenWest, May 4, 2013
THe Plan
Software Development Methodologies
A Quick Look at Agile Scrum
Intro to Kanban
Why Kanban might be a good fit for you
How to implement Kanban in your team
Conclusions/Questions
methodologies
Methodology: a label for a process
that is used to develop software
Traditionally, there have been some common
methods, despite well-known flaws
There are a lot of different ways
that are more popular now
and offer better alternatives
Waterfall
Almost everyone has heard of, used,
and made fun of the Waterfall method
-
Requirements
- Design
- Implementation
- Verification
- Maintenance
Waterfall is a very linear approach
Iterative methods
A variety of methods use iterative principles,
including Agile methodologies
Instead of one big Waterfall for the whole
project, they sometimes use a series of
smaller Waterfalls
This resolves some of the Waterfall issues,
but not all of them
Agile Development
Closely related to both "iterative" and "chaos" models
Scrum is the most popular variant:
-
Divide your time into segments (sprints)
- Plan a sprint at a time (usually 1-2 weeks)
- Build out what you planned
- Demonstrate and review
- Repeat
Usually leads to productive sprints, but in the
big picture, there's a penalty for avoiding
long-range planning and analysis
Planning Conundrums
A major sticking point for a lot of models is
how much planning to do when
When you under-plan, you end up building before
you have a stable specification, and then usually
rebuilding a lot as new information is available
When you over-plan, you can delay implementation,
sometimes leaving a whole team idle, while debating
minutiae that could more quickly be resolved with
a working prototype of the software
There is no clear answer on what to do...
Lean Manufacturing
Let's sidestep into the world of manufacturing,
and specifically the way cars are built
Different from software, besides time and effort,
you also have material costs, so reworking can
get very expensive, so "do it right the first time"
becomes very important
Toyota for decades has been honing the
Toyota Production System (TPS)
It has some important lessons that help us
in the software world as well
Eliminating Waste
TPS focuses on doing things efficiently
by reducing inconsistency and waste
- Over production (largest waste)
- Time on hand (waiting)
- Transportation
- Processing itself
- Stock at hand
- Movement
- Making defective products
Many of these have a parallel in software
A Better Way
- Consistent process to uncover problems
- "Pull" system avoids overproduction
- Level out the workload
- Stop to fix problems - build in quality
- Standardization allows for
continuous improvement (kaizen) - Visual controls to avoid hidden problems
- Understand issues by "going to see
for yourself"
Kanban is the heart of #2, #3, and #6
and relies on #1, #4, and #5
So what is Kanban?
Toyota implemented a visual control for
their production line called Kanban
At each station in the assembly line, kanban cards
are used for requesting more units of work
Send a card to the prior station to request more
They return the card with what you requested
Fixed number of cards in use
Cards always readily visible to everyone
Simple elegance
Let's look at some of the things this gives us:
Just-in-time production: Prior step only builds
as much as you need, when you need it
Level flow of demand: If we process 3 units per
week, the team before and after us will be
sending and receiving 3 units per week too
Low inventory: No buildups of materials because
we only have 6 cards in circulation
Status is obvious: everyone can see the cards
Kanban for Software
Following those key principles, let's apply this:
We have a number of stages in our workflow
(Requirements, analysis, design, implementation,
code review, testing/QA, and deployment)
Imagine that is 3 teams (R/A/D, I/CR, QA/D)
Excess "inventory" at any stage is bad:
backlog of plans/designs go stale,
backlog in review/QA makes repairs harder,
backlog of undeployed work complicates everything
How it works
Imagine each team is already working on
planning, building, or testing something
-
Builders finish Project A, send to QA
-
Request a project plan from designers
-
Start working on Project B
- QA tests and deploys Project Z
- Requests more work from builders
- Starts testing Project A
- Designers hand off Project C plan
- Start planning Project D
Visual Controls
A centerpiece of Kanban for software is the
"Kanban Board"
Homebrew version: sticky notes on a whiteboard
A sticky note for each task/work unit
Columns on the board for each process step
Each team's job is to get their work from
their "todo" column (A) to their "done" column (C)
with current work in their "in progress" column (B)
Example
Electronic Kanban
Complex Kanban
Swimlanes
An optional part of your kanban board is
a thing called "swimlanes" (basically, rows)
Many different ways to do swimlanes,
but the most common seem to be:
- Who is assigned/working on the task
- Priority of the task ("Expedite" lane)
- Project (if your board has multiple)
Electronic kanban boards often have
expand/collapse features that help
Color Coding
You probably noticed how colorful most
of the kanban examples were...
Card color is another great way to convey
additional useful information at a glance
Color code by:
- Bug/Feature/Enhancement/Todo
- Priority
- Customer/Client/Project
- Whatever floats your boat
Totally optional, but extremely helpful
Manual vs Electronic
Both methods are entirely valid, and different
teams have different needs/preferences
Manual can be easier to get started with,
especially if you already have a wall or
whiteboard, and a stack of sticky notes
Electronic is usually a lot easier to change,
and can be automated more easily, and
guide you through the process (enforce rules),
but usually it isn't easy to switch from one
tool to another. For us, integration with our
task tracker was a super-important feature.
Checkpoint
Any questions about:
- What Kanban is?
- How Kanban works?
What kanban offers
Let's talk about some of the benefits:
Visibility: Everyone can see the status of any
work item very clearly at any time
Backlog management: Finite space on your
board limits work in progress
Flow: By limiting work in progress, we
can increase flow across the board
Flexibility: more on this in a moment...
Kanban vs scrum
Both Kanban and Scrum are Agile methods
Scrum focuses on sprints, and has a lot of rules
Kanban focuses on continuous flow, with few rules
Scrum requires things like potentially releasable
software at the end of every sprint
Kanban doesn't
In short, Kanban is a lot more flexible
but with many of the same benefits
When Kanban Fits
When our team dove into Agile, we picked Scrum,
figuring if it's so popular there must be a reason
In our first year of Scrum, we found problems:
- Most of our projects were either too short
or too long to fit in a sprint nicely
- Our planning and reviews didn't match up with
our project size, so were less effective - In our environment, things changed rapidly,
so each sprint ended up being 50% what we
planned and 50% new urgent stuff - Lots of meetings that weren't really having a
significant positive impact
Kanban to the rescue
We stumbled on Kanban almost by accident,
as we were switching to a new task tracking system,
and it has been a good fit for us
"Emergencies" all use the system rather than
having to go around it or throw it off
No more attempts to tell customers that we
won't start on their request for two weeks
Visibility and ease of use has helped our flow
Design, dev, and QA stay busy but not too much
Planning
A quick side note about finding the right balance
with how much to plan ahead vs jump into prototyping
We've found that nailing down the plan
for each unit of work before we start has:
- Dramatically reduced re-work
- Made development faster
- Improved customer satisfaction
- Reduced issues found in QA
- Shortened our cycle time
(Your mileage may vary)
Implementing Kanban
So if any of this sounds interesting,
how do you get started?
- Identify the steps in your process
(We found a "buffer" step between teams helped) - Make a board (manual or electronic)
- Stick your tasks on the board
- Keep the board updated (at least daily)
- Use the board often (in standups, planning, etc)
It really is about as simple as it sounds...
Considerations
Take some time with your team to
consider some of the following:
- Manual or electronic?
- Board placement/visibility
- What columns/steps fit our process?
- Do we want an "expedite" fast lane?
- How do we want to color code?
- Swimlanes? Based on what?
- How do we show who is working on what?
- What is our item limit in each column?
Care and Feeding
Now you have a Kanban board,
how do you take care of it?
First and foremost, Use it. Daily. Constantly.
An updated Kanban is a happy Kanban.
Second, invite it to your daily standups.
Nobody likes to be left out, and Kanban
will add valuable input to your conversations.
Third, celebrate with your Kanban.
Everyone should get satisfaction from moving
their items across the board, and getting stuff done.
Hurdles
What problems would you expect if you tried this
with your team in your environment next week?
We found that it doesn't take long for people
to get used to the system and embrace it
Questions?
Hopefully we have shown what Kanban is,
why you might want to try it,
and how you'd go about doing that
Anything we missed?
Thanks for coming!
@macnewbold / mac@macnewbold.com
kanban the other agile
By Mac Newbold
kanban the other agile
While many people have heard of Agile, and most of those have heard of Scrum, there's another Agile methodology called Kanban that might be a better fit for your team. Kanban has its roots in lean manufacturing, specifically the Toyota Production System, where it plays a key role in reducing the inventory of work-in-progress in just-in-time manufacturing. In agile software development, it's a very flexible alternative to Scrum with fewer rules and a focus on improving throughput and quality. From OpenWest Conference, May 2013. See also http://www.youtube.com/watch?v=vHFYzpiaWYU
