Agile 2009 Day 0: Kanban Bag Stuffing

Spent about 4 hours today packing 1500 conference bags for Agile 2009. Luckily, several guys from the Kanban-Dev mailing list showed up to turn a scene from Modern Times into an unique exercise in Lean production.

I won't explain much about the "Pull" system or queuing theory backing Lean production; rather, I'll just explain what we did.

We had about 1500 bags to pack with more than 25 items each: a lot of flyers, several books (including past volunteer Ahmed Sidky's Becoming Agile), and even some agile hand lotion (wtf, right? But it beats the face creme I got at a triathlon called, I kid you not, "every manjack"). Anyway, it all needed to be bagged, carted, and trolleyed to the reception area. Uff da.

The group split into two teams. Our goal was obviously to get the bags packed as quickly as possible. The Kanban experiment was used to create a system of flow, in which each group had a steady stream of product through their production line. Bottlenecks meant the upstream production unit should slow down and not having work to do meant the upstream unit had to speed up. But it wasn't about working more or working less to achieve flow. It was about tweaking the process so that everyone working hard would result in the flow. The group had to self organize and evolve so that this steady state existed. Over two shifts of people this did all happen to a certain extent. We didn't have measurements to see who was fastest, but each process did improve over time. Here are some observations, along with how they might apply to software teams:

• Having no leader meant that every team member contributed new ideas to process improvement. Does the leader of your software team sometimes stifle innovation?
• Having two teams meant that competition fueled more frequent improvements. What external forces are driving your software team to evolve?
• Having no roles created a system where shouting "We're out of Agile Hand Lotion" meant that the person most capable of grabbing more lotion at that point in time immediately pitched in to do the job. Are the roles in your organization lightweight enough to allow the right person to contribute?
• Having one set of workers out-of-sight (running trolleys through elevators and hotels) meant that it was more difficult for the group to self correct their entire process. Finished bags did pile up and we were at a loss as to how to make the trolley's move faster. What parts of your SDLC are out-of-sight and out-of-mind?
• Not producing a Value Stream Map meant it was difficult to see the whole and fix the real problem, which was slow elevators. VSMs are much lower ceremony than most people realize, and we could have done one. Can your team truly see the whole?
• Many improvements were small and non-obvious in retrospect - "Why don't we pack the books last because they are heaviest?" and "Open the bags more quickly by pulling the handle like this." Does your company have a process group that focuses on the macro view to the exclusion of the micro view?
  

At the end of the day, pro facilitator Jean Tabaka of Collaboration Explained fame hosted our retrospective for us. The format was ORID:

• Objective – Focus on the facts, hard evidence data
• Reflective – Focus on how that made people feel or other associations
• Interpretive – Focus on the impact and significance
• Decisive – Focus on next steps
  

It was a typical retrospective in that we gathered data and created a shared understanding of the event in the Objective phase, talked about our feelings and personal experiences in the Reflective phase, generated insights in the Interpretive phase, and voted with dots in the Decisive phase to create a list of action items for next year. She and the rest of the team did a great job, and both Kanban and the retrospective were superb ways to kick off the volunteer sessions!

And just because I get a kick out of having foreign characters in my posts: 看板 is the symbol for Kanban. Whee!