 |
This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group. |
Complexity theory has had many people believe that predictions aren’t possible in complex systems and that emergent change is the only way forward. But it is important to understand that while knowledge work and many kinds of projects are complex, embedded within the complexity are fairly straightforward relationships. I call these the laws of Flow, Lean and Theory of constraints because these models explain what they are and how they work.
True, these may not be real laws like gravity, but they are reasonably accurate and provide guidance. They are not mere guidance but more fundamental principles on which to create guidance. Here are a few.
Principles, Laws and Adages
There is a significant difference between a principle and a law.
- Principle. A fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning
- Law (natural laws) are statements that describe or predict a range of natural phenomena.
- Adage a proverb or short statement expressing a general truth.
Principles, laws and adages are sometimes confused with each other. The significant difference is that principles are followed to achieve one’s goals, laws are the way things are and adages are the way things will be if you don’t do something about it. Laws are often forces, such as the “law of gravity” which can be overcome by other laws (e.g., satellites stay in orbit because the “law” of gravity is compensated by the “law” of centrifugal force. The key is that laws affect you whether you attend to them or not.
An example of the relationship between principles and laws is illustrated by looking at the principle of obtaining quick feedback. The law guiding this principle is that “delays in obtaining and using feedback creates work that would otherwise not need to be done.” There are many examples of this, including:
- The time from getting a requirement until validating it increases the likelihood that work will be done that was not the intention of the person creating the requirement
- The time from creating a bug until detecting it increases the time to fix it
Some things are called laws which really aren’t. For example, Murphy’s Law that “anything that can go wrong will go wrong.” Some people like to add “and at the worst possible time.” This of course, is not a real law, but it is worth acting as if it were.
Many “laws” may not be as well-defined as the law of gravity. But they are true enough that they should be attended to. Doing so can often alleviate their adverse effects when ignored. For example, one of the more important “laws” that affects software development, but is unfortunately mostly ignored is 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 the organizational structure and technical habits of the development teams are not attended to well.
This is not meant to be a complete list.
Some laws or adages regarding knowledge management
- Distrusting well-intended, competent people adversely affects their behavior
- When people are distrusted but are given the pretense that they are trusted, they will eventually figure out that they are not trusted
- Interrupting people’s work creates unplanned work while reducing the efficiency of the people who were interrupted
- Over-working people lowers their efficiency
- If you treat people poorly, they will not work as hard for you as they would otherwise
- People working on too many items lowers both their productivity and their resolve to do better
- Goodharts law: “When a measure becomes a target, it ceases to be a good measure.” Instead people work towards the measure but not the result intended.
- Parkinson’s law: is the adage that “work expands so as to fill the time available for its completion”.
- Conway’s law: is an adage stating that “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 Law:
- if people ignore principles that effect their work, they will get inferior results than if they attend to them
- if people don’t have compatible visions of the future, they will not work as well together as a team whose members have a compatible vision
- if people disagree on what is important and don’t try to resolve the disagreement or work with it, this disagreement will cause challenges
- people on a team attending to what they like instead of what works, lowers the functionality of a team
Some laws or adages specific to 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 how their teammates will understand the code
- Using archaic names for your code variables 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 correlated to the period of time between integrations
- if you don’t get customer feedback quickly, you will write code a lot of code they really don’t want (for any number of reasons)
Some laws or adages regarding management
- if managers can’t see what you are doing, they won’t understand what you are doing (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
For the most definitive collection of laws and principles regarding product development, see The Principles of Product Development Flow: Second Generation Lean Product Development by Don Reinertsen.
Applying Laws in a Complex System
Many in the Agile community believe that laws don’t exist in software development because it is a complex system. However, I believe that there are laws that virtually always apply. But laws in a complex system may not always appear to apply because other factors are at play – sometimes unknown factors. For example, I believe that if people work on too many things their efficiency goes down. But if they are not a limiting factor on value delivery it may not make any difference.
However, it is not worth debating whether these are true laws or not. It is worth acting as if they were, but validating them just in case we are mistaken. Sometimes even when we discover a law and apply it properly we may miss another law that also applies. This would not be unlike when the designers of the Tacoma Narrows Bridge didn’t attend to wind velocity and insufficient redundancy in the stays of the bridge. And then sometimes people will respond in a way that is not anticipated and essential block what would have been an improvement. But not attending to laws will definitely make positive change harder.
In conclusion
One must attend to the laws of knowledge work in general and software development in particular in order to be effective and/or efficient. Our beliefs about them do not change how they affect us. Part of Agile’s focus on “inspect and adapt” must be about learning how we are being affected by laws we are not paying enough attention to.