Chapter 1

Applying the Agile Manifesto and Principles

IN THIS CHAPTER

Defining the Agile Manifesto and the 12 Agile Principles

Describing the Platinum Principles

Understanding what has changed in project management

Checking out the agile litmus test

This chapter describes the basics of what it means to be agile as outlined in the Agile Manifesto, with its four values, and the 12 Agile Principles behind the Agile Manifesto. It also expands on these basics with three additional Platinum Principles.

This foundation provides product development teams with the information needed to evaluate whether the team is following agile principles, as well as whether their actions and behaviors are consistent with agile values. When you understand these values and principles, you’ll be able to ask, “Is this agile?” and be confident in your answer.

Understanding the Agile Manifesto

In the mid-1990s, the Internet was changing the world right before our eyes. The people working in the booming dot-com industry were under constant pressure to be the first-to-market with fast-changing technologies. Development teams worked day and night, struggling to deliver new software releases before competitors made their companies obsolete. The information technology (IT) industry was completely reinvented in a few short years.

Given the pace of change at that time, cracks inevitably appeared in conventional project management practices. Using traditional methodologies such as waterfall didn’t allow developers to be responsive enough to the market’s dynamic nature and to emerging new approaches to business. Development teams started exploring alternatives to these outdated approaches to project management. In doing so, they noticed some common themes that produced better results.

In February 2001, 17 of these new methodology pioneers met in Snowbird, Utah, to share their experiences, ideas, and practices; to discuss how best to express them; and to suggest ways to improve the world of software development. They couldn’t have imagined the effect their meeting would have on the future of project management. The simplicity and clarity of the manifesto they produced and the subsequent principles they developed transformed the world of information technology and continue to revolutionize product development in every industry, not just software.

Over the next several months, these leaders constructed the following:

• The Agile Manifesto (originally the Manifesto for Agile Software Development): An intentionally streamlined expression of core development values
• The Agile Principles: A set of 12 guiding concepts that support agile teams in delivering value and staying on track
• The Agile Alliance: A community development organization focused on supporting individuals and organizations applying agile principles and practices

The group’s work was destined to make the software industry more productive, more humane, and more sustainable.

The Agile Manifesto is a powerful statement, carefully crafted using fewer than 75 words:

• Manifesto for Agile Software Development
• 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.

  * Agile Manifesto Copyright © 2001: 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, Dave Thomas

  This declaration may be freely copied in any form, but only in its entirety through this notice.

No one can deny that the Agile Manifesto is both a concise and an authoritative statement. Whereas traditional approaches emphasize a rigid plan, avoid change, document everything, and encourage hierarchical-based control, the manifesto focuses on

• People
• Communications
• Product
• Flexibility

The Agile Manifesto represents a big shift in focus in how products are conceived, conducted, and managed. If you read only the items on the left, you understand the new paradigm that the manifesto signers envisioned. They found that by focusing more attention on individuals and interactions, teams would more effectively produce working software through valuable customer collaboration and by responding well to change. In contrast, the traditional primary focus on processes and tools often produces comprehensive or excess documentation to comply with contract negotiations and to follow an unchanging plan.

Research and experience illustrate why agile values are so important:

• Individuals and interactions over processes and tools: Why? Because research shows a 50 times increase in performance when we get individuals and interactions right. One of the ways to get this right is by collocating a development team with an empowered product owner.
• Working software over comprehensive documentation: Why? Because failure to test for and correct defects during the sprint can take up to 24 times more effort and cost in the next sprint. And after the functionality is deployed to the market, if a production support team that wasn’t involved in product development performs the testing and fixing, the cost is up to 100 times more.
• Customer collaboration over contract negotiation: Why? Because a dedicated and accessible product owner can generate a fourfold increase in productivity by providing in-the-moment clarification to the development team, aligning customer priorities with the work being performed.
• Responding to change over following a plan: Why? Because 80 percent of features developed under a waterfall model are infrequently or never used. Starting with a plan is vital, but the start is when we know the least. Agile teams don’t plan less than waterfall teams — they plan as much or more. However, agile teams take a just-in-time approach, planning just enough when needed in support of a strategic product vision and roadmap. Adaptation of the plan to the realities along the way is how agile teams avoid wasteful functionality and deliver products that delight customers.

The creators of the Agile Manifesto originally focused on software development because they worked in the IT industry. However, agile techniques have spread beyond software development and even outside computer-related products. Today, agile approaches such as scrum (see Book 5) are disrupting biotech, manufacturing, aerospace, engineering, marketing, building construction, finance, shipping, automotive, utility, and energy industries with companies such as Apple, Microsoft, and Amazon leading the way. If you want early empirical feedback on the product or service you’re providing, you can benefit from agile methods.

The State of Scrum 2017–2018 report quoted a Scrum Alliance board member who said, “Any organization that does not go through an Agile transformation will die. It is the same as a company refusing to use computers.”

The Agile Manifesto and Agile Principles directly refer to software; this book leaves these references intact when quoting the manifesto and principles. If you create non-software products, try substituting your product as you read on. Agile values and principles apply to all product development activities, not just software.

Outlining the Four Values of the Agile Manifesto

The Agile Manifesto was generated from experience, not from theory. As you review the values described in the following sections, 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 numbered, they are numbered here and throughout this book 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. Table 1-1 shows some differences between valuing individuals and interactions and valuing processes and tools.

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.

TABLE 1-1 Individuals and Interactions Versus 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.

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.

TABLE 1-2 Identifying Useful Documentation

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. In later chapters, you find out how to 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. See Chapter 2 in Book 4 for more on the product backlog, and see Chapter 3 in Book 4 to learn more about the sprint backlog.

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.

This historical focus on negotiation, avoidance of scope change, and limitation of direct customer involvement discourages potentially valuable customer input and can even create an adversarial relationship between customers and project teams.

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.

Figure 1-1 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.

© John Wiley & Sons, Inc.

FIGURE 1-1: 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.

Defining the 12 Agile Principles

In the months following the publication of the Agile Manifesto, the original signatories continued to communicate. To support teams making the transition to agile approaches, they augmented the four values of the Agile Manifesto with 12 principles.

These principles, along with the Platinum principles (explained in the later section “Adding the Platinum Principles”) can be used as a litmus test to see whether the specific practices of your team are true to the intent of the agile movement.

Following is the text of the original 12 principles, published in 2001 by the Agile Alliance:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These agile principles provide practical guidance for development teams.

Another way of organizing the 12 principles is to consider them in the following four distinct groups:

• Customer satisfaction
• Quality
• Teamwork
• Product development

The following sections discuss the principles according to these groups.

Agile principles of customer satisfaction

Agile approaches focus on customer satisfaction, which makes sense. After all, the customer is the reason for developing the product in the first place.

While all 12 principles support the goal of satisfying customers, principles 1, 2, 3, and 4 stand out:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.

You may define the customer of a product in a number of ways:

• The customer is the person or group paying for the product.
• In some organizations, the customer may be a client, external to the organization.
• In other organizations, the customer may be a stakeholder or a group of stakeholders in the organization.
• The person who ends up using the product is also a customer. For clarity and to be consistent with the original 12 agile principles, that person is called the user.

How do you enable these principles? Consider the following:

• Agile teams include a product owner, a person who is responsible for translating what the customer wants into product requirements.
• The product owner prioritizes product features in order of business value or risk and communicates priorities to the development team. The development team delivers the most valuable features on the list in short cycles of development, known as iterations, or sprints.
• The product owner has deep and ongoing involvement throughout each day to clarify priorities and requirements, make decisions, provide feedback, and quickly answer the many questions that pop up during product development.
• Frequent delivery of working product features allows the product owner and the customer to have a full sense of how the product is developing.
• As the development team continues to deliver complete, working, potentially shippable functionality every one to eight weeks or less, the value of the total product grows incrementally, as do its functional capabilities.
• The customer accumulates value for his or her investment regularly by receiving new, ready-to-use functionality throughout development, rather than waiting until the end for the first, and maybe only, delivery of releasable product features.

Table 1-3 lists some customer satisfaction issues that commonly arise during product development. Use Table 1-3 and gather some examples of customer dissatisfaction that you’ve encountered. Do you think becoming more agile would make a difference? Why or why not?

TABLE 1-3 Customer Dissatisfaction and How Agile Might Help

Examples of Customer Dissatisfaction with Product Development	How Agile Approaches Can Increase Customer Satisfaction
The product requirements were misunderstood by the development team.	Product owners work closely with the customer to define and refine product requirements and provide clarity to the development team. Agile teams demonstrate and deliver working functionality at regular intervals. If a product doesn’t work the way the customer thinks it should work, the customer can provide feedback at the end of the sprint, not at the end of development, when the feedback would be too late.
The product wasn’t delivered when the customer needed it.	Working in sprints allows agile teams to deliver high-priority functionality early and often.
The customer can’t request changes without additional cost and time.	Agile processes are built for change. Development teams can accommodate new requirements, requirement updates, and shifting priorities with each sprint — offsetting the cost of these changes by removing the lowest-priority requirements — functionality that likely will never or rarely get used.

Agile strategies for customer satisfaction include the following:

• Producing, in each iteration, the highest-priority features first
• Ideally, locating the product owner and the other members of the team in the same place to eliminate communication barriers
• Breaking requirements into groups of features that can be delivered in one to eight weeks or less
• Keeping written requirements simple, forcing more robust and effective face-to-face communication
• Getting the product owner’s acceptance as soon as functionality is completed
• Revisiting the feature list regularly to ensure that the most valuable requirements continue to have the highest priority

Agile principles of quality

An agile team commits to producing quality in every product increment it creates — from development through documentation to integration and test results — every day. Each team member contributes his or her best work all the time. Although all 12 principles support the goal of quality delivery, principles 1, 3, 4, 6–9, and 12 stand out:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These principles, in practice on a day-to-day basis, can be described as follows:

• The development team members must have full ownership of technical quality and be empowered to solve problems. They carry the responsibility for determining how to create the product, deciding the technical work needed to create it, and organizing product development. People not doing the work don’t tell them how to do it.
• With software development, an agile approach requires architectures that make coding and testing the product modular, flexible, and extensible. The design should address today’s problems and make inevitable changes as simple as possible.
• A set of designs on paper can never tell you that something will work because everything works on paper. When the product quality is such that it can be demonstrated and ultimately shipped in short intervals, everyone knows that the product works — at the end of every sprint.
• As the development team completes features, the team shows the product owner the product functionality to get validation that it meets the acceptance criteria. The product owner’s reviews should happen throughout the iteration, ideally the same day that the development of the requirement was completed. Feedback from the product owner is often necessary even during the development of a feature.
• At the end of every iteration (lasting two weeks or less for most agile teams), working functionality is demonstrated to the customer. Progress is clear and easy to measure.
• Testing is an integral, ongoing part of development and happens throughout the day, not at the end of the iteration. As much as possible, testing is automated.
• With software development, ensuring new code is tested and integrates with previous versions occurs in small increments, possibly several times a day (or thousands of times a day in some organizations, such as Google, Amazon, and Facebook). This process, called continuous integration (CI), helps ensure that the entire solution continues to work when new code is added to the existing code base.

• With software development, examples of technical excellence include establishing coding standards, using service-oriented architecture, implementing automated testing, and building for future change.

  Agile principles apply to more than software products. Technical excellence is crucial whether you’re developing marketing campaigns, publishing books, involved in manufacturing, or engaged in research and development. All disciplines have a set of technical practices that agile teams can use to build in quality all along the way.

Agile approaches provide the following strategies for quality management:

• Defining what done means (that is, shippable ready for market, / go to market) at the beginning of development and then using that definition as a benchmark for quality
• Testing aggressively and daily through automated means
• Building only the functionality needed when it’s needed
• Reviewing the software code and streamlining (refactoring)
• Showcasing to stakeholders and customers only the functionality that has been accepted by the product owner
• Having multiple feedback points throughout the day, iteration, and product lifecycle

Agile principles of teamwork

Teamwork is critical to agile product development. Creating good products requires cooperation among all members of the team, including customers and stakeholders. Agile approaches support team-building and teamwork, and they emphasize trust in self-managing development teams. A permanent, skilled, motivated, unified, and empowered team is a successful team.

Although all 12 principles support the goal of teamwork, principles 4–6, 8, 11, and 12 stand out as supporting team empowerment, efficiency, and excellence:

4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile approaches focus on sustainable development; as knowledge workers, our brains are the value we bring to product development. If only for selfish reasons, organizations should want fresh, well-rested brains working for them. Maintaining a regular work pace, rather than having periods of intense overwork, helps keep each team member’s mind sharp and product quality high.

Here are some practices you can adopt to make this vision of teamwork a reality:

• Ensure that your development team members have the proper skills and motivation.
• Provide training sufficient to the task.
• Support the self-organizing development team’s decisions about what to do and how to do it; don’t have managers tell the team what to do.
• Hold team members responsible as a single team, not as individuals.

• Use face-to-face communication to quickly and efficiently convey information.

  Suppose that you usually communicate to Sharon by email. You take time to craft your message and then send it. The message sits in Sharon’s inbox, and she eventually reads it. If Sharon has any questions, she writes another email in response and sends it. That message sits in your inbox until you eventually read it. And so forth. This type of table tennis communication is too inefficient to use in the middle of a rapid iteration. A five-minute discussion addresses the issue quickly and with less risk of misunderstanding — and with a huge cost savings.

• Have spontaneous conversations throughout the day to build knowledge, understanding, and efficiency.
• Collocate teammates in close proximity to increase clear and efficient communication. If collocation isn’t possible, use video chat rather than email. Teams who rely on written communication for collaboration are slower and more prone to miscommunication errors. Written intra-team communication is a liability.

• Make sure that lessons learned is an ongoing feedback loop rather than an end-of-project-only occurrence. Retrospectives should be held at the end of each iteration, when reflection and adaptation can improve development team productivity immediately going forward, creating ever higher levels of efficiency. A lessons learned meeting at the end of development has minimal value because the next product created might have a different group of people and practices. To learn more about retrospectives, see Chapter 5 in Book 4.

  The first retrospective is as valuable (or even more valuable) as any future retrospective because, at the beginning, the team has the opportunity to make changes that can benefit the rest of the product development moving forward.

The following strategies promote effective teamwork:

• Collocate the development team so they have no physical barriers to effective and real-time communication.
• Put together a physical environment conducive for collaboration: a team room with whiteboards, colored pens, and other tactile tools for developing and conveying ideas to ensure shared understanding.
• Create an environment where team members are encouraged to speak their minds.
• Meet face-to-face whenever possible. Don’t send an email if a conversation can handle the issue.
• Get clarifications throughout the day as they’re needed.
• Encourage the team to solve problems rather than having managers solve problems for the team.

• Resist the temptation to shuffle team members. Allow the team to become a stable, permanent, high-performing, capability-expanding team.

  A long-term product perspective requires long-term, permanent teams. High-performing teams take years to build. Their understanding of the customer, their feedback from each release, the product support they provide, and the product development environment logically encourage teams to remain as stable as possible. Team members may seek new opportunities for career development outside the team, but for the most part teams should remain as constant as possible for maximum value. As each new feature is built, the team remains constant, able to support and learn from the product’s adoption by the customer.

Agile principles of product development

Agility in product management encompasses three key areas:

• Making sure the development team can be productive and can sustainably increase productivity over long periods of time
• Ensuring that information about the product’s progress is available to stakeholders without interrupting the flow of development activities by asking the development team for updates
• Handling requests for new features as they occur and integrating them into the product development cycle

An agile approach focuses on planning and executing the work to produce the best product that can be released. The approach is supported by communicating openly, avoiding distractions and wasteful activities, and ensuring that the progress of the product development is clear to everyone.

All 12 principles support product management, but principles 1–3 and 7–10 stand out for us:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.

Following are some advantages of adopting agile product management:

• Agile teams achieve faster time-to-market and, consequently, cost savings. They start development earlier than in traditional approaches because agile approaches minimize the exhaustive upfront planning and documentation that is conventionally part of the early stages of a waterfall project.
• Agile teams are self-organizing and self-managing. The managerial effort normally put into telling developers how to do their work can be applied to removing impediments and organizational distractions that slow down the team.
• Agile development teams determine how much work they can accomplish in an iteration and commit to achieving those goals. Ownership is fundamentally different because the development team is establishing the commitment, not complying with an externally developed commitment.

• An agile approach asks, “What is the minimum we can do to achieve the goal?” instead of focusing on including all features and extra refinements that could possibly be needed. An agile approach usually means streamlining: barely sufficient documentation, removal of unnecessary meetings, avoidance of inefficient communication (such as email), and minimizing complexity of what’s under the hood (just enough to make it work).

  Creating complicated documents that aren’t useful for product development is a waste of effort. It’s okay to document a decision, but you don’t need multiple pages on the history and nuances of how the decision was made. Keep the documentation barely sufficient (that is, sufficient but just barely), and you’ll have more time to focus on supporting the development team.

• By encapsulating development into short sprints that last several weeks or less, you can adhere to the goals of the current iteration while accommodating change in subsequent iterations. The length of each sprint remains the same throughout development to provide a predictable rhythm for the team long-term.
• Planning, elaborating on requirements, developing, testing, and demonstrating functionality occur within an iteration, lowering the risk of heading in the wrong direction for extended periods of time or developing something that the customer doesn’t want.

• Agile practices encourage a steady pace of development that is productive and healthy. For example, in the popular agile software development set of practices called extreme programming (XP), the maximum workweek is 40 hours, and the preferred workweek is 35 hours. Agile product development is constant and sustainable, as well as more productive, especially long term.

  Traditional approaches routinely feature a death march, in which the team puts in extremely long hours for days and even weeks at the end to meet a previously unidentified and unrealistic deadline. As the death march goes on, productivity tends to drop dramatically. More defects are introduced, and because defects need to be corrected in a way that doesn’t break a different piece of functionality, correcting defects is the most expensive work that can be performed. Defects are often the result of overloading a system — specifically demanding an unsustainable pace of work. Check out a presentation on the negative effects of “Racing in Reverse” at https://platinumedge.com/overtime.

• Priorities, experience with the existing product, and, eventually, the speed at which development will likely occur within each sprint are clear, making for good decisions about how much can or should be accomplished in a given amount of time.

If you’ve worked on a traditional project before, you might have a basic understanding of project management activities. Table 1-4 lists a few project management tasks, along with how you would meet those needs with agile approaches. Use Table 1-4 to capture your thoughts about your experiences and how agile approaches look different from traditional project management.

TABLE 1-4 Contrasting Historical Project Management with Agile Product Management

Traditional Project Management Tasks	Agile Approach to Product Development Tasks
Create a fully detailed project requirement document at the beginning of the project. Try to control requirement changes throughout the project.	Create a product backlog — a simple list of requirements by priority. Quickly update the product backlog as requirements and priorities change throughout product development.
Conduct weekly status meetings with all project stakeholders and developers. Send detailed meeting notes and status reports after each meeting.	The development team meets quickly, for no longer than 15 minutes, at the start of each day to coordinate and synchronize that day’s work and any roadblocks. They can update the centrally visible burndown chart in under a minute at the end of each day. Anyone, including stakeholders, can see the real-time progress on demand.
Create a detailed project schedule with all tasks at the beginning of the project. Try to keep the project tasks on schedule. Update the schedule on a regular basis.	Work within sprints and identify only specific tasks for the active sprint.
Assign tasks to the development team.	Support the development team by removing impediments and distractions. Development teams define and pull (as opposed to push) their own tasks.

Successful product development is facilitated by the following agile approaches:

• Supporting the development team with real-time answers to their questions, shielding them from competing priorities, and empowering them to develop solutions and determine how much work to take on in each iteration
• Producing barely sufficient documents
• Streamlining status reporting so that information is pushed out by the development team in seconds rather than pulled out by a project manager over a longer period of time
• Minimizing nondevelopment tasks
• Setting expectations that change is normal and beneficial, not something to be feared or evaded
• Adopting a just-in-time requirements refinement to minimize change disruption and wasted effort
• Collaborating with the development team to create realistic schedules, targets, and goals
• Protecting the team from organizational disruptions that could undermine product goals by introducing work that is not relevant to the product objectives
• Understanding that an appropriate balance between work and life is a component of efficient development
• Viewing the product as a long-term investment requiring permanent teams pursuing value over specifications

Adding the Platinum Principles

Through in-the-trenches experience working with teams transitioning to agile product development — and field testing in large, medium, and small organizations worldwide —three additional principles of agile product development were developed. They’re called the Platinum Principles:

• Resist formality.
• Think and act as a team.
• Visualize rather than write.

You can explore each principle in more detail in the following sections.

Resisting formality

Even the most agile teams can drift toward excessive formalization. For example, it isn’t uncommon to find team members waiting until a scheduled meeting to discuss simple issues that could be solved in seconds. These meetings often have an agenda and meeting minutes and require a certain level of demobilization and remobilization just to attend. In an agile approach, this level of formalization isn’t required.

You should always question formalization and unnecessary, showy displays. For example, is there an easier way to get what you need? How does the current activity support the development of a quality product as quickly as possible? Answering these questions helps you focus on productive work and avoid unnecessary tasks.

In an agile system, discussions and the physical work environment are open and free-flowing; documentation is kept to the lowest level of quantity and complexity such that it contributes value to the product, not hampers it; and flashy displays, such as well-decorated presentations, are avoided. Professional, frank communications are best for the team, and the entire organizational environment has to make that openness available and comfortable.

Strategies for success in resisting formality include the following:

• Reducing organizational hierarchy wherever possible by eliminating titles in the team
• Avoiding aesthetic investments such as elaborate slide presentations or extensive meeting minute forms, especially when demonstrating shippable functionality at the end of a sprint
• Educating stakeholders who request complicated displays about the high costs and low returns of such displays

Thinking and acting as a team

Team members should focus on how the team as a whole can be most productive. This focus can mean letting go of individual niches and performance metrics. In an agile environment, the entire team should be aligned in its commitment to the goal, its ownership of the scope of work, and its acknowledgment of the time available to achieve that commitment.

Following are some strategies for thinking and acting as a team:

• Develop in pairs and switch partners often. Both pair programming (both partners are knowledgeable in the area) and shadowing (only one partner is knowledgeable in the area) raise product quality.
• Replace individual work titles with a uniform product developer title. Development activities include all tasks necessary to take requirements through to functionality, including design, implementation (for example, coding), testing, and documentation — not just writing code or turning a screwdriver.
• Report at the team level only, as opposed to creating special management reports that subdivide the team.
• Replace individual performance metrics with team performance metrics.

Visualizing rather than writing

An agile team should use visualization as much as possible, whether through simple diagrams or computerized modeling tools. Images are much more powerful than words. When you use a diagram or mockup instead of a document, your customer can relate better to the concept and the content.

Your ability to define the features of a system increases exponentially when you step up your interaction with the proposed solution: A graphical representation is almost always better than a textual one, and experiencing functionality hands-on is best.

Even a sketch on a piece of paper can be a more effective communication tool than a formal text-based document. A picture is worth a thousand words. A textual description is the weakest form of communication if you’re trying to ensure common understanding — especially when the description is delivered by email with the request to “let me know if you have any questions.”

Examples of strategies for visualization include the following:

• Stocking the work environment with plenty of whiteboards, poster paper, pens, and paper so that drawing tools are readily available
• Using models instead of text to communicate concepts
• Reporting status through charts, graphs, and dashboards, such as those in Figure 1-2

© John Wiley & Sons, Inc.

FIGURE 1-2: Charts and graphs for providing transparency.

Seeing Changes as a Result of Agile Values

The publication of the Agile Manifesto and the 12 Agile Principles legitimized and focused the agile movement in the following ways:

• Agile approaches changed attitudes toward product management processes. In trying to improve processes, methodologists in the past worked to develop a universal process that could be used under all conditions, assuming that more process and greater formality would yield improved results. This approach, however, required more time, overhead, and cost and often diminished quality. The manifesto and the 12 principles acknowledged that too much process is a problem, not a solution, and that the right process in the right amount differs in each situation.
• Agile approaches changed attitudes toward knowledge workers. IT groups began to remember that development team members aren’t disposable resources but individuals whose skills, talents, and innovation make a difference to every product. The same product created by different team members will be a different product.
• Agile approaches changed the relationship between business and IT groups. Agile product development addressed the problems associated with the historical separation between business and IT by bringing these contributors together on the same team, at equal levels of involvement and with shared goals.
• Agile approaches corrected attitudes toward change. Historical approaches viewed change as a problem to be avoided or minimized. The Agile Manifesto and its principles helped identify change as an opportunity to ensure that the most informed ideas were implemented.

Taking the Agile Litmus Test

To be agile, you need to be able to ask, “Is this agile?” If you’re ever in doubt about whether a particular process, practice, tool, or approach adheres to the Agile Manifesto or the 12 principles, refer to the following list of questions:

1. Does what we’re doing at this moment support the early and continuous delivery of valuable software?
2. Does our process welcome change and take advantage of change?
3. Does our process lead to and support the delivery of working functionality?
4. Are the developers and the product owner working together daily? Are customers and business stakeholders working closely with the team?
5. Does our environment give the team the support it needs to get the job done?
6. Are we communicating in person face-to-face rather than over the phone or through email?
7. Are we measuring progress by the amount of working functionality produced?
8. Can we maintain our current pace of development indefinitely?
9. Do we support technical excellence and good design that allows for future changes?
10. Are we maximizing the amount of work not done — namely, doing as little as necessary to fulfill the product goal for our customer?
11. Is this development team self-organizing and self-managing? Does it have the freedom to succeed?
12. Are we reflecting at regular intervals and adjusting our behavior accordingly?

If you answered “yes” to all these questions, congratulations; you’re likely becoming more agile. If you answered “no” to any of these questions, what can you do to change that answer to “yes”? You can come back to this exercise at any time and use the agile litmus test for yourself, as well as with your team and the wider organization.