Keeping Work Moving

The physics of attention in software development

Building software is not like working on an assembly line. 

One key difference lies in how work “moves” in software vs. on an assembly line.

Newton’s First Law of Motion says, 

𝘈𝘯 𝘰𝘣𝘫𝘦𝘤𝘵 𝘢𝘵 𝘳𝘦𝘴𝘵 𝘴𝘵𝘢𝘺𝘴 𝘢𝘵 𝘳𝘦𝘴𝘵 𝘢𝘯𝘥 𝘢𝘯 𝘰𝘣𝘫𝘦𝘤𝘵 𝘪𝘯 𝘮𝘰𝘵𝘪𝘰𝘯 𝘴𝘵𝘢𝘺𝘴 𝘪𝘯 𝘮𝘰𝘵𝘪𝘰𝘯 𝘸𝘪𝘵𝘩 𝘵𝘩𝘦 𝘴𝘢𝘮𝘦 𝘴𝘱𝘦𝘦𝘥 𝘢𝘯𝘥 𝘪𝘯 𝘵𝘩𝘦 𝘴𝘢𝘮𝘦 𝘥𝘪𝘳𝘦𝘤𝘵𝘪𝘰𝘯 𝘶𝘯𝘭𝘦𝘴𝘴 𝘢𝘤𝘵𝘦𝘥 𝘶𝘱𝘰𝘯 𝘣𝘺 𝘢𝘯 𝘶𝘯𝘣𝘢𝘭𝘢𝘯𝘤𝘦𝘥 𝘧𝘰𝘳𝘤𝘦.

In assembly line work, this unbalanced force is exerted by the moving assembly line, which keeps work in constant motion unless someone explicitly stops the line.

In software development, the opposite is true.

The only unbalanced force that can keep work moving is attention: from people with the right knowledge and skills to collaborate and keep work in motion. 

Work stops moving when the attention is taken away or not in the right place at the right time.

So odd as it might seem, software development and the famous Canadian sport of curling have much in common!

Both of them need constant attention on the “work” for it to keep moving through the “system,” particularly in the most knowledge-intensive parts of the process like UX design and coding.

There is no denying that the software development process's most valuable and knowledge-intensive parts are kept in motion by the force of human attention, at least in these early days of generative AI.

One of the critical arguments for automating the development process, wherever possible, is to create an assembly line-like external force that keeps work moving through the pipeline without needing this constant human attention, particularly in the non-value-added packaging and deployment phases.

So what?

First, cognitive load has been recognized as a key limiting constraint to flow in software development

¹

, but measuring this directly is tricky.

If, however, we take the view that focusing attention on a unit of work consumes cognitive capacity and turns it to motion - a directly perceptible and potentially measurable property of work - then we have an indirect way of measuring the cognitive capacity and distribution of cognitive load within a system, by examining the motion of work within it.

This gives us concrete ways of measuring if changes made to organizations to facilitate the flow of work based on the basis of optimizing the cognitive load on teams are having their intended effect.

Second, in software development, it is often difficult to plan what work needs attention, from whom, and when, even if we know everything that needs to be done and maybe even the order in which we want to do it. 

This might make it feel like software development is inherently chaotic or complex and unpredictable.

But a straightforward way exists to manage this complexity and uncertainty.

Watch the work in progress and look for the work that is not moving. 

If we can accurately measure the “motion” of software work, we can identify imbalances between cognitive capacity and demand in the system lie and what, if anything, needs to be done about it.

This is important because motionless work is a key indicator of an unstable system, a system that takes on more work than it can deliver.

Motion and Instability

If you recall the four conditions for system stability, the critical condition impacted by this is the fourth one.

The average age of the units of work in progress is neither increasing or decreasing unboundedly.

Work that stops moving continues to age in the system, and the longer it stays immobile, the greater the impact on the average age on work in progress in the system, and the likelihood that it will violate the fourth condition pushing the system into instablity.

However, if we can reason rigorously about the motion of work, we have a very practical principle we can apply to manage this condition for stability.

We call it the “Keep Work Moving” principle.

If the first three conditions for stability are satisfied, and in addition, we can keep all the work in the system moving at all times, then the system will be stable.

We will develop a definition of motion and motion analysis that is suitable for operationalizing this principle in upcoming posts.

But first, let’s see what this buys us.

Why “Keeping Work Moving” Matters

The key idea is that the system should only take on as much work that it can keep moving at all times.

In software, the aging of work is just as critical a factor in creating instability as the amount of work in progress and the ability to visualize the “motion” of work, together with policies that are designed to regulate the flow of work in response to the slowing or stalling work are critical.

This, in turn, sheds light and provides tools to manage imbalances in cognitive capacity and load across a system, which is a critical constraint in software development work.

If all work in progress is moving at all times, then the cognitive load on the system is within manageable levels. Otherwise, there are imbalances that need to be identified and addressed.

You can think of “Keep Work Moving” as a principle we need in software development in addition to the principles of “Limit WIP" and “Pull Work” used to manage the number of items in the system and the rate at which work is accepted into the system at any time, to stabilize flow through a system.

There are essential relationships between all these principles, which we will explore later in our series.

The “Keep Work Moving” principle

²

, combined with measuring and visualizing the motion of work, gives us some useful tools to manage aging work actively and regulate the flow of work when aging causes a system to move away from stability.

Analyzing the impediments to “Keeping Work Moving” can be a powerful tool for system analysis and improvement and can shed light on process inefficiencies, skill gaps in delivery, knowledge gaps and constraints, and true capacity to deliver work in a stable fashion, among many others.

All of these and more will be discussed as we make our way through this series on stability and flow.

Thanks for reading.

1. The seminal work here is Team Topologies from Mathew Skelton and Manuel Pais.

More recently, Dr. Craig Statham and Stephen Walter introduced a set of formal techniques for reasoning about the relationship between cognitive load and flow as part of their work on the Value Stream Reference Architecture. Their work directly inspired me to make the connection between cognitive load and motion analysis, a key aspect of how we approach product development flow in The Polaris Advisor Program. I am confident that there are deeper connections to be established between their formalism and the laws of flow as described by queueing theory, which is our primary theoretical lens for analyzing flow.

2. The “Keep Work Moving” principle is closely related to Flow Efficiency, but I view this as a fundamental principle that is first used to make a system stable and later used to improve flow efficiency once we have established stability.