Kanban Paper Airplane Factory

i went to the local capital kanban meetup yesterday evening. it was a bunch of project managers discussing kanban and waste in it. seemed completely out of my comfort zone and a way to meet new people in tech here in town so i attended. it turned out to be really cool and way more interesting than my expectations were. i wanted to mention some of those here, specifically some of the it wastes that were mentioned i see all the time, the insights i got from the paper airplane factory game, and some after meeting talk that changed my perspective on what i perceive as problems in our industry with good software east of california (hah, trick question, there is no good software done east of california…).

it wastes

andrea ross did a presentation about waste in it. kanban, the production process used by toyota then turned into a project management and software development, has 7 or 8 forms of what it calls waste. these are primarely in the factory line production process, so you have to draw your own metaphors and similes, and that’s what andrea’s presentation extrapolated on.

from a high level, these are:

• defects / rework
• overproduction
• waiting
• non-standard over processing
• transportation / logistics
• intellect
• motion
• excess inventory

her slides that have bullet point examples for each one are pretty self-explanatory. what was interesting to me was the sheer volume of bullet points i see all the time, together, in the same projects i work on. some can’t be avoided, nature of the business and all that. still, it was pretty eye opening to see that a traditional factory production process has identified these items as the core waste items, and software development has plenty of them with just about the same meanings. i won’t cover them in detail here as her slides do.

kanban, bottlenecks, and waste

the concept of kanban is to quickly identify bottlenecks in the existing production process, and iterate to improve the process to fix them.

notice i said “existing” and “process”. the existing part is where kanban has been easier to market than say six sigma which is bought into wholesale, hence why it’s easier to be a six sigma consultant than a kanban one. kanban you basically overlay on top of what you have and it surfaces the problems your existing process has pretty clearly. meaning, if you see a bunch of cards on a kanban board that are in the “analysis” column, and very few in the rest, it’s pretty clear where the bottle neck is located.

now the “process” part is analogous to the production line; in this case all that goes into making software from the traditional waterfall perspective: design, development, deployment. however, the key here is you aren’t fixing the “bottleneck”, but rather the process itself. that is what i learned through our paper airplane factory exercise quite clearly. there are a series of games like this that can be modified, but the point is they help teach the bottleneck vs. process modification process extremely clearly.

the key takeaway for me was fixing the bottleneck, like the 5 developers + 1 manager in a war room during a troubling moment during a software project, is actually a form of waste. yes, it’s great teams rise up to tackle these problems in the moment. however, it’s important to note that it’s the project manager’s job to both recognize this as waste and fix the actual process problem. i’ll explain this below.

note: if you’re concerned about spoilers, please be aware of 2 things. first, there are more than just the airplane factory game that you can find online. second, if you do read the following section and later participate in the exercise, please either let the teacher/presenter know, or try not to modify the process too much to allow others to learn.

airplane factory

the game is like so (abridged version, you can find the full instructions here ):

1. divide your people into 4 groups, each sitting adjacent to each other. circle or semi-circular seating arrangements works best to encourage intentional bottleneck adjustment engagement.
2. cut up the airplane folding instructions alone the designated lines.
3. give the first part of the instructions to the first group in the line. give the second part of the instructions to the second group, and repeat on down the line. some people may not necessarily have designated jobs beyond passing papers, etc. this is intentional to illustrate the intellect waste of not using human ip… and also to note how they’ll often become efficient passers, helpers, or even qa.
4. ensure the group/person who’s last in line is aware of how far the plane must fly as a metric of defining a successful plane.
5. setup a 5 minute timer, start it, and yell “go!”
6. after 5 minutes, identify how many successfully flown airplanes were made as well as how much waste (crumpled papers, non-flying planes, etc) were created. that’s the round 1 score.
7. iterate.

the iterate step is where you reflect on what just happened and attempt to modify the process. i’ll go over how ours went down so you get an idea.

round 1

line setup : we had 8 people in our line. round 1, we had 1 lady do the half fold, the 2nd guy do the additional 2 folds + paper sides cut, andrea and i pass the paper to our left, another lady handle the 1st wing folds, and a gentleman at the end to make the wings and throw it. our last person was a lady who handled qa and scoring.

process : very quickly we had a bottleneck with the lady at my stations left. the instructions weren’t very clear and she struggled to learn how to do the first one. both andrea and i quickly went to help; andrea attempting to do it with her, me taking a picture of the instructions with my iphone, and attempting to duplicate at my desk while ensuring i kept passing the planes to my left into an ever growing pile.

once i figured it out (i had actually built the exact same plane last week for my daughters birthday present which has an electronic propeller you attach), i told the ladies to ignore the “requirements” as they were crap and i walked them through how to successfully complete their step. i then quickly returned to my desk which had a pile of unmoved inventory.

the only person who didn’t struggle with their assembly was the 1st in the line who had to fold paper in half.

i believe we ended up with 2 planes and 1 waste.

takeaway : our teacher quickly pointed how we went “downstream” to fix the production line process. this is a reactionary, and completely normal mode, to fix production line problems. it’s also wrong. you’re supposed to identify the upstream problem causing it and fix that. additionally, we didn’t stop the line to ensure we fixed this problem first before continuing, also wrong. car companies like toyota do this via a chain that’s pulled to stop the line so they can ensure the problem is resolved. sometimes they even take part of their line off the main line to ensure things keep moving.

as a side note, apparently gm used to keep going. door doesn’t fit right? keep going; jam the mofo on there. they’d end up with a lot full of cars pretty quickly… even if they were low quality. ford was similar, but they’d ensure the cars were actually sold first before they sold them, thus not resulting in lots full of inventory they couldn’t sell like gm… even if the quality of pre-sold cars was still low.

we also noted various other problems such as no training in each plane’s building instructions, no one stopping if the station after them go overwhelmed with their ever growing stack, and sometimes idle resources (people with not much to do).

round 2

improvements : first, the teacher actually implemented designated stack areas with a piece of paper on each station, and then wrote a number on the paper; this was the max amount of completed planes you could place for the next station to build so you didn’t exacerbate a bottleneck.

second, i become a designated passer to my left while my partner moved to the left station to have a 2 women team doing the complicated folding.

process : my job was pretty easy; pass, and ensure i don’t bottleneck it. every single station was faster since they had practiced their portion. the guy to my right had actually done his first 3 paper cuts wrong in round 1 which caused confusion to my left station, but had it down pat in round 2. the last station still experimented with various angles of folding to see how far the plane could actually fly. we actually had the last women in the line, qa, send a messed up plane back through the line as an unfolded piece of paper because it didn’t fly right; w00t, less waste!

a bottleneck, again, formed to my left, but the girls found a way to divide up the 2 step process between them to be more efficient. as our 5 minutes progressed, they got faster and eventually started making progress on the backlog.

we made 5 planes, 1 waste.

takeaway : we built 4 planes with 1 waste. the first person, as usual, was too fast. the guy to my right had an inefficient process because he’d have to fold, pick up the scissors, cut, then put ‘em down again. we had all abandoned our airplane instructions by this point.

round 3

improvements : everything else was fine, so we decided to give me the cutting job and the guy to my right would just fold. the girls to my left on-the-fly modification was good and we kept it.

process : my first 3 were slow, but once i practiced, i was uber fast and we were humming. the girls to my left were killing it. i managed to keep my right stack always below or at 2 in the pile. very quickly it became apparent the 1st person was too fast; she was constantly folding and then waiting before she was allowed to make another.

we made 8 airplanes, no waste.

takeaway : those of with spouses were already getting texted like mad to leave, but we all wanted to see round 3 succeed better than 2, and see if we made the process perfect. we didn’t; it went the complete opposite direction to the front of the line needing minor modifications. overall, though, our output increased a lot, our waste went down, and it was very clear that the adjustments we made + the teachers maximum stack amounts were working well.

my overall takeaways

i went to this meeting to both meet new people in town to network with as well as to get out of my comfort zone. i find when i do the latter, i learn a lot and sometimes get a new perspective. it gave me a new appreciation for project managers who have not just 1, but 5 projects they have to manage to make an attempt to do this on. this also assumes they get enough time to really learn about each teams issues, where those bottlenecks are, and what the best ways are to address them. not by just fixing the bottlenecks, but by fixing the process itself, ensuring stop guards are in place not as many items/cards in a column, etc.

it also made me intimately aware of how i, as a consultant, immediately want to fix the bottleneck, and have learned ways (such as the war room) to solve them… when in reality, it’s a pm issue for a greater process problem. the other thing that makes it more complex is the whole “all things being equal”. for example, a kanban board a pm would use on the whole process vs. just the kanban board my software team would use. if my team fails to do tdd and ends up with a variety of bugs in the system because we’re forced to develop quickly and produce bad work, this show up on hers as us being the bottleneck. without time to talk to us and really empower us to change our process, nothing will change.

i see this time and time again. the excuses, which are sometimes valid, range from “the software’s good enough even with the bugs”, or “tdd is too much work for not enough value” or “we can’t write a test suite for a huge mess that isn’t even testable”. …and that’s just a small portion of what i’ve seen gone wrong. if you’ve ever worked for a design agency, or even a large firm that has a huge new client, it’s very apparent many teams have a hard time getting sign off from clients which causes a bottleneck in the analysis column on the kanban board because the items either pile up, or priority constantly shifts… yet they never actually make it out of their column.

a pm there who works with the government offered his strategies for dealing with the strange qa cycles government agencies will have where it goes into a black hole for 6 weeks thus really screwing up his kanban metrics.

overall, it was neat to be in a room with people who were geeking out on improving process. you see a lot of software developers get bored with programming or frustrated with how their lack of process is going, so they read up on xp and agile. when you look at what these pm’s deal with, it makes you feel like just a small part in a larger overall process.

more importantly, my preconceptions about leadership being the problem 99% of my problem projects really had a wrench thrown in. i was bitching about it to one of the pm’s, and quickly explained, in great detail, why some big companies which don’t have a hard line metric such as money to predict performance will often use lean methodologies since “ensuring customer satisfaction” is hard to measure depending on your business, and requires a more exploratory way of doing business. that said, it was great to hear that the common problems i experience in software dev with solutions were the same, just 1 of many that pm’s have to deal with.

i highly encourage software developers to partake in one of these exercises, even if you do scrum vs. kanban. really eye opening stuff.