…work, work, work. It’s what we do.
“I have to go to work.”
“What do you do for work?”
“OK, team. Let’s get to work.”
“Where do you work?
“Is that working for you?”
“That’ll never work.”
“Let’s work together.”
“Time to roll up our sleeves and get to work.”
The notion of work is so pervasive it underpins my belief that Agile principles and practices can be applied to a variety of human endeavors beyond the narrow focus on software development. In fact, the case can be made that Agile principles and practices have been around for millennia and only very recently were codified for a software development context. Agile simply feels more natural, more aligned with how humans think and interact to solve problems. From the way we explore and learn as children to the way we solve problems at home as adults, it’s much easier to recognize Agile patterns than waterfall patterns. Somehow, when we go to work we’re subject to the behaviors and measures of machines and Taylorism.
It doesn’t have to be that way. Agile has been shown to more effective at increasing productivity and decreasing costs in contexts beyond software. So why isn’t it practiced everywhere all the time?
I can think of a couple of broad generalizations that answer this question. First, Agile isn’t a panacea. Nothing is. To paraphrase Winston Churchill, Agile is the worst form of project management, except for all the others. Second, in the light of Conway’s Law and Shalloway’s Corollary, the systemic monster pushing back on change is a formidable one.
I have no aspirations of making Agile a panacea and will never claim it to be one. But until something more promising comes along, I can work to improve the practices for applying Agile values and principles. As for the systemic monster, that’s what this series of articles are about.
Monsters are scary because we don’t know them, we can’t see them, they’re hidden from us, they’re “out there, somewhere.” We’ll begin the process of understanding the systemic workplace monster by shining a light on work. What is it? How do we define it?
With each new day, in one form or another, we face a newly filled box of Work to Do. On the far side of the day, there is an empty box of Work Done.
In a perfect world, by the end of the day, Work to Do is empty and Work Done is full.
This transition doesn’t happen by itself. Magic won’t get work moved to done. There’s effort involved. More effort means more progress. Less effort, less progress. On Agile software projects, Work to Do is described in the product backlog and Work Done manifests as a deliverable product or service.
Typically, there is some form of measure on progress toward the goal of getting work to done. In scrum, this might be story points completed or business value delivered.
But we don’t live in a perfect world. Whatever the endeavor, errors and mistakes are part of the work effort. Instructions were unclear or incomplete, time constraints caused the work to be rushed, the person doing the work was apathetic or otherwise unfocused – there are thousands of reasons for why some of the work fails to meet expectations.
Since our efforts to complete work are always less than perfect by some percentage, part of the effort that creates progress is also an effort that generates errors. Anyone managing a project – especially a technical project – should expect that there is a box of Undiscovered Rework hiding somewhere. How big that box is or how fast it’s filling are unknown. All we know at this point is the box of Undiscovered Rework exists. In software development, the contents of this box are referred to as defects or bugs.
We know the box of Undiscovered Rework is there somewhere. So now we need a deliberate effort aimed at discovering that rework. This is the job of quality assurance and testing professionals. Their efforts at rework discovery bring the defects and errors to light so that they can be documented and added to the flow of Work to Do.
This is the work loop.1 Human interactions and behaviors aimed at achieving some larger goal provide the energy for driving this loop. The quality of those interactions determine how fast work moves through this loop.
In subsequent posts, we’ll begin to explore several specific human interactions and behaviors the can either support or inhibit the flow of work through this loop. But first, a sidebar to learn how to read the diagrams that follow. We’ll cover that in the next post of this series.
Previous article in the series: Assessing and Tracking Team Performance – Part 1: The Revenge of Frankenagile
Next article in the series: Assessing and Tracking Team Performance – Part 3: System Dynamics and Causal Loop Diagrams 101
1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007