Home > Store

Agile Software Development Ecosystems

Register your product to gain access to bonus material or receive a coupon.

Agile Software Development Ecosystems


  • Sorry, this book is no longer in print.
Not for Sale


  • Copyright 2002
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 448
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-76043-6
  • ISBN-13: 978-0-201-76043-9

Traditional software development methods struggle to keep pace with the accelerated pace and rapid change of Internet-era development. Several "agile methodologies" have been developed in response -- and these approaches to software development are showing exceptional promise. In this book, Jim Highsmith covers them all -- showing what they have in common, where they differ, and how to choose and customize the best agile approach for your needs. Highsmith begins by introducing the values and principles shared by virtually all agile software development methods. He presents detailed case studies from organizations that have used them, as well as interviews with each method's principal authors or leading practitioners. Next, he takes a closer look at the key features and techniques associated with each major Agile approach: Extreme Programming (XP), Crystal Methods, Scrum, Dynamic Systems Development Method (DSDM), Lean Development, Adaptive Software Development (ASD), and Feature-Driven Development (FDD). In Part III, Highsmith offers practical advice on customizing the optimal agile discipline for your own organization. For all software developers, project managers, and other IT professionals seeking more flexible, effective approaches to developing software.

Sample Content

Online Sample Chapter

Agility in Software Development

Table of Contents



Finding a Balance.

Fundamental Questions.

What Kinds of Problems Does Agility Solve Best?

What Is Agility?

What Are Agile Software Development Ecosystems?

A Chaordic Perspective.

Collaborative Values and Principles.

A Barely Sufficient Methodology.

Changing Perspectives.


Book Organization and Conventions.

The Major Agile Ecosystems and Leaders.


Dynamic Systems Development Method (DSDM).

Crystal Methods.

Feature-Driven Development (FDD).

Lean Development (LD).

Extreme Programming (XP).

Adaptive Software Development (ASD).


The Agile Software Development Series.


1. The Change-Driven Economy.

Turbulence: Bubbles versus Trends.

Exploration versus Optimization.

Exploratory Projects.

Command-Control versus Leadership-Collaboration Cultures.

Thriving at the Edge.

2. IDX Systems Corporation.

The IDX Story.

An Agile Group in Action.

3. Agility.


Creating and Responding to Change.

Nimbleness and Improvisation.

Conformance to Actual.

Balancing Flexibility and Structure.

“Agile” Studies.

Product Development in Internet Time.

“Heavy” Agile Projects.

Agile Software Development Ecosystems.


4. Kent Beck.


5. Deliver Something Useful.

HAHT Commerce, Inc.

Customer Delivery Principles.

Delivering Customer Value.

Voice of the Customer.

Working Software.

Frequent Delivery.

Work Together Daily.

Practices That Deliver Useful Features.

The Customer-Developer Interface.

Proxy Users.

Domain-Knowledgeable Developers.

Contracts: Shaping Customer Relationships.

Obviously It's Not Obvious.

6. Alistair Cockburn.


7. Rely on People.


Who Are You Calling Average?

Trust, Mistrust, and Communications.

Talent, Skill, and Process.

Process versus Skill.

Artifacts and Information Flow.

Innovation and Creativity.

The Fall and Resurrection of Programming.

Software through People.

8. Ken Schwaber.


9. Encourage Collaboration.

The Modern Transport Team at ITL.

A Cooperative Game of Invention and Communication.

Practice versus Process.

Documentation Is Not Understanding.

The Dimensions of Collaboration.

Real Teams.

10. Martin Fowler.


11. Technical Excellence.

The PDFS Team at Generali Group.

Agile Is Not Ad Hoc.

Removal of Defects.

Focus on Code.

Simple Design.

Big Bang versus Incremental.

Modeling and Abstraction.

Domain Recognition.

Documentation versus Conversation.

Specialists versus Generalists.

Quality versus Speed.

Establishment versus Anti-establishment.

Values and Principles.


12. Ward Cunningham.


13. Do the Simplest Thing Possible.

The Survey Controller Team at Trimble Navigation.


The Three Faces of Simplicity.

Simplicity as Minimalism.

Simplicity as Good Design.

Simplicity as Generative Rules.

Adapting Simple Rules.

A Final Note on Simplicity.

14. Jim Highsmith.
15. Be Adaptable.

The Mustang Team at Cellular, Inc.

The Great Divide: Predictability or Adaptability.

Our Changing Business Ecosystem.

Embracing Change.

Facilitate Change.

View Rework as a Virtue.

Control Final Components.

Constant Feedback at Multiple Levels.

Multiple Process Levels.

Balancing Adaptation with Anticipation.

Putting Lipstick on a Bulldog.

The Cost of Change.

Conform to Actual: Measuring Success.

Adaptability Is a Mindset.

16. Bob Charette.



17. Scrum.

The Scrum Process.

Pre-Sprint Planning.


Post-Sprint Meeting.

Monitoring Progress.

Scrum's Contributions.

18. Dynamic Systems Development Method.

Arie van Bennekum.

DSDM Principles.

The DSDM Process.

DSDM's Contributions.

19. Crystal Methods.

Methodology Design Principles.

The Crystal Framework.

Crystal Method Example: Crystal Clear.

Crystal's Contributions.

20. Feature-Driven Development.

The Singapore Project.

The FDD Process Model.

Process 1: Develop an Overall Model.

Process 2: Build a Features List.

Process 3: Plan by Feature.

Process 4: Design by Feature.

Process 5: Build by Feature.

Beyond the FDD Process Description.

Conceptual Similarities and Differences.

FDD's Contributions.

21. Lean Development.


The Strategic Foundation of Lean Development.

Lean Development's Origins.

What Is Lean Development?

The Lean Development Environment.

Lean Development's Contributions.

22. Extreme Programming.

XP--The Basics.

XP Practices.

Values and Principles.

XP's Contributions.

23. Adaptive Software Development.

A Change-Oriented Life Cycle.

The Basic ASD Life Cycle.

Speculate: Initiation and Planning.

Collaborate: Concurrent Feature Development.

Learn: Quality Review.

Leadership-Collaboration Management.

ASD's Contributions.


24. Articulating Your Ecosystem.

Opportunity and Problem Domains.

Cultural Domain.

The Competence Culture.

The Control Culture.

The Collaboration Culture.

The Cultivation Culture.

Cultural Relativism.

Matching Methodology to Opportunity and Culture.

Methodology Selection.

Articulate Values and Principles.

25. Designing Your Agile Methodology.

Methodology Expectations.

Methodology Elements and the System of Practices.

Keep It Simple.

Practices and Principles

Methodology Design Principles.

Frameworks, Templates, and Scenarios.

Phase and Gate Life Cycle Frameworks.

Problem Domain Templates.


Collaborative Methodology Design Steps.

Evaluate Project Objectives and Characteristics.

Design a Methodology Framework, Templates, and Scenarios.

Customize Templates to the Team.

A Customizing Approach.

Adapt the Template to Use.


Methodology Scaling: Balancing Optimizing and Adapting Elements.

Collaboration Scaling.

Architecture and Integration Scaling.

Agile Methodologies for the Enterprise.

26. The Agile Metamorphosis.

Chaordic Perspective.

Collaborative Values and Principles.

Barely Sufficient Methodology.

The Agility Ratings.

Final Thoughts.

Index. 0201760436T04092002


From February 11 to 13, 2001, at the Lodge at Snowbird ski resort in the Wasatch Mountains of Utah, 17 people met to talk, ski, relax, and try to find common ground. What emerged was the Agile Software Development movement. Representatives from Extreme Programming (XP), Scrum, the Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal Methods, Feature-Driven Development (FDD), Pragmatic Programming, and others sympathetic to the need for an alternative to document-driven, rigorous software development processes convened. What this meeting produced--The Manifesto for Agile Software Development, signed by all 17 of the participants--was symbolic. It declares that:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

This value statement has a number of fascinating aspects, not the least of which was getting 17 people to agree to it. Although this was a group of experienced and recognized software development "gurus," the word uncovering was selected to indicate that the authors don't have all the answers and don't subscribe to the silver-bullet theory.

The phrase "by doing it" indicates that the authors actually practice these methods in their own work. Ken Schwaber told the story of his days of selling tools to automate comprehensive, "heavy" methodologies. Impressed by the responsiveness of Ken's company, Jeff Sutherland asked him which of these rigorous methodologies he used for internal development. "I still remember the look on Jeff's face," Ken remarked, "when I told him, ‘None. If we used any of them, we'd be out of business.'" The authors want to help others with Agile practices and to further our own knowledge by learning from those we try to help.

The value statements have a form. In each statement, the first segment indicates a preference, while the latter segment describes an item that, while important, is of lesser priority. This distinction lies at the heart of agility, but simply asking people to list what's valuable doesn't flesh out essential differences. Roy Singham, CEO of ThoughtWorks, put it well when he said that it's the edge cases, the hard choices, that interest him. "Yes, we value planning, comprehensive documentation, processes, and tools. That's easy to say. The hard thing is to ask, ‘What do you value more?'" When push comes to shove--and it usually does--something must give, and we need to be clear about what stays and what gives.

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 process than people. Agile development reverses this trend. If individuals are unique, and we believe they are, 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 to delivering working software. Working software tells the developers and sponsors what they really have in front of them--as opposed to promises of what they might have in front of them. Working software can be shipped, modified, or scrapped, but it is always real.

Contract negotiation, whether through an internal project charter or an external legal contract, isn't a bad practice, just a seriously insufficient one. Customers want a product that conforms to their needs--at the time of delivery. "Contract negotiation encourages the addition of buffers contingency," says colleague Ron Holliday. "This makes projects take even longer, drives up costs, and reduces responsiveness to change. A collaborative arrangement is a team effort between customer and supplier to deliver the best possible solution." Contracts and project charters provide boundary conditions within which the parties can work, but only through ongoing collaboration can a development team hope to understand and deliver what the client wants.

No one can argue that following a plan is a good idea--right? Well, yes and no. In a world of business and technology turbulence, scrupulously following a plan can have dire consequences, even if it's executed faithfully. However carefully a plan is crafted, it becomes dangerous if it blinds you to change. As you will see in several of the case studies presented in this book, few, if any, of the projects delivered what was planned for in the beginning. And yet they were successful because the development team was Agile enough to respond again and again to external changes. In the Information Age, planning is important, but accepting that deviations from any plan are "normal" is even more important.

The meeting at Snowbird was incubated at a spring 2000 gathering of Extreme Programming leaders organized by Kent Beck. At that meeting in Oregon, a few "outsiders" but "sympathizers," such as myself, were invited, and attendees voiced support for a variety of "light" methodologies. During 2000, a number of articles referenced the category of "light" or "lightweight" practices. In conversation, the soon to be "Agile" authors didn't like the moniker "light," but it stuck at that time.

In September 2000, "Uncle Bob" Martin of Object Mentor in Chicago started what was to become the Agile ball rolling with an email: "I'd like to convene a short (two-day) conference in the January to February 2001 time frame here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room. All of you are invited, and I'd be interested to know who else I should approach." Bob set up an online group site, and the discussions raged. Early on, Alistair Cockburn weighed in with an epistle that identified the general disgruntlement with the word "light": "I don't mind the methodology being called light in weight, but I'm not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting. It somehow sounds like a bunch of skinny, feeble-minded lightweight people trying to remember what day it is."

The fiercest debate was over location! There was serious concern about Chicago in wintertime--cold and nothing fun to do. Someone suggested Snowbird, Utah--cold, but fun things to do, at least for those who ski on their heads, as Martin Fowler tried on the first day. Someone else mentioned Anguilla in the Caribbean--warm and fun, but time consuming to get to. In the end, Snowbird and skiing won out.

The Agile Manifesto value statements represent a deeper theme that drives many, but not all, of the Manifesto's authors. At the close of the two-day meeting, Bob Martin joked that he was about to make a "mushy" statement. Although tinged with humor, no one disagreed with Bob's sentiments--that we all felt privileged to work with a group of people who held a set of compatible values, based on trust and respect for each other, promotion of organizational models based on people, and the desire to build collaborative communities in which to work. At the core, I believe Agile developers are really about mushy stuff--about delivering products to customers while operating in a vibrant, sustaining workplace. So in the final analysis, the meteoric rise of interest in--and criticism of--Agile Software Development is about the mushy stuff of values and culture.

For example, I think that, ultimately, XP has mushroomed in use and interest not because of pair programming or refactoring but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations. Kent Beck tells the story of an early job in which he estimated a programming effort to be six weeks for two people. After his manager reassigned the other programmer at the beginning of the project (effectively halving the resources), Kent completed the project in twelve weeks--and felt terrible! The boss, of course, harangued Kent throughout the second six weeks. Somewhat despondent because he was such a "failure" as a programmer, Kent finally realized that his original estimate of six weeks was extremely accurate--for two people--and that his "failure" was really his manager's failure to take the responsibility for removing project resources. This type of situation goes on every day with individuals who don't want to make hard tradeoff decisions, so they impose irrational demands.

The Agile movement is not anti-methodology; in fact, we seek to restore credibility to the concept of methodology. We want to restore a balance. We accept modeling, but not in order to file some diagram in a dusty corporate repository. We accept documentation, but not hundreds of pages of never-maintained and rarely used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of FDD or Scrum or any of the other Agile approaches as "hackers" are ignorant of both the approaches and the original definition of the term hacker--a programmer who enjoys solving complex programming problems, rather than one who practices either ad hoc development or "cracking." Agile Software Development incorporates proven software engineering techniques, but without the overhead of traditional methodologies.

The Agile Alliance was born in early 2001, but the history of the various approaches and the people who developed them goes back 10 to 15 years. This book describes these practices and the principles behind them, but more important, it delves into the people--the people who are developing the practices and the people who use them to deliver business value to their customers.

Finding a Balance

The left side of the Agile Manifesto value statements indicates what Agilists consider more important than the items on the right side. This should not be construed as indicating that tools, process, documentation, or contracts are unimportant. There is a tremendous difference between one thing being more or less important than another and being unimportant. Judicious use of tools is absolutely critical to speeding software development and reducing its costs. Contracts are one vital component to understanding developer-customer relationships. Documentation, in moderation, aids communication, enhances knowledge transfer, preserves historical information, and fulfills governmental and legal requirements.

But Agilists take a certain perspective on these topics. Try this exercise. For each of the Manifesto value statements, construct two questions along the lines of the following:

  • Could we have a successful project by delivering documentation without working software?
  • Could we have a successful project by delivering working software without any documentation?

By looking at these two end points, we can better grasp relative importance. Although there has to be a balance--documentation and working software, contracts and collaboration, responsiveness and planning, people and process--we have to delineate the extremes, the end points, so that organizations, teams, and individuals can find their own balance points. If we start out trying to find the middle ground, we never will.

One of the great contributions of XP's "extremoes"--Kent Beck, Ron Jeffries, and Ward Cunningham--is that they have staked out positions that have stirred debate in ways that taking moderate positions never would. When Ron says, "Great designs emerge from zero anticipatory design and continuous refactoring," he is challenging himself, and us, to rethink our assumptions about software development. We have to understand the limits before we can understand the balance points.

So although I realize the value of documentation, contracts, plans, and processes, there are numerous sources of material about these subjects. My intention is to identify and define Agile Software Development, to articulate its practices and principles, so you can make your own decision about where on the spectrum you, or your organization, need to be.

Fundamental Questions

There are three fundamental questions that this book answers: (1) What kinds of problems does agility solve best? (2) What is agility? and (3) What are Agile Software Development Ecosystems (ASDEs)?

What Kinds of Problems Does Agility Solve Best?

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 asks what problems Agile practices best solve, not just solve. So, while XP, Crystal, or Scrum can surely be used for a wide range of projects, they are particularly relevant to extreme or complex projects--those that have an accelerated time schedule combined with significant risk and uncertainty that generate constant change during the project.

As the level of change caused by rapidly evolving technology, business models, and products increases and the need for delivery speed accelerates, ASDEs' effectiveness increases quickly over rigorous methodologies.

What Is Agility?

Agility, like any other complex concept, has a number of definitions, but for me, the most clearly focused definition is

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Rather than shrink from change, Agile organizations harness or embrace change by being better than competitors at responding to changing conditions and by creating change that competitors can't respond to adequately. However, companies must determine what level of agility they require to remain competitive. Agility is only an advantage relative to competitors--a copper mining company doesn't need to be as agile as a biotechnology firm.

Other aspects of agility are also important: nimbleness or flexibility on the one hand, and balance on the other. Agile organizations are nimble (able to change directions quickly) and flexible (able to see how things that worked for them last week may not work as well next week). An Agile organization also knows how to balance structure and flexibility. If everything changes all the time, forward motion becomes problematic. Agile organizations understand that balancing on the edge between order and chaos determines success.

What Are Agile Software Development Ecosystems?

I began writing this 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 development--people, relationships, and uncertainty. Furthermore, by using the word "methodology," Agile practices are instantly compared to traditional software development methodologies--thereby using the wrong measuring stick for comparison. So I use the term "Agile Software Development Ecosystem" to describe a holistic environment that includes three interwoven components--a "chaordic" perspective, collaborative values and principles, and a barely sufficient methodology--and 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 are 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 American Heritage Dictionary defines ecosystem as "organisms and their environment: a localized group of interdependent organisms together with the environment that they inhabit and depend on." The Oxford English Dictionary extends this definition to include a constant interchange within the system, including both organic and inorganic elements. The word methodology conjures up a vision of things--activities, processes, tools. These are not inconsequential elements, but incomplete ones. 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.

A 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 chaordic--that 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 life cycle practices are built is a root cause of dysfunctionality between customer, management, and development organizations. A chaordic perspective impacts 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 they are not predictable.
  • Processes can aid consistency, but they are not repeatable.

Although ASDEs involve careful planning, the fundamental assumption remains that plans, in a turbulent environment, are not predictable, at 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. Second, while process can aid people in working together, in volatile environments the idea of driving out process variation through measurement and correction--statistical process control--becomes an unworkable hypothesis. Changes that are the result of knowledge gained during the project, knowledge not discernable early in the project, require processes that can respond to change, not ones that attempt to eliminate it.

As Martin Fowler points out, the two fundamental characteristics of ASDEs are their focus on adaptability rather than predictability and on people rather than process (Fowler 2000). As you read through this book, you will see just how fundamental--and challenging to the status quo--these two principles really are. Being Agile means accepting that outcomes are not predictable and that processes are not repeatable. It even implies that as process repeatability increases, project predictability decreases.

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 (Senge 1990). 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 one whose mental model includes collaborative networks, emergence, decentralization of power, and acceptance of unpredictability. One is Newtonian, the other chaordic.

A chaordic perspective draws on a complex adaptive systems model in which decentralized, independent agents (each of us) interact in self-organizing ways, guided by a set of simple, generative rules that create complex, emergent results. This perspective is examined in detail in my book Adaptive Software Development (Highsmith 2000) and is explicitly embraced in the philosophies of Agilists Ken Schwaber, Bob Charette, and Kent Beck.

XP provides an example of how methodology and culture fit together. At one level, XP is defined by a system of practices--pair programming, test-first development, refactoring, coding standards. But the values and principles of XP define a collaborative culture--how developers work together with customers, how individuals interact and treat each other as human beings.

Collaborative Values and Principles

The second piece of the interconnected web that defines ASDEs is the statement of collaborative values and principles. While it is 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 culture--the environment in which people want to work.

A 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. In The Social Life of Information, John Seely Brown and Paul Duguid (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, rather than a process-centered, approach to methodology.

There are two reasons to pursue barely sufficient methodologies: value and innovation. Streamlined methodologies concentrate on those activities that create value and ruthlessly eliminate non-value-adding activities. Programming usually adds value; process management often adds overhead. Bare sufficiency means keeping the former and eliminating the latter. Second, 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), or "minimal" (Charette). However, this streamlining of methodology isn't based just on reducing work effort but, more important, it is based on understanding the chaordic world view--one 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, the practices of ASDEs, carried out by talented and skilled individuals, produce results.

Changing Perspectives

In the software profession, we've used the words "methodology" and "process" for so long that they roll off the tongue and the pen without trouble. "Ecosystem" will take getting used to, but then, that's why I'm using the word--to foster a different perspective. "There is accumulating evidence that corporations fail because the prevailing thinking and language of management are too narrowly based on the prevailing thinking and language of economics," says Arie De Geus (1997). "They forget that their organizations' true nature is that of a community of humans."

To change thinking, we must change the language we use, so I use the word "ecosystem" to change our thinking about how software projects should be viewed. A chaordic perspective, a collaborative set of values and principles, and a barely sufficient methodology all combine and interact to form an Agile ecosystem. We cannot separate the three, at least in my mind, and I think most Agilists would agree. One could have a streamlined methodology but a linear, Newtonian view of organizations, and the result would not be Agile. One could have a streamlined methodology but a hierarchical, control-based work culture, and it would not be Agile. One could have a collaborative, people-oriented work culture but a rigid, predictive approach to planning and managing projects, and it would not be Agile. Agility requires all three.

The ultimate objective of this book is to describe new ways of working together to deliver business value to software customers. 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 do, or should, work. It's impossible to compare Agile approaches with non-Agile approaches using "methodology" as the only mechanism for comparison.

In closing, I need to state that I don't speak for anyone in the Agile community other than myself. I may interpret what Ken Schwaber says about Scrum, what Jeff De Luca says about FDD, or what Alistair Cockburn says about Crystal Methods, but they are my interpretations. In making generalizations about ASDEs, I'm sure I've made statements that would generate disagreement from 1 or more of the other 16 authors of the Agile Manifesto. However, I have talked to, corresponded with, or worked with all these authors, so although they are my own interpretations, they also reflect a deep sense of being part of, and contributor to, this community.

Although 17 individuals authored the Agile Manifesto, thousands support this effort. Many, many individuals have signed the Manifesto Web page, and an array of Web sites prominently display the statement "We support the Agile Manifesto." Agilists have stirred a healthy debate within the software development and project management communities. I hope this book will contribute to that debate and encourage others to join in it.

Jim Highsmith
Salt Lake City, Utah



The 1990s were the Decade of Process for IT. We prostrated ourselves before the CMM and ISO. We sought not just perfection in the way we built software, but total predictability. We concluded that it wasn't enough just to do things right; we also had to "call our shot"--to say in advance exactly what we intended to do, and then do exactly that. Nothing more and nothing less. We were determined (in CMM terms) to "plan the work and work the plan."

A big part of our process focus in the 1990s had to do with our obsession with all things Japanese. Think back to 1990 and remember your own take on the subject at that time. There was a general malaise and a feeling that the West had lost its momentum and the Japanese had a lock on the future. After all, they worked harder, stayed later, had far more rigorous discipline, and were regularly achieving levels of quality that the rest of the world could only dream of. The Japanese phenomenon, the relentless advance of the "Pacific Tiger," was all the talk that year. If we're going to survive, we thought, we had better become more like the Japanese. And so we moved to a more Japanese kind of rigor and process.

But the 1990s were not kind to Japan. By the end of the decade, the Japanese economy had been in a slump that was as bad as, and had lasted as long as, the Great Depression. Somehow, hard work, discipline, efficiency, and rigor--the very qualities that had been essential in the 1980s--were not a winning combination for the 1990s. What mattered in the 1990s was being able to turn on a dime. The Internet changed everything, and only those who were ready to change quickly with it would prosper. Agility: 1; everything else: 0.

Similarly, the process obsession did not stand its adherents in very good stead. The list of companies most successful at climbing up the CMM ladder early in the decade reads like a Who's Who of downsizing by the end. Process rigor was simply not the right recipe for an era in which everything was changing. Predicting in advance what your every step would be ended up seeming like a dumb obsession. What sense does it make to predict your steps in advance when you're not even sure where you're headed?

Today the era of fat process is over. As Jim Highsmith has said, "Thin is in." To optimize for speed and responsiveness, we need to put process on a diet. We need to shed paperwork and bureaucratic burden, eliminate endless code inspections, and invest in our people so they can steer themselves sensibly through the chaotic maze that is a modern-day IT project. This is the genesis of the Agile approaches to software development.

Jim Highsmith has put all this together into a kind of survey introduction to the Agile methodologies. He has had the good sense not just to present this as a discussion of a concept, but to tell it as a story. As in any good story, it is the people who matter most. And so he tells us about Agile approaches by telling us about their principal advocates and inventors, people like Kent Beck, Alistair Cockburn, Martin Fowler, and the other "light methodologists." These are the minds that are changing how IT gets done. Their story is what Agile Software Development Ecosystems is all about.

Tom DeMarco
Camden, Maine


levels of, 157
technical excellence and, 157-160
transition from, to concrete implementation, 101-103
Acceptance tests, 69
agility ratings and, 378
ASD and, 202, 213, 318, 319
balancing, with anticipation, 214-216
Cellular, Inc. and, 199-203
changing business ecosystems and, 206-208
chaordic perspectives and, 197, 201-202, 219, 227
chaos theory and, 196-197
embracing change and, 208-214
measuring success and, 221-226
methodology design and, 335-336, 350
as a mindset, 226-227
overview of, 199-227
plans and, 214-216, 222-223, 225-226
simplicity and, 184, 187-188
Adaptive Software Development. See ASD (Adaptive Software Development)
Adaptive Software Development: A Collaboration Approach to Managing Complex Systems, (Highsmith), xxvi, xxxvii, 100, 191, 194, 196-197, 265, 309, 358, 379
ADM (Advanced Development Methods), 106
Aesthetics, of code, 46, 49
AgileAlliance Web site, xxxvii
Agile Competitors and Virtual Organizations (Goldman, Nagel, and Preiss), 27, 28
Agile Management Practice (Cutter Consortium), 191
Agile Manifesto, xvii-xviii, xx-xxii, xxviii, 58, 92-93
Agile Modeling (AM), 159-160
Agile Project Management service (Cutter Consortium), 16
Agile Software Development (Cockburn), 80
basic description of, xxiii, 27-31
conformance to business value and, 32-33
cost of, mistakes as, 30
Dove on, 27
improvisation and, 30-31
nimbleness and, 30-31
problems best solved by, xxii
AM (Agile Modeling), 159-160
Ambler, Scott, 158, 159
Analysis Patterns: Reusable Object Models (Fowler), 133, 137
Anti-establishment style, 166
Archer, Rowland, 55
as a form of abstraction, 158
scaling, 363-366
ASD (Adaptive Software Development), xxxiv, 265, 368
adaptation and, 202, 213, 318, 319
basic description of, 309-319
Cockburn on, 80, 368
contributions of, 319
customer-developer interface and, 67, 68
encouraging collaboration and, 115, 120
FDD and, comparison of, 282
focus groups, 67, 69
generative rules and, 184-187
Leadership-Collaboration management and, 317-319
life cycle, 313-316
methodology design and, 340
simplicity and, 180-181, 184-187
Web site, xxxvii
ASDEs (Agile Software Development Ecosystems). See also specific types
basic description of, xxiii-xiv
as practice-centered, xxviii
criticisms of, 97, 150, 256
major, xxxi-xxxvi
problems best solved by, xxii
Austin, Rob, 37-39, 75
"Average people," use of the phrase, 92-93
Axelrod, Robert, 199


Backlog features, xxxii, 69, 243-245, 247-249
Bayer, Sam, 55-58, 63, 194-195, 309
creative collaboration and, 175-176
on trust, 380
Beck, Kent, xix-xx, xxii, xxvi, xxix, xxxiii
on communication, 142
Cunningham and, relationship of, 170-176
deeply-held beliefs of, 204
on the design process, 154, 183
Extreme Programming Explained: Embrace Change, 4-5, 46, 143, 220, 298, 309, 379
on feedback, 305
on methodology, 62
on pair programming, 302-303
Planning Extreme Programming, 46, 133, 136
on processes, 241-242
on refactoring, 301-302
Scrum and, 241-242, 244-245, 248
on small releases, 299
on software teams, 93
technical excellence and, 150, 154, 160
on working with customers, 76
on XP, 45-52, 297-298
Beedle, Mike, xxxii, 105, 244, 358
Bennekum, Arie van, xxxii, 251-253
Big-bang approach, 156-157
Boehm, Barry, 220-221, 313
Bolles, Jack, 89-92, 103, 142
Bonabeau, Eric, 186
Bowling Alley market phase, 324, 327, 330-332
Brown, John Seely, xxvi, 121
Brown, Shona, 32, 201, 214-215
Buckingham, Marcus, 95-96


CAS (complex adaptive systems) theory, 48, 217, 218
CASE tools, 106, 143, 194, 289
CCBs (change control boards), 208-210
Change. See also Dynamism
accelerated pace of, 4, 13
adaptation and, 206-214
ASD and, 310-313
balancing structure with, 33-34
in business ecosystems, 206-208
cost of, 220-221
creating and responding to, 29-30, 33-34
-driven economy, 3-17
embracing, 4-17, 208-214
facilitating, 209-210
LD and, 292-293
management, 206-207
orders, 74
risk entrepreneurship and, 10
XP and, 298
Chaordic perspective, xxiv-xxvi, xxviii
adaptation and, 197, 201-202, 219, 227
agility ratings and, 377, 378
ASD and, 317
basic description of, 368-372
Scrum and, 242
Chaos (Gleick), 47
Chaos theory, 196, 318
adaptation and, 215, 217, 219, 227
improvisational businesses and, 215
LD and, 290
Scrum and, 241
Charette, Bob, xxvi, xxxiii, 27-30, 40, 120, 285
on baselines, 290
on CMM, 236-237
on competitive advantage, 286-287
on documentation, 289-290, 342
on front-end architectural components, 158
interview with, 229-237
on risk entrepreneurship, 10, 286-288, 296
scaling issues and, 358
on success factors for LD, 291-292
on the "virtuous circle" created by LD, 295
Checklists, processes and, confusion between, 97-98
Christensen, Clayton, 34, 206-207
Chrysler Comprehensive Compensation system (C3 project), 45, 48-49, 135-143, 174-175, 298
CIO (magazine), 248
CMM (Capability Maturity Model), 59, 91, 326
barely-sufficient methodologies and, 376, 378
Charette on, 236-237
LD and, 289, 291
publications, 165, 166
quality and, 306
simplicity and, 189
technical excellence and, 165, 166
versions of, 165
Coad, Peter, xxxiii, 269-272
Cockburn, Alistair, xix, xxvi, xxviii-xxix, xxxii, 40, 91
on ASD, 80, 368
on communication, 120, 127
on the cost of removing defects, 221
on Crystal Methods, 79-88, 261-262, 265, 267-268
on embellishment, 52
FDD and, 284
heavy Agile projects and, 36
on increasing personal interaction, 99
on incremental development, 80, 81, 82
on methodology, 52, 79-88, 323
Musashi and, 180
PDFS team and, 147-148
on software development as a a game, 379
Surviving Object-Oriented Projects, xxxvi, 80, 82, 159
technical excellence and, 160
on working with customers, 111
Writing Effective Use Cases, xxxvi, 80
Code. See also Defects; Testing
aesthetics of, 46, 49
compiling, 47, 101
focus on, 152-154
Coffman, Curt, 95-96
Coldewey, Jens, 145-149
Collaboration. See also Leadership-Collaboration management model
agility ratings and, 378
ASD and, 309-310, 311-313, 315
communication and, 120-121
cultural, 127-129, 328
decision-making and, 127-129
dimensions of, 127-129
DSDM and, 258
encouraging, 115-131
Fowler on, 142
invention and, 120-121
LD and, 291
methodology design and, 341-343, 350-355, 361-363
Orr on, 309
practices, 339
principle of, 355, 372-375
technical excellence and, 149
values related to, xxvi, 372-375
Collective ownership, 120, 130, 303, 341, 362
Command-Control management style, 6, 15-17, 324, 379
adaptation and, 219, 224
ASD and, 317
hierarchical nature of, 219
FDD and, 284
mistrust and, 94
Scrum and, 242
Crystal Methods and, 265
documentation versus, 124-126, 161-162
encouraging collaboration and, 120-121, 125-127
face-to-face, relying on, 120, 127
Fowler on, 143
methodology design and, 342
modeling and, 158, 160
"software through people" motto and, 103
technical excellence and, 158, 160
trust and, 93-95
XP and, 304-305
Competence culture, 327
Complexity: The Emerging Science at the Edge of Order and Chaos (Waldrop), 196
Complexity theory, 196, 309-310
Computer Society of India, 115
ComputerWorld, 16
Consistency, as a goal, 337
Constantine, Larry, 97, 267, 301
Continuous integration, 303
Contracts, xvii, xviii-xix, 72-76
delivered-feature, 74-76
fixed-price, 73, 75
fixed-schedule, variable-scope, 74
Control. See also Command-Control management style
culture, 241, 327
of projects, shifting, 59-60
"Controlled Chaos: Living on the Edge" (Schwaber), 241
Courage, importance of, 305-306
adaptation and, 219
approaches to processes and, 96, 99-100
origins of, 371
paramount importance of, 4
simplicity and, 184-186
XP and, 304-305
Criticality, 351, 352
Cross-application integration, 61
Crouching Tiger, Hidden Dragon (film), 31
Crystal Clear (Cockburn), xxxvi
Crystal Clear method, xxxvi, 145, 147, 149, 265
examples of, 266-267
methodology design and, 347, 349, 365
problem domain templates and, 357
Crystal Methods, xvii, xxii, xxviii. See also Crystal Clear method
barely-sufficient methodologies and, 376, 377
basic description of, xxxii, 261-268, 368
Cockburn on, 79-88, 261-262, 265, 267-268
collaborative culture and, 17
contributions of, 267-268
customer-developer interface, 68-69
development of, 80-81
examples of, 266-267
family of, diagram of, 264
framework for, 263-265
methodology design and, 262-263, 365
simplicity and, 181, 188-189
technical excellence and, 145-150, 160
Web site, xxxvii
Crystal Orange, 82, 263
Crystal Red, 265, 268, 365
Cultivation culture, 328
Cultural relativism, 79-80, 85, 328-329
Cunningham, Ward, xxii, 45
adaptation and, 204
Beck and, relationship of, 170-176
development of XP by, xxxiii, 169-175
emphasis of, on technical mastery, 46
Customer(s). See also Focus groups
conformance to business value and, 32-33
constant involvement of, 66-67
contracts with, xvii, xviii-xix, 72-76
delivery principles and, 58-67
-developer interface, 68-69, 71, 72
-driven development, 40
handling conflict with, 76
on-site, with XP, 67, 68-69, 257, 304
value, delivering, 58-60, 66, 291
voice of, 61-63
Customization, mass, 28
Cutter Consortium, 16, 191
IT Journal, 241
Summit conference (2001), 76


Datamation magazine, 300
Data Structured Software Maintenance (Higgins), 211-212
Data Structured Systems Development, 169
David Consulting Group, 357-358
DeCarlo, Doug, 226-227
adaptation and, 188, 219, 227
methodology design and, 344-345
process, collaborative, 127-129
Defects. See also Testing
defining quality and, 306
removal of, 151-152, 220-221
number of, production speed and, relationship between, 163-165
frequent, 65-66
principles, 58-67
time, technical excellence and, 155, 156
Dell Computer, 37, 205, 232
De Luca, Jeff, xxviii, 269-272, 281-283
the development of FDD and, xxxiii
Java Modeling in Color with UML, 159, 269, 279
methodology design and, 341, 358
scaling issues and, 358
DeMarco, Tom, 14, 221
and Build iteration, 254-256, 258
Beck's criteria for, 183
by features, 277-278
of methodologies, 262-263, 335-366
responsibility-driven, 81-82
simplicity as good, 183-184, 340-341, 355
courage and, 305-306
formality and, difference between, 142-143
importance of, 14-15
methodology design and, 343, 359-360
as a requirement of agility, 21
scaling and, 359-360
Discovery workshops, 56
Dixon, Nancy, 98, 123, 125
LD and, 289-290, 292
methodology design and, 342
minimalist, 126
scaling and, 359, 361
shifting attention from, to discussion, 124-126
simplicity and, 182
technical excellence and, 161-162
zero-based, 161
Domain-knowledgeable developers, 70-72
Dotcom businesses. See also eBusiness; eCommerce
adaptation and, 207
eBusiness revolution and, 6-7
lack of discipline among, 14
rise and fall of, 4-8
DSDM (Dynamic Systems Development Method), xvii, 64
barely-sufficient methodologies and, 376, 377
basic description of, xxxii, 251-260
Consortium, 258
contributions of, 259-260
development of, xxxii
FDD and, comparison of, 284
methodology design and, 352
principles, 253-254, 259
process, 254-258
simplicity and, 185
Duguid, Paul, xxvi, 121-122
Dynamism, 5-6, 201-204, 290. See also Change


Early Market phase, 324, 327, 329-331
eBusiness. See also eCommerce; Dotcom businesses
adaptation and, 207
domain-knowledgeable developers and, 71
DSDM and, 260
revolution, 6-7
eCommerce, 325, 352. See also eBusiness; Dotcom businesses
adaptation and, 207
domain-knowledgeable developers and, 71
DSDM and, 260
Ecosystems. See also ASDEs (Agile Software Development Ecosystems)
agility ratings for, 377-378
articulating, 323-334
cultural domains and, xxvi, 326-329
emphasis on, 40
opportunity domains and, 324-325
problem domains and, 324-325
selection of, 331-333
use of the term, xxiv, xxvii-xxviii
Eisenhardt, Kathleen, 32, 177, 201, 214-215
Elbow, Peter, 369, 371
Electrical engineering, 152-154, 192
Emergent properties, 184-185
Employees. See also Individuals; Teams
morale of, 16, 175
overtime worked by, 303-304
Empowerment, 218, 219
Entrepreneurship, 10, 286-288, 296
ERP (enterprise resource planning), 37, 56-57, 292
Lean Development and, 232
methodology design and, 351, 352
Evolutionary theory, 207
Evolution of Useful Things, The (Petroski), 371
e-volve! (Kanter), 216
Excellence, technical, 145-167
abstraction and, 157-160
agility ratings and, 378
anti-establishment style and, 165-166
big-bang approach and, 156-157
defect removal and, 151-152
documentation and, 161-162
domain recognition and, 160-161
focus on code and, 152-154
generalists and, 162-163
incremental approach and, 156-157
methodology design and, 340
modeling and, 157-160
quality and, 150-151
simple design and, 154-156
specialists and, 162-163
testing and, 148-149, 152, 164-165
Exploration. See also Exploratory Projects
adaptation and, 222
balancing structure and, 34
conformance to business value and, 33
inefficiency of, 41
LD and, 296
nimbleness and, 30
oil, 9-10, 12, 38, 41
optimization versus, 9-12
product development and, 35
staging strategies and, 38
technical excellence and, 149
venture capital model and, 75
Exploratory Projects, 12-15. See also Exploration
Extreme Programming (XP), xvii, xx, xxii, xix
adaptation and, 211-213, 215, 222
barely-sufficient methodologies and, 376
basic description of, xxxiii, 297-306
Beck on, 45-52, 297-298
change-driven economy and, 4-5
coding standards, 304
collaborative culture and, 17
contributions of, 306-307
criticisms of, 167
Cunningham on, 169-175
development of, 46
documentation and, 124-125
encouraging collaboration and, 124-125, 130
as an example of how methodology and culture fit together, xxvi
extension of, in scope, 50-51
FDD and, comparison of, xxxiii, 281-282, 284
40-hour practice, 303-304, 305
Fowler on, 133-134, 137-142, 144
future of, 175
Immersion Workshops, 183, 297
Jeffries on, 62
methodology design and, 340-342, 349, 355
notoriety of, 140
on-site customers, 67, 68-69, 257, 304
practices, 299-304
refactoring and, 25, 211
reflections on, 52-53
resurrection of programming and, 100-103
Scrum and, comparison of, 242
simplicity and, 154-156, 180, 181, 183-188, 300-301
"spike" technique, 170, 172, 256
technical excellence and, 147, 149, 154-157, 160-162, 167
testing and, 152, 302
ThoughtWorks and, 89-92
values and principles, 304-306
Extreme Programming Explained: Embrace Change (Beck), 4-5, 46, 143, 220, 298, 309, 379


Failure, analysis of, 291, 296, 369
Falkner, Dane, 251
FDD (Feature-Driven Development), xvii, xx, xxviii, 368. See also Features
adaptation and, 212
barely-sufficient methodologies and, 376, 377
basic description of, xxxiii, 269-284
contributions of, 283-284
methodology design and, 341
process model, 272-278
Singapore project, 269, 270-272
technical excellence and, 152, 158, 159, 161-162
Feature(s). See also FDD (Feature-Driven Development)
building by, 278
delivery capability, contracts and, 73-74
design by, 277-278
interim/final, accepting, 72
lists of, building, 275-276
planning by, 276-277
practices that deliver useful, 67-76
prioritizing, 52, 68, 69
Feedback, 35, 36, 313, 370
constant, at multiple levels, 213
Fowler on, 135
methodology design and, 340, 343
technical excellence and, 156
XP and, 51, 299-300, 305, 306
First, Break All the Rules (Buckingham and Coffman), 95
"Fix on occurrence" strategy, 182
customers and, 61
encouraging collaboration and, 129
enhancing, through ASDEs, 39, 40
improvisation and, 31
methodology design and, 337, 344
simplicity and, 184, 186
structure and, balancing, 33-34
XP and, 47, 50
Focus groups, 55, 63, 65
ASD and, 67, 69
feedback practices and, 213
technical excellence and, 150, 152
Fowler, Martin, xix, 89-90, 46, 204
Analysis Patterns: Reusable Object Models, 133, 137
on feedback, 135
on the fundamental characteristics of ASDEs, xxv
interview with, 133-144
on iterative development, 143
on maximizing "the people factor," 93
on methodology, 138-139, 141
Planning Extreme Programming, 46, 133, 136
on refactoring, 210-211
UML Distilled: A Brief Guide to Standard Object Modeling Language, 133, 137
Frameworks, 344-350, 353-354
Frequent delivery principle, 65-66
Frontier projects, 13
Functionality, 51, 56, 291
customers and, 63
frequent delivery and, 65-66
Functional Model iteration, 254-256, 258


Garmus, David, 357-358
Generali Group, 145-150
Generalists, specialists versus, 162-163
Generative rules, 184-188, 217, 368
Gilb, Tom, 299
Goldratt, Eliyahu, 343
Gould, Stephan Jay, 207
Grenning, James, 183, 302
GUI (graphical user interface), xxxvi, 82, 145, 149


Hacker, original definition of, xx
Hadfield, Tom, 135-136
HAHT Commerce, 55-58, 70
Harnessing Complexity (Cohen and Axelrod), 199
Heathkits, 49
Heaven in a Chip: Fuzzy Visions of Society and Science in the Digital Age (Kosko), 3
Higgins, Dave, 211-212
Hock, Dee, 185, 219, 227, 317, 372
Holland, John, 173, 251
Holliday, Ron, xviii
Humphrey, Watts, 372


Iansiti, Marco, 17, 35, 36, 129, 224
IBM (International Business Machines), 220, 326
Advanced Business Institute, 205
Institute for Knowledge Management, 129
MATE and, 107
OS/2, 147
Scrum and, 107
WebSphere server, 57
Zurich Research Laboratory, 80
IDX Systems, 19-26, 105
IEEE (Institute of Electrical and Electronics Engineers)
Dynabook on Extreme Programming, 124
standards, 229
Transactions on Computers, 220
Improving Software Organizations (Mathiassen), xxxvi
Improvisation, 30-31
Increment length, 84
Incremental development
Cockburn on, 80, 81, 82
technical excellence and, 156-157
India, xxx, 115-119, 191
characterization of, as "average," 92-93
"software through people" motto and, 103
valuing, over processes and tools, xvii, xviii, 40, 218, 373
Industrial Age, 380
Information. See also Information Age
engineering (IE), 156-157
flow, 99
strategy plan (ISP), 157
Information Age, 3-4, 7, 15
adaptation and, 207-208, 218
simplicity and, 180
adaptation and, 218, 219
change-driven economy and, 4, 6
controlling, 370-371
creating change and, 29-30
enhancing, through ASDEs, 40
inefficiency and, 41
paramount importance of, 4
process-centric approaches and, 99-100
simplicity and, 184-185
Innovator's Dilemma: When New Technologies Cause Great Firms to Fail (Christensen), 206-207
continuous, 303
cross-application, 61
scaling, 363-366
International Standards Organization (ISO), 115, 259, 361
Exploratory Projects and, 13
time, product development in, 34-36, 116
Iterative development, 55, 60
adaptation and, 226
ASD and, 312, 314-415
contracts and, 73, 74
demand-driven characteristics of, 73
FDD and, 279-282
Fowler on, 143
methodology design and, 340, 345-346, 357
RAD and, 195
refactoring and, 143


JAD (joint application development)
ASD and, 314, 316
documentation and, 126
DSDM and, 252
methodology design and, 362
Japan, 11, 27-28, 79, 180-181
Java Modeling in Color with UML (Coad, Lefebvre, and De Luca), 159, 269, 279
Jeffries, Ron, xxii, xxxiii, 45, 204, 212, 298
on building APIs, 61-62
on courage, 305-306
as a dynamist, 204
on eliminating processes, 182
FDD and, 281
on handling customers, 61-62
Jones, Capers, 160


Keen, Ron, 25
Kern, Jon, xxxiii, 153, 159-160, 270
Kerth, Norm, 94
explicit, documentation of, 98
tacit, 98, 125
transfer, five categories of, 123


LD (Lean Development), 181, 222
basic description of, xxxiii, 285-296
Charette on, 27, 229-237
contributions of, 295-296
Crystal Methods and, 267
encouraging collaboration and, 120
environment, 293-295
evolution of, 230-231
methodology design and, 342
origins of, 289-290
pushing, beyond its limits, 40
strategic foundation of, 286-288
success factors for, 291-292
Leadership-Collaboration management model, xxxiv, 15-17, 227. See also Collaboration
ASD and, 317-319
chaordic perspective and, 368
self-organization within, 219
trust and, 94
Lean Development (LD). See LD (Lean Development)
Lean Thinking (Womack and Jones), 181
Liability issues, 344
Life cycles. See also Waterfall life cycle
ASD and, 313-316
contracts and, 74
documentation and, 126
DSDM and, 256
emphasis on diagrams and documents in, 64-65
FDD and, 278-280
focusing on the end of, 195
frameworks and, 344-350
frequent delivery and, 65-66
"phase and gate," 195-196, 344-350
shortened, 13
Speculate-Collaborate-Learn, 310, 311-313
technology adoption, 34


McBreen, Pete, 89, 115, 164
McConnell, Steve, 138
MacCormack, Alan, 35, 36
Machine That Changed the World: The Story of Lean Production (Womack, Jones, and Roos), 27, 162-163, 289
Mah, Michael, 357
Main Street market phase, 324-325, 327, 329-331
"Management's New Paradigms" (Drucker), 29
Manifesto for Agile Software Development, xvii-xviii, xx-xxii, xxviii, 58, 92-93
Bowling Alley phase and, 324, 327, 330-331, 332
Early Market phase and, 324, 327, 329-331
Main Street phase and, 324-325, 327, 329-331
fragmentation of, 28
"time to," 60
Tornado phase and, 324-325, 327, 330-331
Martin, Bob, xix, xx, 183, 301-302
Mass customization, 28
MATE (Methods and Tool Expert), 106, 107
Mellor, Steve, 159
Mental model, xxv
Mentoring, 49-50
Metamorphoses (Ovid), 367
Metamorphosis, use of the term, 367
Metaphor, use of, 300
articulating ecosystems and, 323-334
barely-sufficient, xxvi-xxviii, 374-375, 378
Cockburn on, 52, 79-88, 323
concept of, restoring credibility to, xx
Crystal Methods and, 262-263
definition of, xxiii-xxiv, 85-86, 335
designing, 262-263, 335-366
elements of, 338-342
embellishment and, 52
for the enterprise, 365-366
ethnology of, 79-88
expectations of, 336-337
failure of, 222
fear and, 62
Fowler on, 138-139, 141
frameworks, 344-350, 353-354
generative rules and, 185-186
manuals, 40
matching, to opportunity and culture, 329-331
resurrection of programming and, 100-103
scaling, 357-366
scenarios, 344-350, 353-354
Scrum and, 241
simplicity and, 185-186, 187
systems of practices and, 338-342
technical excellence and, 148-150, 156, 167
templates, 344-350, 353-357
Meyer, Christopher, 186
Microsoft, 36, 79, 100, 194-195. See also specific software
articulating ecosystems and, 325-326
continuous integration and, 303
personality of, as a corporation, 381
scaling and, 358
Tornado markets and, 325
Milestones, 196, 272-273, 344-345
basing, on verifiable deliverables, 64-65
length of, 84
Mill, Harlan, 279
LD and, 292
simplicity as, 180, 181-182
XP and, 299
MIT (Massachusetts Institute of Technology), 35, 170
MIT Sloan Management Review, 35
Moore, Geoffrey, 34, 236, 324, 326-327, 333
Morale, of employees, 16, 175
MSNBC Silicon Summit II, 7
Multiplier effect, 192
Musashi, Miyamoto, 180, 181


Nebulon, 269, 274, 277
Newkirk, Jim, 143
New Pioneers, The (Petzinger). 216-217, 335
"New Product Development Game" (Takeuchi and Nonaka), 107
New Zealand, xxx, 79, 177, 191, 242, 309
Nimbleness, 30-31
Norway, 79, 81
"Now, Discover Your Strengths" (Buckingham and Coffman), 95-96


Object Mentor, xix
Objectives, evaluating, 351
O'Connor, Michael, 177-179
Oil exploration, 9-10, 12, 38, 41
OOP (Object-Oriented Programming), 91, 106
Fowler and, 136
methodology, 80-81
OOPSLA conference, 99, 108, 133, 135, 140
Opportunity domains, 324-325
adaptation and, 218
ASD and, 317, 318-319
conformance to business value and, 33
exploration versus, 9-12
nimbleness and, 30
scaling and, 360-361
Orr, Ken, 169, 222, 309
Outlines (writing models), 101-102
Overtime, 303-304
Ownership, collective, 303, 362


Pair programming, 130, 213, 305
basic description of, 302-303
collective ownership and, 303
methodology design and, 339, 357
simplicity and, 181, 187
technical excellence and, 148, 150
traveling pairs and, 362
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects (Schmidt et al.), 174
People. See Customers; Employees; Individuals
PERT charts, 108, 222
linear dependencies in, 348
methodology design and, 345-346, 348
Scrum and, 242, 249
Petroski, Henry, 371
Petzinger, Tom, 216-217, 304, 335
Phase and gate life cycle, 195-196, 344-350
Planning Extreme Programming (Beck and Fowler), 46, 133, 136
adaptation and, 214-216, 222-223, 225-226
balancing flexibility and, 33-34
conformance to, 32-33, 147
Crystal Methods and, 266
customer delivery principles and, 59
encouraging collaboration and, 130-131
FDD and, 276-277
Scrum and, 243, 244-245
simplicity and, 179
technical excellence and, 147
XP and, 52, 229
Policies, 84, 86, 266-268
Post-Sprint meeting, 243, 247. See also Scrum
Postrel, Virginia, 5-6, 201
best, notion of, 123, 126
focus on, 195
process versus, xxvi-xxvii, 121-123
system of, 154-155
Pragmatism, xvii, 34
Pre-Sprint planning, 243, 244-245
Principles. See also Values
articulating, 333
collaborative, xxvi, 355, 372-375
delivery, 58-67
DSDM, 253-254, 259
methodology design, 262-263, 343-344
"working software," xvii-xviii, xxi, 63-65, 100-103
"work together daily," 66-67
XP, 304-306
Problem domains, 324-325, 347
analysis workshops, 148
-centric approach, 95-100
creativity and, 96, 99-100
defined, 108
eliminating, 182
empirical, 108, 213, 241-242, 246, 250
folded-zippered, 139
immature, 369
multiple levels of, 214
practice versus, xxvi-xxvii, 121-123
skill versus, 97-99
traditional approaches to, 96-97
Product Backlog, 243, 244
"Product-Development Practices that Work: How Internet Companies Build Software" (MacCormack), 35, 36
Project Management Institute, 345
Project scope
adaptation and, 205, 210
contracts and, 74-75
creep, 74, 205, 210
establishing, 72
methodology design and, 351
technical excellence and, 149
Prototypes, 64, 101, 256
Proxy users, 69-70
Prusak, Laurence, 124, 129
Psychology of Computer Programming (Weinberg), 173


QSM Associates, 357
ASD and, 315-316
rapid feedback and, 36
reviews, 315-316
speed versus, 163-165
technical excellence and, 150-151, 163-165
XP and, 46, 306


RAD (rapid application development), xxxii, 60, 194
Amdahl and, 195
ASD and, 309
criticism of, 150
DSDM and, 251
HAHT Commerce and, 55, 56
Scrum and, 108
technical excellence and, 150, 157
RADical Software Development, 55, 309
Rapid Development (McConnell), 138
Refactoring, 25, 143
Fowler on, 133, 301
importance of, 155-156
methodology design and, 349
rework and, 210-212
scaling and, 364
simplicity and, 183
technical excellence and, 150, 154-157
XP and, 301-302
Refactoring: Improving the Design of Existing Code (Fowler), 133, 301
Regine, Birute, 219, 361
Reinertsen, Donald, 123
Relativism, cultural, 79-80, 85, 328-329
Release Backlog, 244
Release cycles, 111-112
adaptation and, 200
changes, 76
contracts and, 74
creep, 51
customer involvement and, 66-67
FDD and, 278-280
gathering, 67, 69, 194
specifications, 72
voice of the customer and, 61
Response Ability (Dove), 27
Rework, viewing, as a virtue, 210-212
Rigorous, use of the term, xxxi. See also RSMs (Rigorous Software Methodologies)
adaptation and, 222
addressing issues germane to, 10
articulating ecosystems and, 324
ASD and, 312
business, 37, 38, 40
categorization of, 37-38
entrepreneurship, 10, 286-288, 296
Exploratory Projects and, 13
LD and, 286-288, 295, 296
leadership, 286-288
management, 10, 84
methodology design and, 351, 352
organizational, 37-38
technical, 37, 38
Robustness, 186
Rowland Archer, 56
RSMs (Rigorous Software Methodologies), 4, 5, 61
adaptation and, 201
the Agile metamorphosis and, 368, 370, 372, 375-376, 380
articulating ecosystems and, 323, 329, 332
barely-sufficient methodologies and, 376
Crystal Methods and, 267
delivering customer value and, 58, 59
documentation and, 125
employee morale and, 16
encouraging collaboration and, 120, 125, 130
Exploratory Projects and, 13
LD and, 295
management styles and, 96
methodology design and, 335-336, 345, 359, 365
scaling and, 359
uncertainty and, 17
adaptation and, 217, 218
-breaking culture, 215
generative, 184-188, 217, 368
RUP (Rational Unified Process), 306, 139, 143
Russell, Lou, 95, 380


Samurai tradition, 180-181
Scaling, 357-366
Scenarios, 344-350, 353-354
contracts and, 73
encouraging collaboration and, 116
Schwaber, Ken, xvii-xviii, xxvi, xxviii, xxix
adaptation and, 204, 208, 213, 217, 222
on chaos, 241
on empirical processes, 208, 213
on failure, 222
IDX Systems and, 20-24
personality of, 381
scaling issues and, 358
Scrum and, xxxii, 105-113, 241, 249
Scope, project
adaptation and, 205, 210
contracts and, 74-75
creep, 74, 205, 210
establishing, 72
methodology design and, 351
technical excellence and, 149
Scrum, xvii, xx, xxii, xxviii


Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020