- What Is Agility?
- What Are Agile Software Development Ecosystems (ASDEs)?
- What Kinds of Problems Does Agility Solve Best?
- What Is the Future of Agile Software Development?
What Are Agile Software Development Ecosystems (ASDEs)?
I began writing a book about Agile software development methodologies, but I kept worrying about the word methodology because it didn't fit with the focal points of Agile developmentpeople, relationships, and uncertainty. Furthermore, by using the word methodology, Agile practices are instantly compared to traditional software development methodologiesthereby using the wrong measuring stick for comparison. So I began to use the term Agile software development ecosystem to describe a holistic environment that includes three interwoven components:
"Chaordic" perspective
Collaborative values and principles
Barely sufficient methodology
I use the term Agilists to identify those who are proponents of ASDEs.
Some people think that Agile means fewer processes, less ceremony, and briefer documents, but it has a much broader perspective, which is the primary reason for using the word ecosystem rather than methodology. Although fewer processes and less formality might lower development costs, they're not enough to produce agility. Focusing on people and their interactions and giving individuals the power to make quick decisions and to self-adapt their own processes are key to Agile ecosystems.
The word ecosystem conjures up a vision of living things and their interactions with each other. Within an organizational context, an ecosystem can then be thought of as a dynamic, ever-changing environment in which people and organizations constantly initiate actions and respond to each other's actions. The word ecosystem focuses us on the dynamic interactions of individuals and teams rather than on the static lines on organization charts.
"Chaordic" Perspective
To fully understand ASDEs, we need to understand each of the three components and how they relate to each other. First, Agilists share a view that organizations are chaordicthat every organization exhibits properties of both chaos and order that defy management through the use of linear, predictive planning and execution practices. Viewing organizations as chaordic means understanding that the predictability upon which traditional project management and development lifecycle practices are built is a root cause of dysfunctionality among customer, management, and development organizations. A chaordic perspective affects both how we respond to change and how we manage project teams and organizations.
In day-to-day project work, a chaordic perspective creates two outcomes that are 180 degrees out of sync with rigorous methodologies:
Product goals are achievable, but not predictable.
Processes can aid consistency, but they're not repeatable.
Although ASDEs involve careful planning, the fundamental assumption remains that in a turbulent environment, plans are not predictableat least at the level of project scope, schedule, and cost. Plans are hypotheses to be tested rather than predictions to be realized. However, the product goals of the business are achievable, in large part because Agile people adapt. They can "adapt" to an articulated vision and a schedule, scope, or cost goal through tradeoffs in the other two dimensions. And while process can aid people in working together, in volatile environments the idea of driving out process variation through measurement and correctionstatistical process controlbecomes an unworkable hypothesis. Changes that are the result of knowledge gained during the projectknowledge not discernable early in the projectrequire processes that can respond to change, not ones that attempt to eliminate it.
Peter Senge uses the term mental model to identify the perspective, set of assumptions, stories, and beliefs that each of us carries in our mind that provide a context for thinking (The Fifth Discipline: The Art and Practice of the Learning Organization, Currency/Doubleday, 1994). In organizations, the collective set of mental models defines an overall cultural context. Companies that are heavily sales-oriented differ from those that are heavily engineering-oriented. Companies whose driving strategy is customer intimacy differ from those whose driving force is product innovation. Companies whose mental model includes linearity, cause and effect, hierarchy, predictability, and control will operate very differently from those whose mental models include collaborative networks, emergence, decentralization of power, and acceptance of unpredictability. One is Newtonian, the other chaordic.
Collaborative Values and Principles
The second piece of the interconnected web that defines ASDEs is the statement of collaborative values and principles. While it's difficult to characterize the Agile Manifesto in one word, collaborative seems to be the best single adjective. Values and principles shape the ecosystem. Without a set of stated values and principles, an ecosystem is sterile, reflecting practices but not the people who interact within it.
A collaborative culture includes people and their relationships within a development team and with customers, management, and partnering teams within or external to their own company. Human dynamics, communications, and collaboration may be known as the "soft" sciences, but in practice, they may be the hardest to master. Principles and values help define a culturethe environment in which people want to work.
Barely Sufficient Methodology
The final component of an ASDE is methodology. The traditional definition of methodology includes things such as roles, activities, processes, techniques, and tools. Alistair Cockburn summarizes these components when he defines methodology as "the conventions we agree to"the ways in which people work together on a project (Agile Software Development, Addison-Wesley, 2001, ISBN 0-201-69969-9).
In The Social Life of Information, John Seely Brown and Paul Duguid (Harvard Business School Press, 2000) discuss the major differences between process (as used by the business process reengineering movement) and practice:
Processes are described in manuals; practices are what happen in reality.
Process centrists relegate people to second place; practice centrists place people first.
Process centrists focus on explicit (written down) knowledge, while practice centrists focus on tacit (internal) knowledge.
The ASDE model provides a practice-centered approach to methodology rather than a process-centered approach.
There are two reasons to pursue barely sufficient methodologies: value and innovation.
Streamlined methodologies concentrate on those activities that create value and ruthlessly eliminate nonvalue-adding activities. Programming usually adds value; process management often adds overhead. Bare sufficiency means keeping the former and eliminating the latter.
Innovation and creativity flourish in chaordic environments, not orderly ones. Barely sufficient methodologies are cauldrons for breeding innovation.
Methodology also relates to organizational model. Agile methodologies contain minimal processes and documentation and reduced ceremony (formality). Agile methodologies are labeled "barely sufficient" (Cockburn) or "a little bit less than just enough" (Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems [Dorset House, 2000]), or "minimal" (Bob Charette's Lean Development Guidelines). However, this streamlining of methodology isn't just based on reducing work effort, but more importantly is based on understanding the chaordic worldviewone in which emergent (innovative) results are best generated at the "edge of chaos," perched midway between chaos and order.
Practices (or techniques) are the lifeblood of methodology. Whether it's pair programming, Scrum meetings, customer focus groups, or automated testing, when carried out by talented and skilled individuals the practices of ASDEs produce results.