In physics, if you exert force on an object but the object doesn’t move, no work has been performed. Applied force or effort does not equal work performed.

Work measures something happening. Efficiency compares the effort expended to the results achieved. Expending calories without achieving anything is "efforting." “Efforting” is not working. It has zero value. All the preparing, pushing, hydrating, sweating, calorie burn, and wear on work gloves are just resource consumption.

Does this mean that effort is work only to the extent that the desired outcome is achieved? Yes and no. You can roll a boulder over your own foot, and still accomplish work – painfully. A result that is damaging or sends the object in the wrong direction is “waste,” but it still is work.

In software engineering, contrasting work with efforting requires differeing thinking from when evaluation physical behaviors such as manufacturing. Software engineering is 'thought work,' where results are not as immediately obvious. “Waste” and “scrap” can be byproducts of non-systems thinking (or daydreaming), but require different approaches to detect and reduce. Comparisons to assembly lines don’t fit the ideation and design-intensive aspects of software engineering. Early attempts to separate work from waste, such as measuring lines of code, number of objects, or volume of variables created, didn’t work well.

There is one useful marker, however: the eventual result should be a product. In software engineering that is the primary, measurable determination of work performed. Just as with physical products, the more frequently chunks of product are created and validated, the better we can determine if we are working effectively and efficiently.

It’s tricky. Sometimes a person will sit quietly for a week, apparently doing nothing, then jump up and churn out fifty lines of code that reduce a code base by hundreds – or thousands -- of lines of duplicative and bulky code. Or a development lead may use an Inspect and Adapt session to lobby for refactoring of the code base because velocity fixation caused sloppy maintenance of a core code library, making it brittle and causing defect insertion each time it was touched. Thinking and refactoring are also work (highly valuable work), just as surely as moving a pile of bricks, but they are harder to measure because they reduce the amount of “stuff” generated while increasing less tangible things such as maintainability, recoverability, and modifiability.

(The refactoring case is a real one where I backed the technical lead. He was able to make his case because defect removal was taking increasingly more time each iteration, squeezing new product creation to a trickle. The business sponsors agreed to let teams spend a PI fixing architectural problems, and in the following PI their rate of product demonstration shot up to pre-slowdown levels.)

Some managers struggle with this concept. Anxious to see digital equivalents of sweat, grunting, and worn-out work gloves, they will divert efforts into filling out Gantt Charts, multiplying status meetings, and demanding endless numbers of PowerPoint slides. This is how Lean, Agile, Kanban, DevOps, and other approaches get buried under output chaff.

Tom DeMarco and Timothy Lister wrote about a programmer sitting in profound thought until his boss asked, "What are you doing." He replied, "I'm thinking," at which his boss said, "do that at home!" Apparently thinking didn’t look worky enough, even from a thought worker

Agile and kindred approaches try to pare away non-essential things to maximize the amount of valuable work done for the effort, and to maximize the amount of "efforting" not done. (The bullet point in the 12 Principles touching on this could have been worded differently.)

Understanding what 'work' actually means prepares us to understand whether the way we work is efficient, effective, and ethical. If someone contracts me to move an object, and I hire skilled professionals with equipment who are measured on how efficiently they get that object moved, then I am doing well. If I spend all the money on labor for a low-wage crew (with a high markup) that takes an enormous amount of time to complete less work -- then that is ethically questionable. At best it is incompetent.

In software development, if we hear talk about useless Scrum ceremonies, requirements elicitation activities without resulting Features or Stories*, and planning ceremonies where no planning occurs, then we may be seeing examples of effort expended with minimal work accomplished while using Agile terminology. We should ask hard questions in those situations. We should check whether so-called Lean or Agile approaches are creating the same amount of bloat and chaff as did the "heavy" approaches they replaced.

*Scrum practitioners would complain that creating backlogs of Features, Stories with point values, BDD-based Acceptance Criteria, etc. are useless work. They are correct within that framework. In Agile environments with less uncertain and exploratory work, then using some level of those techniques can be useful.

Thought Work