Gall's Law is an essential observation about systems (not just software systems, but organizational ones as well, and it applies recursively). It states:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Software systems need to start small and simple and then evolve over time through frequent releases for feedback and adjustments based on that feedback. Big-up-front planning—everything from backlogs to architecture to over-specified "stories"—is in the way of that.
Similarly, the best organizational systems start small (e.g., as a startup) and evolve consciously as the organization grows. (Please pay attention to the word "consciously." Random growth never works—in organizations or in software products.)
When it comes to "transitioning to" or "adopting" Agile, we're firmly in the territory of Gall's Law as well. First, the existing organizational system almost always falls into the "never works and cannot be made to work" category, so you end up in "start over" territory. Doing that all at once, by bringing in a Deloitte or an army of Scrum trainers, also "never works." Start simple with a top-level readjustment of thinking about how the organization should work—a C-Level strategy. Then, begin small and *consciously* and incrementally change things until that new philosophy is realized.
Gall's Law
Gall's Law
Gall's Law
Gall's Law is an essential observation about systems (not just software systems, but organizational ones as well, and it applies recursively). It states:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Software systems need to start small and simple and then evolve over time through frequent releases for feedback and adjustments based on that feedback. Big-up-front planning—everything from backlogs to architecture to over-specified "stories"—is in the way of that.
Similarly, the best organizational systems start small (e.g., as a startup) and evolve consciously as the organization grows. (Please pay attention to the word "consciously." Random growth never works—in organizations or in software products.)
When it comes to "transitioning to" or "adopting" Agile, we're firmly in the territory of Gall's Law as well. First, the existing organizational system almost always falls into the "never works and cannot be made to work" category, so you end up in "start over" territory. Doing that all at once, by bringing in a Deloitte or an army of Scrum trainers, also "never works." Start simple with a top-level readjustment of thinking about how the organization should work—a C-Level strategy. Then, begin small and *consciously* and incrementally change things until that new philosophy is realized.