Agile Software Development Ecosystems

February 11 – 13, 2001, can be called the day of The Manifesto for Agile Software Development forthcoming. It declares that from then on people who deal with any software should strive for finding better ways of developing software by doing it and helping others do it.

Through this work we should come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiations
• Responding to changes over following the plan.

This Manifesto hasn’t been recognized as the answer to all problems, but it has given a push to real software development process improvement and elaboration.

The first value statement recognizes the importance of processes and tools but stresses that the interaction of talented individuals is of far more importance. Rigorous methodologies and their business process reengineering brethren place more emphasis on the process itself than people. Agile development reverses this trend. If individuals are unique, then processes should be melded to individuals and teams, not the other way around.

Similarly, while comprehensive documentation is not necessarily harmful, the primary focus must remain on the final product–working software. This means that every project team needs to determine, for itself, what documentation is absolutely essential for delivering working software.

No one can argue that following a plan is a good idea. No matter how carefully a plan is crafted, it becomes dangerous if it blinds you to change. And yet it is successful because the development team can be Agile enough to respond again and again to external changes.

The Agile movement is not anti-methodology; in fact, the authors sought to restore credibility to the concept of methodology. They wanted to restore a balance. They accepted modeling, but not in order to file some diagram in a dusty corporate repository. They accepted documentation, but not hundreds of pages of never-maintained and rarely used tomes. They planned, but recognized the limits of planning in a turbulent environment. Agile Software Development incorporates proven software engineering techniques, but without the overhead of traditional methodologies.

Great designs emerge from zero anticipatory design and continuous refactoring. Thus, we have to understand the limits before we can understand the balance points.

There are three fundamental questions to answer:

• What kinds of problems does agility solve best?
• What is agility?
• What are Agile Software Development Ecosystems (ASDEs)?

Problems characterized by change, speed, and turbulence are best solved by agility. Some people argue that good practices are good practices (pair programming, customer focus groups, or feature planning, for example) and therefore ASDEs should not be “limited” to a particular problem type. While true in part, the question is what problems Agile practices solve best, not just solve.

Agility is the ability to create as well as to respond to changes in order to profit in a turbulent business environment.

Agile organizations are nimble and flexible. An Agile organization also knows how to balance the structure and flexibility.

In our opinoin, the heart of ASDEs is a core belief in people — their individuality and their interactions. It’s impossible to discuss people and their ways of working together (ecosystem) without discussing values and principles. It’s impossible to discuss values and principles without also discussing assumptions about how organizations work, or should, work.

It’s impossible to compare Agile approaches with non-Agile approaches using a “methodology” as the only mechanism for comparison.