Agile Software Management Accounting for Systems

• By David J. Anderson
• Feb 20, 2004
• Sample Chapter is provided courtesy of Prentice Hall Professional

This chapter is from the book
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

Detail Complexity Versus Systems Complexity

It is not unusual to meet people who are good at coping with complexity. However, probably only a few of them are systems thinkers. Much of the complexity in life is detail complexity [O'Connor 1997, p. 15]. Detail complexity describes something that has many parts, for example, a project plan with 1,500 tasks has detail complexity. Software analysis has detail complexity. UML class diagrams or database entity-relationship diagrams have detail complexity.

On the other hand, a system with many nested feedback loops, where small variations in the operation of the system can leverage enormous differences in the outcome, is said to have "inherent complexity." Understanding inherent complexity is difficult. It does not come naturally. Understanding inherent complexity means deducing the rules of the system operation, understanding the emergent properties and how varying the rules will leverage effect on the output of the system. If the inherent complexity is properly understood, it should be possible to expend the minimum amount of energy to leverage the maximum amount of improvement in the adaptive behavior (or outcome) of the system. A failure to understand the inherent complexity can result in changes that lead to undesired adaptive behavior or to expending excessive amounts of energy in the system in order to achieve the desired outcome. Expending excessive amounts of energy happens when the leverage point is chosen incorrectly because of a failure to fully comprehend the system.