Kanban?

[Andy O]

So, I mean to take the time to learn more, but wondering if there are
people here that can help me get a quick hit. I'm an Agile guy.
Mostly XP and Scrum. I get those things. But now there's Lean and
Kanban.

What are these things and how do they differ from Agile/Scrum?

Maybe worth exploring at a meeting?

[Jeff Jensen]

I'll take a swing at Lean. 

It is the application of the Lean Manufacturing methodology (think Toyota and Honda in the '70s and 80s) to software development.  Lean identifies seven types of waste (incomplete work, extra processes, unnecessary inventory or features, waiting, wasted motion, task switching, defects, and management overhead).

These are addressed through amplified learning (fast feedback, iterations, and synchronization); delaying decisions (keep your options open and commit as late as possible), deliver quickly, empower the team, build-in integrity (refactoring, model-driven design, architecture use), and looking at the whole rather than the parts (suboptimization of the whole by over optimizing the parts).

Many of the concepts are similar to what you know, but approached from a different point.

The primer on it is Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.

[Stephen Haberman]

> But now there's Lean and Kanban.
>
> What are these things and how do they differ from Agile/Scrum?

To me the biggest different about kanban is that it is iteration-less.
And, for the more extreme kanban guys, estimate-less. They assertions
is that estimates are wild guesses anyway, so why do it? Just start.

The idea is you can work on, say, 4 things at once (because you have 4
devs or whatever, you adjust the number "4" in response to reality as
you go), so, you pick 4 things and just do those.

Let's say you get 2 done, and want to release, then release, and replace
those 2 with 2 new things the customer wants. Whether its been a week,
a month, or a day, you release-on-demand, basically.

The idea is to reduce task-switching and allow devs/the team to just
focus on one thing at a time until its done.

As a potential con, I think it does up the ante on your build
process--of the 4 things that are "work in progress", you have to be
able to release when only a subset are done. This means either all work
is being done in feature branches (not a big deal, post-1.0, I think) or
else devs have to be disciplined about keeping tests passing and having
"control knobs" in the system that can turn their in-development
features on/off if the feature happens to end up in production before
its ready.

What is also odd is that with kanban you'll actually see waterfall poke
its head back in, where they say "dev can do 8 things at once", and
then "qa can do 4 things at once", but if qa has 4 things on their
plate and is not getting them done in a timely fashion, dev cannot
"pass" their complete things over to qa without an open slot. This
blocks dev from taking new items into their queue and makes it much
more apparent where the bottlenecks/"waste" in the system is. So,
either devs pitch in to help automate qa, or you hire more qa people,
or whatever you need to do reduce the bottleneck/waste.

I haven't done kanban, but that's my take.

- Stephen

[Mike Warren]

This artice is a great introduction to Kanban and Lean thinking,
especially for those with an Agile background and experience in XP and
Scrum:

http://agileproductdesign.com/blog/2009/kanban_over_simplified.html

My take is that Scrum has evolved into a set of practices that can be
implemented fairly easily, even without a full understanding of the
Lean principles they support, which makes it easier for some
individuals and organizations to make the transition to a more Agile
development methodology.

Lean, however, focuses on continuous improvement and requires and
understanding of the principles that XP and Scrum support. Knowing
why a certain practice is recommended can help one see when a process
can be improved, should be eliminated, or left alone. Kanban, in
software development, is a tool that supports process improvement,
while also helping to reinforce agile practices.

For instance, on my team, pair programming is reinforced by the limits
to WIP. The queue limit for WIP is equal to half the team size. This
initially forced pairing, now pairing has become an embraced aspect of
how the team works.

In terms of differences from pure Scrum (an interesting conversation
in itself), Stephen mentions iterations and estimates. An issue I
have with Scrum is that iterations have gotten shorter, and stories
have gotten smaller. Stories no longer represent deployable features,
because they are not achievable in an iteration. Further, concepts
such as Done and Done / Done and other abominiation combinations have
been invented to ensure that teams get "full credit" towards their
velocity.

Given that, it isn't much of a stretch to say that what many people
are calling scrum iterations little resemble Scrum as it was initially
practiced. And that is not necessarily a bad thing in my opinion --
it is an example of applying Lean thinking. Iterations have gotten
shorter and stories smaller because there was perceived value in that
happening. The perceived value is that it is easier to plan shorter
time boxes, and easier to estimate small stories.

However, Lean thinking would produce the following questions: Do
these modifications to how Scrum was practiced improve the production
of value? Do they eliminate waste? Can more waste be eliminated?
These changes to Scrum seem focused on making estimation more
reliable, and that effort implies that there is value in accurate
estimation. But is that really the case? Beyond WAGs upon which to
base a business case, what value does estimation provide? The desire
is to be able to have predictable delivery.

Experience would indicate that estimation is a poor way to achieve
that. Measurement is a far better tool, especially with self-gathering
metrics. Using Kanban, it is a simple matter to simply measure the
lead and cycle times for stories. If the stories are all roughly the
same size, nothing else is needed. If they are not, then doing a
simple pointing session during planning allows lead and cycle times to
be averaged based on points.

Tackling the iteration question, one has to ask what the value is of
having them? They are getting shorter in order to be easier to plan.
They used to be longer to ensure that production quality code was
delivery ready -- in other words, value was produced. Again, the
shorter iterations seem to be an application of Lean thinking. Again,
one has to question if further refinement is possible. Especially
when all of the meetings surrounding iteration planning are taken into
account, such as planning, retrospective, review, pre-planning, story
writing, etc. It is one thing to have these every 4 weeks, but to
have them every 1 or 2?

Getting away from theory now, I will describe Lean/Kanban as it is
currently being practiced on my team. First, I must point out that we
are in the infancy of this process, and constantly seeking ways to
improve it. The two main areas I will discuss are estimation and
iterations. Estimation has become a very lean process for us, and we
have replaced iterations with daily, weekly, and bi-weekly heartbeats,
which I elaborate on here.

Every two weeks we have a team meeting. In the meeting we have
personal check ins on how everyone is doing, a project sanity check
discussion, a short Kaizen / retrospective session (longer if the
answer to the sanity check is negative), review of any defects, story
pointing of any new stories, verification of the priority queue on the
Kanban board, a commitment check on what is planned, and set goals for
the next two weeks. Since we don't do true estimation, we don't go
into story detail during this meeting and don't task out stories.
This meeting is scheduled for 90 minutes every two weeks and we easily
fit everything into that timeframe.

Weekly, we review what is ready to be moved to production and if there
is anything, and the customer is ready to take it, we make a
production push. This is usually a 10-15 minute conversation on
Tuesday, followed by a production push on Thursday if there is a
coherent value set to push.

Daily, we have a stand up meeting along the traditional lines. In
addition, there is a whiteboard with everyone's name on it and what
they have set for their goal for the day. When new stories are
pulled, the team huddles and works out story details. Tasks and
pairings are determined at this time.

Using this approach, the amount of time we spend in meetings has
dropped significantly, face to face real time communications have
increased dramatically, and productivity is high. The huddles and
pairing have reinforced XP practices, involving our QA and BA
resources in every story as the story is worked, resulting in better
tests being created that meet the conditions of satisfaction
established.

For us, these things have not happened over night, and no step along
the way ever felt like a huge departure from Scrum -- just a lot of
small evolutions which we continue to seek.