Standard Work and Collaboration
Standard Work and Collaboration
[Tl;Dr: Ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.]
Standard work (also known as Standardized Work) is an operational definition of how the work works today. Best written and maintained (studied, updated) by the folks actually doing the work. Toyota defines Standard Work as ”the steps one needs to walk in order to complete a process”. Mike Rother defines Standard Work as the “Target Condition” in the Improvement Kata. This seems to me to make some sense.
“There is something called standard work, but standards should be changed constantly.”
~ Taiichi Ohno, Workplace Management
In slightly more detail: “Standardized work answers the 5W+1H of a process – the who, what, when, where, why, and how. Who operates the process, and how many people does it take? What does the final product look like, what are the quality check points, what are the tools required to complete the job? When is a part completed and ready for the next step (how long should the cycle time and takt time be)? Where is this process completed and what does this location look like (standardized work cell, point of use storage of tools, etc)? Why is this step necessary or value-adding, or why is this a quality check point?”
“When there is no standard [work], there is no Kaizen (continual improvement).”
~ Taiichi Ohno
In other words, when a process is performed unsystematically in different ways, then:
- There can be no basis for comparison (before/after)
- One cannot objectively tell if there was a difference or change
- No improvement is possible in regards to Time, Quality, Quantity, Cost, etc.
Collaboration is Waste
So, where does collaboration come into the picture? If the standard work specifies “collaborate here” (with 5W+1H or an operation definition for the collaboration) for a particular step, then all is fine and dandy.
But often, in software development particularly, there is no standard work, or the standard work lacks the detail which might suggest the 5W+1H of the collaboration. Exceptions which come to mind are: the daily standup (Scrum), sprint planning (Scrum) and sprint retrospectives (Scrum) (i.e. the various Scrum ceremonies – for which teams rapidly find their own work standards or de facto operational definitions).
Consequently, collaboration in software development is most often ad-hoc. Someone might run into a problem or challenge, and ask a colleague e.g. “Hey, can you help me with this?” or “Can we pair on this for half an hour?” or “Let’s get together and figure out what to do here”.
If we had clearly defined standard work, the specifics of what to do and who to call on when a problem arises would already be defined. Without such standard work, the coordination (set-up, figuring-out) of the necessary collaboration is waste, and interrupts the flow (both of value, and in the Mihaly Csikszentmihalyi sense of the word).
Do I hear you rail against this idea? Do you believe it’s impossible to foresee where and when collaboration might be necessary? Do you enjoy collaborating so much that you’re prepared to dismiss its negatives? May I put it to you that in such circumstances, you don’t actually know what y’all are doing? That you have little or no clear idea how to get from the start of sprint (or longer term) to the end, to the delivery of value? That you’re making much of it (“the way the work works”) up as y’all go along?
“…this model of ‘standards’ as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what ‘continuous improvement’ really means.”
~ Mark Rosenthal
The Bottom Line
This may all seem rather esoteric. How much can it matter whether collaboration costs us a few dollars or hours? For me, ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.
Does it matter? I leave that to y’all to decide.
What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal
these thoughts have been intriguing to me. Indeed, collaboration is largely and perhaps reflexively considered to be a good thing without much thought spent on potential negative aspects.
Do you think that some of this ad-hoc collaboration in software development might be due to its often exploratory nature? In other words, is software development more about product development than about production (manufacturing according to specification) ? And does ad-hoc collaboration play a different role in product development than in production?
Or is all of that just a way of admitting we don’t know what we’re doing?