You Are Not A Lathe Operator

Share
Reading time ~4 minutes

This weekend my replacement copy of “The Goal” arrived. (My last copy escaped).

I wrote the following article in mid-2009 – some time before I read Goldratt’s “The Goal”. This was eventually published in 2010 internally at the company I was working with at the time. Today felt like a good day to refresh it and share more widely.

________________________________________

If you haven’t yet done so – read up on the theory of constraints. In fact I recommend that every manager in any size of organization obtain and read a copy of “The Goal” discuss it with your peers & teams and make copies available for your staff.

In Spring 2009 I had the good fortune to attend a training course in Florence, Italy – a hub for European manufacturing training for a large Oil & Gas company.

One of my working team during the week was in the process of implementing a lean production line for the local factory floor. Their layout and travel spaces were all mapped out but the reason for him attending the training was to cover the human aspects of such a radical change.
He had factory floor staff who had been performing the same expert role for 20-30 years or more. Now they were being asked to radically change their working practices and he was feeling the pain.

An operator producing bearings may traditionally be measured on their production volume (and quality).  Their single-minded goal is to maximise their own output. The more bearings produced, the better an operator they are. In some cases, particularly where waste is not well managed, volume may even trump quality.

In a production line, operators are contributing not to the production of bearings but to the production of complete working units as part of a team.
They have to look both up and down-stream and assess the state of flow through the entire team. If there’s a bottleneck in the line, they’re expected to adjust or stop their own activity to help out and “level the load” in order to maximize the performance and throughput of the entire assemblies they’re working on in the factory.

The challenge here was that some operators had learned over years of training and measurement to sub-optimize around their own roles and personal output even though the real unit of value was in the whole team’s output.

His challenge was not unique and for this particular company, lean manufacturing was already a major focus. The striking synergies between lean & agile meant I was able to share insights from my own experiences with him.

Now let’s take his example and consider some quotes often heard during software development.

  • “It’ll be far more efficient if I do all the coding now in one go.”
  • “Seeing as I’m already doing some surgery here it makes sense to add these few other things that I’m pretty sure we we’ll need”.

Often these are suffixed with “it’ll be ready in when it’s ready”.
I’ll raise my hand and admit to this behavior in the past – particularly when in the midst of a major refactoring exercise.
But…

  • What about everyone upstream and downstream of my code?
  • What’s the impact on the testers of me delivering 3 months worth of code over 2 days worth of code?
  • Do I have people waiting for work downstream?
  • If I changed my delivery practices would I get feedback sooner?
  • If I got feedback sooner would those bugs be less of a pain to context switch and fix?
  • Would the overall throughout of the team be greater?
  • If requirements change how much of my work would be wasted?

This is where agile and manufacturing meet.

Admittedly in manufacturing, the concept of a multi-skilled operator is far more prevalent than in software however the software industry equivalent is often described as the “Generalizing Specialist” – that is: whilst a member of the team may primarily be role X, they are able to add support and value in role Y – even if that’s not their job title.

This may be a simplification of reality but some skills are exportable or importable across roles and allow us to level the load by having others do the heavy lifting.

It is the responsibility of every member of a development team to consider the entire value-stream, the activities of all skills and roles that contribute to a working product increment and ask questions like:

  • “Am I working on our top priority item? – if not, should I contribute to it in some way?”
  • “Could we be delivering more finished work sooner if I helped out elsewhere?”
  • “I’d really appreciate someone covering these areas around the edges of what I’m working on”
  • “Here’s a problem that keeps slowing us down, let’s figure out how to remove the bottleneck.”

Think about your current role in a development team.

  • Are there opportunities for members of the team covering different roles to support each other better?
  • Is anyone over-producing in comparison to capacity of other areas and causing headaches downstream?
  • Could some conversations be had sooner, be much shorter and save pain?

Take some time out this week and consider how your teams and individuals could improve their cross-role collaboration, share some of the heavy lifting and deliver as a more cohesive unit?

Share your thoughts...