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.
Efforting isn’t work
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.
Work equals Force time Distance
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 will play out differently from when managing physical activities. Software engineering is 'thought work,' where results are not as immediately obvious. Comparisons to assembly lines don’t fit the ideation and design aspects of software engineering. For starters, because software development work is not easily metered because it is so design-intensive. Early attempts such as measuring lines of code, number of objects, or volume of variables created didn’t work well.
There is a shared value, however: the eventual result should be a product. For software 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.
But 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. That is work, just as surely as moving a pile of bricks, but it is harder to measure because it reduces the amount of “stuff” while increasing less tangible things such as maintainability, recoverability, and modifiability.
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.
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.