Archive

Monthly Archives: February 2019

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

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

5W+1H

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:

  1. There can be no basis for comparison (before/after)
  2. One cannot objectively tell if there was a difference or change
  3. 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.

– Bob

Further Reading

What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal

 

Antimatter Principle Elaborated

Around a year ago I wrote a post with the title “Antimatter Evo“. For those who may have found it a little over-long, and for those who prefer lists, I’ve extracted the core Antimatter Principle elements into this briefer post ( corresponding, BTW, to the twelve principles of the Agile Manifesto). And I’ve also added a list of related Think Different posts under “Further Reading”.

Twelve Principles for Software Development

The Twelve Principles of Agile Development as seen through the Antimatter Principle lens, and its vocabulary:

1. Our only priority is to continually attend to the needs of everyone that matters.

2. Handle changing needs, and changing membership of the “everyone that matters” community, in ways that meet the needs of the folks that matter.

3. Deliver stuff as often as, and by means that, meets the needs of everyone that matters.

4. Share needs and solutions as often as, and by means that, meets the needs of everyone that matters.

5. Motivate people to the degree that, and by means that, meets the needs of everyone that matters.

6. Facilitate sharing of information, feelings, needs, etc. to the degree that, and by means that, meets the needs of everyone that matters.

7. Choose a primary measure of progress that meets the needs of everyone that matters.

8. Choose a pace that meets the needs of everyone that matters.

9. Agree on attributes of quality, and levels of quality, with respect to the means of the endeavour, that meets the needs of everyone that matters.

10. Spend effort only where it directly attends to some need of someone that matters.

11. Agree on attributes of quality, and levels of quality, with respect to the organisation of the endeavour, that meets the needs of everyone that matters.

12. Pursue improvement, with respect to the means and organisation of the endeavour, that meets the needs of everyone that matters.

Summary

The Antimatter Principle is simplicity itself (just four words) – “Attend to folks’ needs”.

The above list illustrates how the Twelve Principles can be subsumed by just the one.

– Bob

Further Reading

The Antimatter Principle ~ Think Different blog post
A Vocabulary for the Antimatter Principle ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
The Needsscape ~ Think Different blog post
Wants, Needs ~ Think Different blog post
How To Connect With Folks’ Needs ~ Think Different blog post
NeedsFlow ~ Think Different blog post
The Agile Path to Quality ~ Think Different blog post