As you review the values described in the following discussion, consider what they would mean if you put them into practice. How do these values support meeting time-to-market goals, dealing with change, and valuing human innovation?
Although the agile values and principles are not usually numbered, they are numbered here for ease of reference. The numbering matches their order in the manifesto.
Value 1: Individuals and interactions over processes and tools
When you allow each person to contribute his or her unique value to a product, the result can be powerful. When these human interactions focus on solving problems, a unified purpose can emerge. Moreover, the agreements come about through processes and tools that are much simpler than conventional ones.A simple conversation in which you talk through a product issue can solve many problems in a relatively short time. Trying to emulate the power of a direct conversation with email, spreadsheets, and documents results in significant overhead costs and delays. Instead of adding clarity, these types of managed, controlled communications are often ambiguous and time-consuming and distract the development team from the work of creating a product.
Consider what it means if you value individuals and interactions highly. The table shows some differences between valuing individuals and interactions and valuing processes and tools.| Individuals and Interactions Have High Value | Processes and Tools Have High Value | |
| Pros | Communication is clear and effective. Communication is quick and efficient. Teamwork becomes strong as people work together. Development teams can self-organize. Development teams have more chances to innovate. Development teams can quickly adjust processes as necessary. Development team members can take personal ownership of the product. Development team members can have deeper job satisfaction. |
Processes are clear and can be easy to follow. Written records of communication exist. |
| Cons | To enable more team empowerment and less command and control, managers may have to unlearn traditional leadership tendencies. People may need to let go of ego to work well as members of a team. |
People may over-rely on processes instead of finding the best ways to create good products. One process doesn’t fit all teams — different people have different work styles. One process doesn’t fit all products. Communication can be ambiguous and time-consuming. |
If processes and tools are seen as the way to manage product development and everything associated with it, people and the way they approach the work must conform to the processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile approaches, however, value people over process. This emphasis on individuals and teams puts the focus on their energy, innovation, and ability to solve problems. You use processes and tools in agile product management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations.
Value 2: Working software over comprehensive documentation
A development team’s focus should be on producing working functionality. With agile development, the only way to measure whether you are truly finished with a product requirement is to produce the working functionality associated with that requirement. For software products, working software means the software meets the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the investment.Have you ever been in a status meeting where you reported that you were, say, 75 percent done with your project? What would happen if your customer told you, “We ran out of money. Can we have our 75 percent now?” On a traditional project, you wouldn’t have any working software to give the customer; 75 percent done traditionally means you are 75 percent in progress and 0 percent done. With agile product development, however, by using the definition of done, you would have working, potentially shippable functionality for 75 percent of your product requirements — the highest-priority 75 percent of requirements.
Although agile approaches have roots in software development, you can use them for other types of products. This second agile value can easily read, “Working functionality over comprehensive documentation.”
Tasks that distract from producing valuable functionality must be evaluated to see whether they support or undermine the job of creating a working product. Table 1-2 shows a few examples of traditional project documents and their usefulness. Think about whether documents produced on a recent project you were involved in added value to the functionality being delivered to your customer.| Document | Does the Document Add to Product Value? | Is the Document Barely Sufficient or Gold-Plated? |
| Project schedule created with expensive project management software, complete with Gantt chart | No. Start-to-finish schedules with detailed tasks and dates tend to provide more than what is necessary for product development. Also, many of these details change before you develop future features. |
Gold-plated. Although project managers may spend a lot of time creating and updating project schedules, team members tend to want to know only key deliverable dates. Management often wants to know only whether the deliverable is on time, ahead of schedule, or behind. |
| Requirements documentation | Yes. All products have requirements — details about product features and needs. Development teams need to know those needs to create a product. |
Possibly gold-plated; should be barely sufficient. Requirements documents can easily grow to include unnecessary details. Agile approaches provide simple ways to enable product requirement conversations. |
| Product technical specifications | Yes. Documenting how you created a product can make future changes easier. |
Possibly gold-plated; should be barely sufficient. Agile documentation includes just what it needs — development teams often don’t have time for extra flourishes and are keen to minimize documentation. |
| Weekly status report | No. Weekly status reports are for management purposes but do not assist product creation. |
Gold-plated. Knowing status is helpful, but traditional status reports contain outdated information and are much more burdensome than necessary. |
| Detailed project communication plan | No. Although a contact list can be helpful, the details in many communication plans are useless to product development teams. |
Gold-plated. Communication plans often end up being documents about documentation — an egregious example of busywork. |
With agile product development, barely sufficient is a positive description, meaning that a task, document, meeting, or almost anything created includes only what it needs to achieve the goal. Being barely sufficient is practical and efficient — it’s sufficient, just enough. The opposite of barely sufficient is gold-plating, or adding unnecessary frivolity — and effort — to a feature, task, document, meeting, or anything else.
All development requires some documentation. With agile product development, documents are useful only if they support development and are barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.Stop producing a document and see who complains. After you know the requester of the document, strive to better understand why the document is necessary. The five whys work great in this situation — ask “why” after each successive answer to get to the root reason cause for the document. After you know the core reason for the document, see how you can satisfy that need with an agile artifact or streamlined process.
Agile teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues. You can create and use simple tools (such as a product backlog, a sprint backlog, and a task board) that allow teams to understand requirements and assess real-time status daily. With agile approaches, teams spend more time on development and less time on documentation, resulting in a more efficient delivery of a working product.Value 3: Customer collaboration over contract negotiation
The customer is not the enemy. Really.Historical project management approaches usually limit customer involvement to a few development stages:
- Start of a project: When the customer and the project team negotiate contract details.
- Any time the scope changes during the project: When the customer and the project team negotiate changes to the contract.
- End of a project: When the project team delivers a completed product to the customer. If the product doesn’t meet the customer’s expectations, the project team and the customer negotiate additional changes to the contract.
You will never know less about a product than at its start. Locking product details into a contract at the beginning of development means you have to make decisions based on incomplete knowledge. If you have flexibility for change as you learn more about a product and the customer the product is serving, you’ll ultimately create better products.
The agile pioneers understood that collaboration, rather than confrontation, produced better, leaner, more useful products. As a result of this understanding, agile methods make the customer part of the product development on an ongoing basis.Using an agile approach in practice, you’ll experience a partnership between the customer and the development team in which discovery, questioning, learning, and adjusting during the course of product development are routine, acceptable, and systematic.
Value 4: Responding to change over following a plan
Change is a valuable tool for creating great products. Teams that can respond quickly to customers, product users, and the market are able to develop relevant, helpful products that people want to use.Unfortunately, traditional project management approaches attempt to wrestle the change monster and pin it to the ground so it goes out for the count. Rigorous change management procedures and budget structures that can’t accommodate new product requirements make changes difficult. Traditional project teams often find themselves blindly following a plan, missing opportunities to create more valuable products or, even worse, unable to react timely to changing market conditions.
The figure shows the relationship between time, opportunity for change, and the cost of change on a traditional project. As time — and knowledge about your product — increases, the ability to make changes decrease, and costs more.
Traditional project opportunity for change.By contrast, agile development accommodates change systematically. The flexibility of agile approaches increases stability because product changes are predictable and manageable — in other words, it’s expected and non-disruptive to an agile team. In the rest of Book 4, you discover how agile approaches to planning, working, and prioritization allow teams to respond quickly to change.
As new events unfold, the team incorporates these realities into the ongoing work. Any new item becomes an opportunity to provide additional value instead of an obstacle to avoid, giving development teams a greater opportunity for success.