In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.

Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.

I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.

Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.

Compensation

We got paid by something they called “piecework”. That is, only completed boilers mattered coming off of our line. If a boiler unit was completed through packaging and final inspection, then everyone on the line would get a fixed figure for the type (size) of boiler they just produced.

If I remember correctly the per station, piecework rates were around $1.50 – $3.00 per boiler. Depending on our speed and the sizes of the boilers, we would make between 5-8 boilers per hour. Even though the work was very manual and hard, in the late 1970’s, this was a very attractive hourly rate.

It was also somewhat variable depending on how hard “the line” wanted to work. I recall during each Christmas season, we would refocus and nearly double our output. It wasn’t sustainable in the long term, but we could do it for a monthly ‘burst’, which served as a Christmas Bonus of sorts.

Of course the entire line had to agree to the increased effort and stress and this didn’t always happen.

Flow

It turned out that individual productivity didn’t really matter so much. We were constrained by the overall capacity of the entire line. So, the slowest team member would always be the limiting factor.

Quite often it wasn’t simply performance that limited us, but other factors. Line members would come into work ill, injured, or not feeling very energetic and they would fall below their standards of performance. So there could be quite a bit of variability in the overall line’s performance.

Even breaks were an issue. It was almost funny in that line members were extremely reluctant to take bathroom breaks because it would affect the productivity of the overall line and their compensation.

If you were fast at your station, then you could “work ahead” for a bit and create a queue so that you could take a bathroom break without affecting flow. But only if your upstream partner could produce as quickly as your increased rate.

Quality

As I said, ultimately we were only compensated by finished boilers so quality was a significant factor. One way we all compensated for that was everyone knowing each others jobs. We would rotate jobs quite often so that each of us understood the role and responsibilities of each station on the line.

We then found who was ‘best’ at each station and we would optimize for them to working in the station where they would be the most productive. But, this understanding also allowed all of us to check each other’s work along the assembly line.

You see, we were also responsible for fixing the boilers we delivered with defects and these were not compensated at a piecework level. Instead, we received a very low hourly rate for all rework. So it was in our best interest to catch errors, defects, and omissions early and fix them as soon as possible.

It was a balancing act with speed/productivity versus quality, with everyone one on the line paying attention to overall product quality.

Ideas & Continuous Improvement

It may sound counterintuitive, but we were constantly tuning our processes. Sure, we were incredibly focused on our production and throughput, but we also spent time experimenting.

I remember one experiment was when I helped my upstream partner to build base units at the beginning of our shift. The idea was to build a large queue, because his station was the most sensitive to increased work time associated with larger and larger boilers.

The downstream partners would stock the other stations while we were doing this so we had sufficient materials for a long run. This became part of our pattern when we were

We also looked for novel tools and approaches for assembly. In some cases, manual tools were actually faster than their compressed air cousins, so we were always fiddling with our techniques and approaches.

Throughput was all that Mattered!

We really had only three measures that we (and the company) cared about:

1. How many boilers of varying sizes did we produce each shift?
2. How much rework did we have?
3. How much money did we make per hour? (both in piecework and rework rates)

We tried to keep our rework at zero per shift and maximize our rates. This wasn’t always possible, but it was a goal for every shift.

One of the things that a focus on throughput influenced was working across stations. I’ve already said that we learned each other’s stations. But beyond that, we would help across each other’s stations during each shift as needed to keep the flow even and balanced across the line. If someone fell behind for any reason, even if we didn’t like it, we would pitch in and help out.

Why?

Because it benefited the line, our overall throughput, and ultimately our pocketbooks. We realized the only real measure that counted was what we produced as a line or team!

Wrapping Up

First of all let me say this. I fully realize that manufacturing boilers is significantly different than the knowledge work associated with software development. I’m not trying to demean developers or boilermakers by making the comparison J

However, from an agile and lean perspective, I see lots of correlation between the two. Which is why I’ve been reflecting back to those days lately. I see agile practices like:

• Swarming
• Whole-team quality
• Innovation
• Focus on throughput
• Rework avoidance
• Team skill balance
• Stretching

Emerging from my experiences on the assembly line.

Beyond that though, the notion of piecework drove many of these behaviors—that and the assembly line logistics themselves. I wonder…

What if we only paid agile teams for fully done User Stories? Stories where they completely met the Definition of Done without any rework remaining? I wonder what behaviors that would inspire within the teams?

Stay agile my friends,

Bob.