Kan Ban On The Floor, Kan Ban On The Wall

Below is the core of my presentation for the Southern Fried Agile conference on Oct 23rd. #southernfriedagile.  Here’s the slide deck

It’s funny the way you learn about something in one part of your life that you think you may never use again only to re-discover it later as one of the most important things you ever experienced.  I consider myself lucky because I have a good number of those things. (then again that’s maybe because I’m slow to pick up on why something is important).  In any case, kanban is one of those things for me.

I got my start in Software working with an IT group in the Automotive Industry that built, among other things, shop floor applications for belt and hose manufacturing.
If your eyes glazed over just now, I won’t take it personally.  Belt and hose manufacturing doesn’t exactly excite everyone’s imagination.
BUT–how they are built–specifically how hose assemblies are built–can be VERY exciting.

In all of your cars, there are various hoses–fuel lines, air lines, and oil lines. In most of the cars out on the road, there are rubber hoses clamped to metal tubes bent at all kinds of interesting angles, depending on the make and model of the car they go on.  To build those hose assemblies, lots of little things have to happen.

1. Hose length needs to be cut
2. the hose bend may need to be heat-formed
3. the metal tubing needs to be cut
4. burrs removed and tubing washed
5. metal tubing formed
6. brackets may need to be welded on
7. clamps attached
8. pieces assembled
9. assembly checked for form angle and positions

Take all of that and multiply it times 15 or 20 cells and you get a sense of what a hose assembly plant might be like.  A plant in Easley, SC where I spent quite a bit of time, looked like something out of Indiana Jones.  They made hose assemblies in the steps I listed above. It was dark and dirty and dangerous, and noisy.  No one trusted anyone, and everyone was racing each other to get their  own pile of work done.  Production managers would come in and tell everyone they needed to switch to work on a new part number, and all of that half finished work would just be piled up in a standby WIP area.  Sometimes to be lost forever.

All of that material in all of those dark corners was the same as cash being burned.

The plant was about to go under when they brought in a kaizen team to work on a more lean approach with continuous improvement.–specifically, to use kanban to improve the work cell throughput.  Kanban–a visual card system that is used to help highlight where problems are occurring. 
This was for a group of people who didn’t even say hello to one another in the morning out of sheer hatred.  How in the heck were they going to respond to a system pointing out there problems–let alone pull together as a team to fix those problems?

Very long story short, I was pulled away for a few months to work in another plant on another project, and when I was sent back to help the Easley plant with a new “spin” on their kanban project, I was certain it was going to be an unmitigated disaster.

What happened changed me and the way I look at people. At first, I thought that the plant was being closed—there was so much space and light and so little
shouting. “They must have fired all of the people who were fighting” I thought.
But they were all there—and they were all getting along.  At shift change they would do a DAILY retrospective.  So switching to kanban helped them realize they needed to be doing the following:

• Pulling work rather than pushing it
• Setting WIP limits –adjusting daily based on retrospectives
• Holding Daily shift-change standups to provide transparency
• Encouraging Cross functional abilities within the team
• Focusing on throughput of finished good instilled a sense of team accomplishment.

Those changes in turn reaped the  following benefits:

• Completed work steadily flowing out the door
• No more half finished work piling up
• Predictable throughput cycles for each finished good
• Cross functional team members
• no single points of failure
• Better knowledge of how to FIX the pain points
• Clear view on exactly where work is bottle-necking
• A team dynamic healthy enough to resolve the bottlenecks immediately.
• A clear view of upcoming work for Everyone’s consumption
• Cleaner workspaces and safer, better operating equipment

Thank you www.barnorama.com

It turns out that humans are actually good to one another. Who knew?  Given the opportunity to find harmony, they will grasp it. To borrow from Abraham Lincoln, if you can appeal to the better angels of people’s nature, they will do the right thing. How cool is that?

Fast forward over years of struggling with waterfall project management and more years working with teams in various forms of Agile and I found myself working with software teams with varying understandings of the concepts of kanban.  It seems that many have grabbed the Lean software development concepts of Mary and Tom Poppendieck but taken too lightly the fact that it is hard work that requires continuous steps towards improvement.  “We switched to kanban, now we’re better; therefore, Kanban is the answer”  Or even worse: “We switched to kanban, but we didn’t get better; therefore, Kanban is stupid.”
 
What I am suggesting is this.  Kanban, as a framework, has many applications,
but we need to keep sight of its original intent–to help us diagnose problems quickly.  The very nature of its structure is to pin point problems.  Yes, that means we have to impose WIP limits so that the problems can be spotted and addressed.

What I’m also suggesting is that we reexamine the tendency to look to kanban as a long term solution–as a newly adopted methodology–but instead plan on using it for the short term.

The very act of switching to kanban requires that the team

• sit down and have conversations about “exit criteria” for each of the areas
• work out any and all ways they can be more cross-functional
• seriously analyze (and for many, for the first time) what their process flow stages look like
• clearly define as a team what their definition of done is.

and all of that before they even get started!

Once a team starts actually using a kanban board with WIP limits and all of the structures I’ve mentioned above, the team will also be forced to
acknowledge and fix their weaknesses as a team.  The cognitive dissonance included in that simple act–regularly acknowledging your weakness as a group and then acting upon a solution arrived at as a group–cannot help but build your team’s strength and health.

There’s much more to this discussion, and I’ll be talking about that at Southern Fried Agile on Oct 23rd, but the points I get to for teams using kanban for software development as follows:

kanban software development has its sweet spots:

• Large backlog of individual enhancements or bugs
• Team members whose capacity is 100% predictable
• Backlog items are independent minimal marketable features (wait, shouldn’t all backlog items be IMMFs?)
• Management willing to allow time for team throughput data to be collected–for predictability calculations
• Mature team already experienced with agile.

and kanban software development has its not-so-sweet spots:

• “We need delivery dates right now.”
• Partially dedicated team working “when available.”
• Stories with intra-board or off-board dependencies 
• No WIP limits to help you spot bottlenecks
• Pushing work rather than allowing it to be pulled
• Team too immature to handle conflict (therefore resolution)
• The thing that made the Easley team so hard to deal with actually made them a more mature team–they knew how to speak their minds.

So here are some good ideas for a successful use of kanban:

• Conscientious use of WIP limits
• Daily kanban board standups
• Weekly backlog refinement—focus on true MMF
• Demo every (typical) sprint duration–e.g two weeks
• Retrospect every (typical) sprint duration–e.g. two weeks
• Regular “release train”
• Continuous improvement until you no longer need the board

and here are some ideas you’ll need to stress at a Business level:

• Cross-discipline governance board for Business Value prioritization
• Kanban board “radiator” for full visibility
• Frequent and predictable “release train”
• Demo every (typical) sprint duration
• Regular “release train” communicated to everyone
• Respect your teams integrity–

So that is how kanban was something I learned about in one part of my life and  thought I would never use again only to re-discover it later as one of the most important things  I have ever experienced.

Thank you www.deviantart.com