In his new book, Leadership Is Language, David Marquet (2020) contrasts what he calls “red” and “blue” work. The distinction does a beautiful job illustrating what’s wrong with many Agile transformations.
The Red and the Blue….
Red work is DOING work. It’s about execution and reducing variability.
Blue is THINKING work. It’s about discovery and decision making and increasing variability.
Marquet’s distinction echoes Reinertsen’s (2009) discussion of recipes. In a factory, you are running the same recipe over and over. (It’s red work.) Design, on the other hand, is the creation of NEW recipes. (It’s blue work.)
In the Industrial Revolution, Marquet notes, factories optimized by having DIFFERENT people do the blue and red work. Higher-ups did the blue and the boots on the ground the red. The blue workers would then measure the red workers on their efficiency.
This may have made sense for an assembly line—but it also lay the groundwork for what McGregor (1960) would later describe as “Theory X” thinking, the assumption that people by and large do not want to work and need to be controlled and coerced to maximize productivity.
In many of today’s contexts, such as software product design and development, this separation of blue from red work makes less and less sense, Marquet argues. It impedes value, flooding the system with handoffs and unnecessary dependencies, and worsening the responsiveness and quality of decisions made.
Agile as Skeuomorphism
You can probably guess how this pertains to Agile. Executives seem hellbent on insisting Agile was about speed or efficiency (or whatever else they want it to be about) and not, ahem, AGILITY. It’s a bait-and-switch. Below, for instance, is a graph from the 13th annual Version One State of Agile report. Notice the things it focuses on.
Agile keeps getting twisted into a way to speed up the red work while keeping the blue work separate. The focus then is largely on acceleration, productivity, reducing cost, and predictability. That’s factory thinking, plain and simple—assembly-line red work at a remove from the blue, and that is not what increases agility.
When orgs do their “transformations” while focusing on accelerating the red work, it reduces Agile to a skeuomorph in the old sense of the term. You might be familiar with the concept in UI design, where it’s often a good thing.
An example is making a digital button look like a physical button to provide users with an affordance. The box now LOOKS like something that’s physically clickable.
But that’s not the original meaning of the word. H. Colley March coined the term (in 1890!) specifically to describe NONfunctional adornment. As Basalla (1988) puts it, a “skeuomorph” was to take something necessary to one design and mimic it in another in an UNNEEDED way.
An example is pottery with fake clay rivets, made to resemble metal pots that need real rivets. There are digital equivalents as well, such as Apple’s bizarre iCal, with its buttons formatted to look like…leather? (Petrovski, 2012)
The result is tacky and misleading…like most Agile transformations. Agile was SUPPOSED to be about empowering software teams, not applying thumbscrews and placing them unfairly under an efficiency microscope.
The result of most transformations is a form of fakery, with orgs touting the importance of “agility” while not doing much to increase it. Instead they impose some Scrum administrivia, ignoring that imposition is already not Agile. They tell teams to go faster, and in attempt to make the org itself go faster, end up increasing dependencies as they equivocate on the meaning of “scaling.”
Scaling is SUPPOSED to mean teams figure things out and spread their discoveries for other teams that want to leverage them. What it tends to mean in practice is an org has some serious issues, hasn’t figured out anything, but wants impose “scaling” in order to somehow solve the problem for them.
Notice this equivocation gets it backwards. If you do Agile as intended (without imposition), the conflict goes away. If you let teams discover what works best and nurture and grow their learnings while removing obstacles to their organic continuous improvement, then there is no need for a “transformation” and, ironically, there is nothing to “scale.”
When you equivocate on the core essentia of Agile, your use of the term becomes disingenuous and largely for show. In other words, it’s a skeuomorph—it’s like fake shutters on a 1970s house or ornamental kitchen drawers that don’t actually open.
To increase agility, to be “agile,” you must avoid the bait-and-switch. Agile never was about increasing the efficiency of red work. As Marquet argues, in today’s world, you by and large want the blue and red work done by THE SAME PEOPLE.
Agile was about increasing this. Just read the Manifesto. Forget Scrum. You want teams working DIRECTLY with customers, it says. If your take on “scaling Agile” PREVENTS this, then you might want to ask, what exactly are you “scaling?”
Iteratively building product increments (red work) only increases agility if it produces learnings that result in smarter bets made (blue work) without a bunch of dependencies and handoffs.
There is a direct inverse relationship between agility and dependencies. Increasing the former requires a tighter coupling of the blue-work decision authority to “pick bets” to the red-work discovery that should immediately “derisk” the assumptions being made.
The tighter the link, the greater the agility, period. This gets us back to the actual point of Agile—empowering teams.
There is both a power and LEVITY in teams that have the right mix of empowerment and know-how. For agility, for NIMBLENESS, for increased speed of learning and optimal decision-value maximization, teams need know-how and empowerment for both red AND blue work.
Maximizing them as separate matrices is, well….
Until next time.
References
Basalla, G. (1988). The evolution of technology. Cambridge, UK: Cambridge University Press.
March, H. C. (1890). The meaning of ornament; or its archaeology and its psychology. Transactions of the Lancashire and Chesire Antiquarian Society, Volume 7, 160-192.
Marquet, D. (2020). Leadership is language: The hidden power of what you say and what you don’t. USA: Portfolio/Penguin.
McGregor, D. (1960). The human side of enterprise. NY: McGraw-Hill.
Petrovski, P. (2012). The authentically digital interface. Thoughts on the Connected Future. Retrieved on October 13, 2014 from: http://www.peterpetrovski.com/post/28032060238/the-authentically-digital-interface.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation Lean product development. Redondo Beach, CA: Celeritas Publishing.
Charles Lambdin 
6 thoughts on “Red and Blue Work: Agile as Skeuomorphism”