Knowledge work and many kinds of project work are complex. The outcome of any organizational change is hard to predict. It helps to understand that teams and organizations operate within a network of what are often straightforward relationships; they operate under what we call the “laws of flow, lean, and theory of constraints.” These laws are reasonably accurate. They guide our efforts for change and improvement.
We have to pay attention to both the way things are and the way things will be if we don’t do something about them.
Laws are often forces which can be overcome by other laws. For example, satellites stay in orbit because the law of gravity is compensated by the law of centrifugal force. Laws affect us whether we attend to them or not.
In knowledge work, the laws of flow, lean, and the theory of constraints may not be as well-defined as the law of gravity, but they are true enough to warrant our attention. Doing so helps us avoid adverse effects. For example, consider Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Conway’s law is a force that, if left unchallenged, results in poor architectures when you do not attend to the organizational structure and technical habits of the teams.
The following are some of the laws and adages that are important to our work. This is not an exhaustive list.
Some Laws for Knowledge Work
- Parkinson’s Law: Work expands to fill the time available for its completion.
- Conway’s Law: Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
- Shalloway’s Corollary to Conway’s Law: When development groups change how their development staff are organized, their current application architecture will work against them.
- Shalloway’s Laws:
- Ignoring the principles that affect work inevitably leads to inferior results.
- When people have incompatible visions of the future, they will not work well together as a team.
- When people disagree on what is important, those disagreements will cause challenges if not resolved.
- When people on a team attend to only what they like, rather than on what works, the whole team’s performance and function will suffer.
Implications for Software Development
- Not defining or validating acceptance tests with the customer (or their representative) before writing code tends to cause wasted effort.
- Not attending to code quality results in the degradation of the code over time, increasing its cost to maintain.
- When a developer writes code attending to only how they like code to be written, their teammates will have more trouble understanding it than if they attended to the team’s coding guidelines.
- Using archaic names for your code variables and methods makes it harder for people (including the author) to understand the code’s intention than if intention revealing names were used.
- The time it takes to perform an integration is proportional to the period of time between integrations.
- If you don’t get customer feedback quickly, you will write code they really don’t want (for any number of reasons).
Implications for Management
- If managers can't see what the team is doing, they won't understand their work (this does not imply they will understand it by just seeing it).
- If managers ask you to do one more thing in your iteration and they don’t know your process (or you don’t have an explicit one) then, when you say you can’t squeeze it in, they will likely think you just aren’t willing to take the extra effort required.
- If you treat managers without respect, you will get less respect in return.
Implications for Working in Complex Systems
It is not worth debating whether these laws are true. Act as if they are, but validate them.
Remember that these laws operate within a system, a network of relationships. We may apply one law correctly only to miss that other laws may also apply.
For example, giving people too much work will cause them to be inefficient. But not having work sequenced correctly will cause delays in value. And as long as that is true, reducing people’s workload will not help value to flow more quickly.
In addition, when working in a complex system, we must always attend to forces inside and outside the system. We do not know how outside people will respond to changes we are trying to make.
Attending to the laws is usually helpful; but not attending to them definitely makes organizational change harder.