Note: I use this part of my wiki to order thoughts, prepare presentations, have ready-to-grab material to "defend" agile development, etcetera. So stuff may be written down only partially, stuff may be incomplete, I may have understood things wrong - please give me feedback on the latter bit....
Agile Development, in my eyes, is software (and business!) development using methods rooted in social complexity science.
Using techniques like ![[WWW]](/moin-1.3.5/cdegroot/img/moin-www.png){kind=small}
Cynefin, one can analyze whether projects, companies, departments, ... are in ordered or complex space (or chaotic, or ...). For systems in complex space, agile methods are applicable. Other systems either need to be moved to complex space, or better matching methods must be used. I wouldn't probably try to manage the building process of a nuclear power plant using Scrum (parts of the design process? Maybe). This analysis is critical!
Cynefin sense-making/classification framework:
Known. Simple stuff,
zero'th order ignorance. Taylorism applies, optimizing for efficiency will work. Knowable. Complicated stuff, first order ignorance. The realm for knowledge management methods.
Complex. Retrospective coherence. Knowledge management won't work. Small improvements with lots of feedback.
Chaotic. Nothing is predictable, nothing works. Probably best to move the system to either of the other spaces.
Disorder. Disagreement about where the system resides.
Ken Schwaber uses a different diagram in the description of Scrum, using axis labeled 'Agreement on requirements' and 'Certainty about technology').
Full agreement and complete certainty mean that the system is simple.
Full agreement but incomplete certainty moves the system into the complicated realm of religion - "I don't care what the project is, we're going to solve it with J2EE';
Certainty but incomplete agreement moves the system into the complicated realm of politics - "The government must change" (but how?);
The top right corner - no agreement, no certainty - is the chaotic domain of anarchy;
Finally, moderate amounts of disagreement and uncertainty result in complex systems.
Note that both systems use the distinction between "complicated" and "complex". A Boeing 747 is complicated. Way too many parts there to keep in your head, but if you take a 747 apart and rebuild it (which is a major undertaking of many man-years), you'll end up with the same 747. The whole is just the sum of the parts. A software development team is complex. Even if you start analyzing it, you will change it; let alone if you take the team apart and rebuild it. The whole is more or less than the sum of the parts.
If a system fits the attributes of a complex system, it is manageable with agile methods. Often, a system can be brought to this space (if this is deemed a good thing) by kicking up some dust, which may be as simple as ripping out the old development system and replacing it with an agile development system. That'll move the system closer to chaos, into complex space; feedback loops must be present in order to prevent the system from falling off the edge.
