Core Agile Values

Agility is more attitude than process, more environment than methodology. In 1994 authors Jim Collins and Jerry Porras (1994) wrote Built to Last , a book based on their research that set out to answer the question, "What makes the truly exceptional companies different from the other companies?" One of their core findings was that exceptional companies created a foundation that didn't change and strategies and practices that did: "Visionary companies distinguish their timeless core values and enduring purpose, which should never change, from their operating practices and business strategies (which should be changing constantly in response to a changing world)."

I think one reason that agile software development has grown in recognition and use during the last few years is that the founders of the movement stated explicitly what we believed in the Manifesto for Agile Software Development . We stated our core values and enduring purpose. Why teams exist, what we intend to build, whom we build it for, and how we work together also form the core principles of APM. If we want to build great products, we need great people. If we want to attract and keep great people, we need a great organization. The core value of an egalitarian meritocracy runs deep in the agile movement. It is surely not the only core value that can produce products, but it is a core value that defines how the majority of agilists view themselves .

We live in an age in which the volume of available information stupefies us. On any relatively interesting subject we can find thousands of Web pages, tensif not hundredsof books, and article after article. How do we filter all this information? How do we process all this information? Core ideology and principles provide one mechanism for processing and filtering information. They steer us in the direction of what is more, or less, important. They help us make product decisions and evaluate development practices.

Principles, or "rules" in complexity theory terminology, affect how tools and practices are implemented. Practices are how principles are acted out. Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used. While the use of practices may vary from project team to project team, the principles are constant. Principles are the simple rules, the generative rules, of complex human adaptive systems.

The Manifesto for Agile Software Development [4] established a set of four core values, which, with a single word change, form the core values of APM:

[4] 2001 by Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.

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

Individuals and interactions over processes and tools Working [products] [5] over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan.

[5] The Manifesto's wording is "software." I use the word "products" here as a more general term .

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

[6] For an in-depth explanation of the Agile Manifesto, see (Fowler and Highsmith 2001).

"This should not be construed as indicating that tools, process, documents, contracts, or plans are unimportant . There is a tremendous difference between one thing being more or less important than another and being un important" (Highsmith 2000). Tools are critical to speeding development and reducing costs. Contracts are vital to initiating developer-customer relationships. Documentation aids communication. However, the items on the left are the most critical. Without skilled individuals, working products, close interactions with customers, and responsiveness to change, product delivery will be nearly impossible .

While these core value statements were originally written for agile software development, they apply directlywith a bit of interpretation, and some reorderingto APM.

Responding to Change

Responding to change over following a plan. This statement reflects the agile viewpoint characterized further by:

• Envision-Explore versus Plan-Do
• Exploration versus production
• Adapting versus anticipating

Every project has knowns and unknowns, certainties and uncertainties, and therefore every project has to balance planning and changing. However, balancing is required because projects also run the gamut from production-style ones in which uncertainty is low, to exploration-style ones in which uncertainty is high. Exploration-style projects are characterized by a process that emphasizes envisioning and then exploring into that vision rather than detailed planning and relatively strict execution of tasks . It's not that one is right and the other wrong, but that each style is more or less applicable to a particular project type.

Another factor that impacts project management style is the cost of an iteration; that is, the cost of experimenting. Even if the need for innovation is great, high iteration costs may dictate a process with greater anticipatory work. Low-cost iterations, like those mentioned earlier, enable an adaptive style of development in which plans, architectures, and designs evolve concurrently with the actual product.

Companies trying to thrive in our turbulent economy must alter both their processes and their perspectives with respect to change. We are no longer talking about 15% to 20% scope creep on projects; we are talking about everything changingscope, features, technology, architecture (but not vision)within the span of a few months. I'm continually surprised by the magnitude of change products and projects undergo. The common project management aim of "conforming to plan" fails dramatically in these situations.

In Artful Making , Harvard Business School professor and colleague Rob Austin and his coauthor Lee Devin (2003) discuss a $125 million IT project disaster in which the company refused to improvise and change from the detailed plan set down prior to the project's start. " 'Plan the work and work the plan' was their implicit mantra," they write. "And it led them directly to a costly and destructive course of action. We'd all like to believe that this kind of problem is rare in business. It's not."

Working Products

Working products over comprehensive documentation. Innovation drives companies. The core ideology at 3M has always emphasized innovation. Motorola recently launched a new cell phone innovation initiative. In early 2003, General Electric changed its motto to "Explore Imagination at Work." Jeffrey Immelt, chairman and CEO of GE, has placed a high priority on innovation and new business. "The companies that know how to develop things are ultimately going to create the most shareholder value. It's as simple as that," says Immelt (Budeir 2003). Many companies have innovation initiatives; fewer are willing to create processes and practices that directly support those initiatives. Switching from delivering documentation artifactscharacteristic of a serial development styleto delivering iterative versions of the real product is one of those mind and practice shifts that supports innovation.

Large, front-loaded projects that spend months, and even years, gathering requirements, proposing architectures, and designing products are prone to massive failures. Why? Because teams proceed in a linear fashion with little reliable feedbackthey have good ideas, but they don't test them in the cauldron of reality. Documents don't work. Products do.

Agile development and project management stress delivery of versions of the actual product, or in the case of high-cost materials, effective simulations or models of the actual product. Finishing a requirements document verifies that a team has successfully gathered a set of requirements. Completing and demonstrating a set of working product features verifies that the development team can actually deliver something tangible to the customer. Working features provide dependable feedback into the development process in ways that documentation cannot.

Again, working products don't preclude the need for documentation. Documents support communication and collaboration, enhance knowledge transfer, preserve historical information, assist ongoing product enhancement, and fulfill regulatory and legal requirements. They are not unimportant, just less important than working versions of the product.

However, there is a fundamental flaw in many people's understanding of documentation documentation is not a substitute for interaction. When a customer and a developer interact to jointly develop specifications and produce some form of permanent record (documents, notes, sketches , feature cards, drawings), the documentation is a by-product of the interaction. When the customer sits down with a product manager and they write a requirements document that gets sent to a development group , then the document has become a substitute for interaction. In the first scenario, the documentation may be valuable to the development team. In the second, it has become a barricade to progress. Little knowledge is either gained or transferred. Furthermore, as interaction decreases, the volume of documentation often increases in a fruitless attempt to compensate.

Customer Collaboration

Customer collaboration over contract negotiation. Customers and product managers drive agile development. The customer team (depending on the product type, the participants may be actual customers, product managers, product champions , or other customer proxies) and the development team form a partnership in which each has specific roles, responsibilities, and accountabilities. In highly volatile, ambiguous, and uncertain new product development efforts, the customer-developer relationship must be collaborative, not marked by adversarial contract disputes.

The goal of a project team is to deliver value to customers. While there are, in big organizations, a variety of stakeholders, the customer should reign supreme. Furthermore, the definition of customer can be reduced to a simple statementthe customer is the individual or group who uses the created product to generate business value or, in the case of retail products, the person who uses the product. Customers define value. Other stakeholders define constraints. When we confuse customers and stakeholders, our projects become muddled.

Customers define requirements (features) that provide value and the business objectives (schedule, cost) that assist in quantifying that value. Today, value arises from implementing features that meet this set of requirements and constraints as they evolve over the life of a project. Once a product has been delivered initially, tomorrow's benefits are a function of how quickly and cost effectively the product can be adapted to requirements and constraints that arise in the future. The formula for success is simple: deliver today, adapt tomorrow.

Individuals and Interactions

Individuals and interactions over processes and tools. Ultimately, unique, talented, and skilled individualsindividually and collectivelybuild products and services. Processes provide guidance and support, and tools improve efficiency, but without the right people who have the right technical and behavioral skills, all the processes and tools in the world won't produce results. Processes (in moderation ) and tools are useful, but when critical decisions must be made, we rely on the knowledge and capabilities of individuals and the team.

Companies often issue flowery statements about how important their people are and then tie them down with unyielding procedures and forms. In the 1990s business went through a period of infatuation with processmuch of it under the banner of business process reengineering (BPR). Process literally became more important than people. BPR proponents thought that structured processes would somehow make up for mediocre individual capabilities, but no process can overcome the lack of good engineers , product managers, customers, suppliers, and executives. Good processes should support the team rather than dictate its actions. Processes are adapted to the team rather than the other way around.

APM supports creators , not stewards. Colleague Rob Austin defines the differences between these two types of individuals:

The problem the creators have is that they want to go for the big prize, to realize their visions in pure form; anything short of that they see as less than successful. The stewards, on the other hand, can't get excited about an innovation until they understand how the economic value (profit) will be created (Austin 2003).

Stewards are critical to business successthey manage the numbers and invest prudently. Businesses without stewards often fail in their fiduciary responsibilities to employees , customers, and investors. However, without creators, the stewards have nothing to steward. Without innovationnew product development, new processes and practices, new ways of creating business valuethe stewards are left maintaining an empty husk. Without the stable foundation provided by stewards, creators may spin out of control.

The agile movement supports individuals and their interactions through dedication to the concepts of self-organization, self-discipline, egalitarianism, respect for individuals, and competency. "Agile" is a social movement driven by both the desire to create a particular work environment and the belief that this "adaptive" environment is critical to the goal of delivering innovative products to customers.