I: How I started to use Scrum
II: Scrum, but
III: Moving away from Scrum
In Part I we looked at how I got
into Agile and Scrum. In Part II we explored how Scrum failed to be flexible enough
to fit into my unique process. In Part III we took a look at how I got introduced
to Kanban, without even knowing it. Today we’ll take a quick look at what Kanban is.
a Japanese word that loosely translated means “signal card.” Kanban’s
underlying thesis is that by using signal cards at various points in the production
process to indicate the amount of work completed, you can limit the amount of work
in progress (WIP) and thus keep the system very “lean” and agile. Work in Progress
(WIP) represents inventory and inventory is expensive to keep.
Kanban was originally developed
at Toyota as part of the
Lean manufacturing movement
to facilitate pull systems in a just in time (JIT) production manufacturing process.
Work is pulled through the system in single units by demand, instead of pushed in
batches. Think Dell computer’s JIT assembly of your laptop as you order it; Dell is
pulling a single unit through its production process on demand as opposed to pushing
through a batch of computers and selling them pre-configured.
Over the past few years there have
been several blogs and books describing a Kanban process as an agile methodology for
software development. There are far more robust
explanations of Kanban out
there on the Internet, so I will not try to outdo them here, however, let me give
a brief overview and then circle back to the system I described in Part III.
a development methodology, Kanban is an
evolutionary process that focuses on the flow of work in progress. Individual
items of near equal size are pulled on demand through the system. Kanban focus on
the flow of the work, trying to make constant improvements to the flow. This
increases the predictability of the system. Evolutionary by nature, Kanban is designed
to facilitate continuous learning and improvement to the process (the Japanese call
this kaizen ). Kanban teams
usually put up a “Kanban Board” where they have the process states as columns and
sticky notes representing the queue or work items and where they are in the production
cycle. This visualizes the production system and allows you to spot areas for improvement.
The Kanban board is the most important
item in the system, it represents the production flow. As an item moves from “design”
to “development” to “test” and off the board to production, you can get a holistic
view of the process and identify bottlenecks. Kanban has a daily standup meeting,
not to focus on “what you have done today” since that is obvious via the Kanban board,
but rather to focus on the production process and talk about bottlenecks and how to
improve them. For example if you have way too many items queued up in the “tester”
queue, you can make changes to the way the work flows through the system (or identify
that you need more testers.)
Kanban throws away the concept
of a sprint and even estimation to a lesser degree. Stories are larger in length
and scope but you have less of them in your system. If you break down tasks into digestible
units of comparable size, by looking at the Kanban board, you know how long it typically
takes to get tasks done. The goal of
Kanban is to keep the work in progress as small as possible, at the exact flow rate
that the team can handle. The team will
commit to deliver work items at the flow rate, and expedite important work items. As
time progresses and the team improves, the flow rates can be adjusted.
Sound familiar? This is the system
I stumbled across at my start-up defined in Part III (minus the Kanban board.) If
I had a Kanban board I would have had all of the states (analysis and rules complete,
in progress, etc) on top and had sticky
note for each task (the RegEx work) in the workflow and where it was in the process.
Since our tasks typically only took half a day and moved from start to finish off
the board in about 48 hours and we had a remote team, it would have made sense to
have an electronic board. Nonetheless, our quazi-Kanban system limited work in progress,
allowed the developers to pull work out of the queue in a very predictable pattern,
and produced quality results. The most important part is that the system was flexible.
Since we started as a Scrum process
and evolved to a more lean manufacturing influenced production system, I learned that
no single development process (such as Scrum) is a “silver bullet”. I
also realized that all of the “features” of Agile are available to you and you can
mix and match them-as long as you adhere to the Agile values put forth in the Agile
manifesto. More on this later in the
last part of this series.
Stephen Forte sits on the board of several start-ups including Triton Works. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press).