The Other AGILE

Mac Newbold

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



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


Almost everyone has heard of, used,
and made fun of the Waterfall method

  1. Requirements
  2. Design
  3. Implementation
  4. Verification
  5. 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:

  1. Divide your time into segments (sprints)
  2. Plan a sprint at a time (usually 1-2 weeks)
  3. Build out what you planned
  4. Demonstrate and review
  5. 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

  1. Over production (largest waste)
  2. Time on hand (waiting)
  3. Transportation
  4. Processing itself
  5. Stock at hand
  6. Movement
  7. Making defective products

Many of these have a parallel in software

A Better Way

  1. Consistent process to uncover problems
  2. "Pull" system avoids overproduction
  3. Level out the workload
  4. Stop to fix problems - build in quality
  5. Standardization allows for
    continuous improvement (kaizen)
  6. Visual controls to avoid hidden problems
  7. 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

  1. Builders finish Project A, send to QA
  2. Request a project plan from designers
  3. Start working on Project B

  1. QA tests and deploys Project Z
  2. Requests more work from builders
  3. Starts testing Project A

  1. Designers hand off Project C plan
  2. 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)


Electronic Kanban

Complex Kanban


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.


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


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?

  1. Identify the steps in your process
    (We found a "buffer" step between teams helped)
  2. Make a board (manual or electronic)
  3. Stick your tasks on the board
  4. Keep the board updated (at least daily)
  5. Use the board often (in standups, planning, etc)

It really is about as simple as it sounds...


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.


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


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

  • 6,811