Chapter 2

The Agile Manifesto and Principles

In This Chapter

Defining the Agile Manifesto and the 12 Agile Principles

Describing the Platinum Principles

Understanding what agile has changed

Taking the agile litmus test

This chapter describes the basics of agile: the Agile Manifesto, with its four core values, and the 12 Agile Principles. I also expand on these basics with three additional Platinum Principles, which my corporation, Platinum Edge, crafted after years of experience supporting organizations transitioning to agile. This foundation provides software development teams with the information needed to evaluate whether the project 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 like waterfall, which is discussed in Chapter 1, 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 continues to revolutionize project management in every industry.

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

The Agile Manifesto: An intentionally streamlined expression of core development values

The Agile Principles: A set of 12 guiding concepts that support agile project teams in implementing agile and staying on track

The Agile Alliance: A community development organization focused on supporting individuals and organizations that are 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. Where traditional approaches emphasize a rigid plan, avoiding change, documenting everything, and hierarchal-based control, the Manifesto focuses on

People

Communications

The product

Flexibility

The Agile Manifesto represents a big shift in focus in how projects are conceived, conducted, and managed.

The creators of the Agile Manifesto originally focused on software development because they worked in the IT industry. However, since 2001, agile project management techniques have spread beyond software development and even outside of computer-related products. Today, people use agile approaches to create products in a variety of industries, including medicine, engineering, marketing, nonprofit work, and even building construction. If you can create a product, you can benefit from agile methods.

The Agile Manifesto and Agile Principles directly refer to software; I leave these references intact when quoting the manifesto and principles throughout the book. If you create products that are not software, try substituting your product as you read on.

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?

Value 1: Individuals and interactions over processes and tools

When you allow each person to contribute his or her unique value to a project, 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 that talks through a project issue can solve many problems in a relatively short time. Trying to emulate the power of a direct conversation with e-mail, spreadsheets, and documents can require a lot of overhead. 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 2-1 shows some differences between valuing individuals and interactions and valuing processes and tools.

Table 2-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 customize processes as necessary. Development team members can take personal ownership of the project. Development team members can have deeper job satisfaction.	Processes are clear and can be easy to follow. Written records of communication exist.
Cons	Development team members must have the capacity to be involved, responsible, and innovative. 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 projects. Communication can be ambiguous and time-consuming.

You can find a blank form like Table 2-1 on the book’s companion website at www.dummies.com/go/agileprojectmanagementfd — jot down the pros and cons of each approach that apply to you and your projects.

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 project 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 products. On agile projects, the only way to measure whether you are truly done with a product requirement is to produce the working product feature associated with that requirement. For software products, working software means the software meets what we call the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the project.

If you have worked on projects in the past, have you ever been in a status meeting where you reported that you were, say, 75% done with your project? What would happen if your customer told you, “We ran out of money. Can we have our 75% now?” On a traditional project, you would not have any working software to give the customer — “75% done” traditionally means you are 75% in progress and 0% done. On an agile project, however, by using the definition of done, you would have working product features for 75% of your project requirements — the highest-priority 75% 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 products over comprehensive documentation.”

Tasks that distract from development must be evaluated to see whether they support or undermine the job of creating a working product. Table 2-2 shows a few examples of traditional project documents and their usefulness. Think about the documents produced on a recent project you were involved in.

Table 2-2 Identifying Documentation That’s Useful

Document	Does the Document Support Product Development?	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, the truth is project team members tend to want to know only key deliverable dates. Management often wants to know only whether the project is on time, ahead of schedule, or behind.
Requirements documentation.	Yes. All projects have requirements — details about product features and needs. Development teams need to know those needs to create a product.	Possibly gold-plated. Requirements documents can easily grow to include unnecessary details. Agile approaches provide simple ways to describe product requirements.
Product technical specifications.	Yes. Documenting how you created a product can make future changes easier.	Possibly gold-plated; usually barely sufficient. Technical documentation usually 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 project status is helpful, but traditional status reports contain outdated information and are much more burdensome than necessary.
Detailed project communication plan.	No. While 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.

All projects require some documentation. On agile projects, however, documents are useful only if they’re barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way.

With agile project management, the term barely sufficient is a positive description, meaning that a task, document, meeting, or almost anything on a project includes only what it needs to achieve the goal. Being barely sufficient is practical and efficient. The opposite of barely sufficient is gold-plating, adding unnecessary frivolity — and effort — to a feature, task, document, meeting, or anything else.

When you work on an agile project, however, you concentrate on documents that are necessary to support product development. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.

You can find a blank form like Table 2-2 at www.dummies.com/go/agile projectmanagementfd. Use that form to assess how well your documentation directly contributed to the product and whether it was barely sufficient.

I’ll often stop producing a document and see who complains. Once I know the requestor of the document, I’ll strive to better understand why the document is necessary. The five whys work great in this situation — ask “why” at least five times to get to the root reason for the document. Once you know the core reason for the document, see how you can satisfy that need with an agile artifact or streamlined process.

Agile project teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues. In the coming 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 project teams to understand requirements and assess status daily. With agile approaches, project 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 involve customers at three key points:

Project start: When the customer and the project manager — or another project team representative — negotiate contract details.

Any time scope changes during the project: When the customer and the project manager 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 customer expectations, the project manager and the customer negotiate additional changes to the contract.

This historical focus on negotiation 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 the project start. Locking product details into a contract at the beginning of your project means you have to make decisions based on incomplete knowledge. If you have flexibility for change as you learn more about a product, you will 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 methodologies make the customer part of the project on an ongoing basis.

Using an agile approach in practice, you’ll experience a partnership between the customer and development team in which discovery, questioning, learning, and adjusting during the course of the project are routine, acceptable, and systematic.

Value 4: Responding to change over following a plan

Change is a valuable tool for creating great products. Project teams that can respond quickly to customers, product users, and the market in general are able to develop relevant, helpful products that people want to use.

Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down 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.

Figure 2-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 decreases, and costs more.

By contrast, agile projects accommodate change systematically. In later chapters, you discover how the agile approaches to planning, working, and prioritization allow project teams to respond quickly to change. The flexibility of agile approaches actually increases project stability, because change on agile projects is predictable and manageable.

As new events unfold, the project team incorporates those 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. They augmented the four values of the Manifesto with 12 guiding Agile Principles to support teams making the transition to agile.

These principles, along with the Platinum Principles, explained later in the section, “Adding the Platinum Principles,” can be used as a litmus test to see whether the specific practices of your project 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

Project management

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 for me:

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 on a project in a number of ways:

In project management terms, the customer is the person or group paying for the project.

In some organizations, the customer may be a client, external to the organization.

In other organizations, the customer may be a project stakeholder or stakeholders within 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, in this book, I call that person the user.

How do you enact these principles? Simply do the following:

Agile project teams include a product owner, a person who is responsible for ensuring translation of what the customer wants into product requirements.

The product owner prioritizes product features in order of market 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 a project.

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 and demonstrable features every eight (ideally, four) 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 product features throughout the project, rather than waiting until the end of what might be a long project for the first, and maybe only, delivery of releasable product features.

In Table 2-3, I have listed some customer satisfaction issues that commonly arise on projects. Use Table 2-3 and gather some examples of customer dissatisfaction that you’ve encountered. Do you think agile project management would make a difference? Why or why not?

You can find a blank form at www.dummies.com/go/agileproject managementfd

Table 2-3 Customer Dissatisfaction and How Agile Might Help

Examples of Customer Dissatisfaction with Projects	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 project teams demonstrate and deliver working product features at regular intervals. If a product doesn’t work the way the customer thinks it should work, the customer is able to provide feedback at the end of the sprint, not the end of the project.
The product wasn’t delivered when customer needed it.	Working in sprints allows agile project teams to deliver high-priority product features early and often.
The customers 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.

Agile provides specific strategies for customer satisfaction, as follows:

Producing, in each iteration, the highest-priority features first

Ideally, locating the product owner and the other members of the project team in the same place

Breaking requirements into groups of features that can be delivered in eight (ideally, four) weeks or less

Keeping written requirements sparse, forcing more robust and effective face-to-face communication

Getting the product owner’s approval as each feature 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 project team commits to producing quality in every product it creates — from development through documentation to test results — every day. Each project team member contributes his or her best work all the time. While all 12 Principles support the goal of quality delivery, principles 1, 3, 4, 6, 7, 8, 9, and 12 stand out for me:

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 and be empowered to solve problems. They carry the responsibility for determining how to create the product, assigning tasks, and organizing product development.

Agile software development requires agile architectures that make coding and 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. When the product quality is such that it can be demonstrated and ultimately shipped, everyone knows that the product works.

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 development of the requirement completed.

At the end of every eight (ideally, four) weeks or less, iteration, working code 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.

Checking that new code integrates with previous versions, is tested, and is shown to be working occurs in small increments and may even occur several times a day. 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.

On software projects, examples of technical excellence include establishing coding standards, using service-oriented architecture, having automated testing, and building for future change.

Agile approaches provide the following strategies for quality management:

Defining what “done” means at the beginning of the project and then using that definition as a benchmark for quality code

Testing aggressively and daily through automated means

Building only the features that are needed when they’re needed

Reviewing the code and streamlining (refactoring)

Showcasing only functioning code that has been accepted by the product owner

Having multiple feedback points throughout the day, iteration, and project

Agile principles of teamwork

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

While all 12 Principles support the goal of teamwork, principles 4, 5, 6, 8, 11, and 12 stand out for me 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 a project. 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 team members’ minds sharp and code quality high.

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

Agile approaches require properly skilled, trained, and motivated development team members.

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 project team members responsible as a single team, not individuals.

Use face-to-face communication to quickly, efficiently convey information.

Suppose that you usually communicate by e-mail to Sharon. 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 e-mail 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.

Spontaneous conversations throughout the day build knowledge, understanding, and efficiency.

The closer teammates are located, the clearer and more efficient communication will be. If collocation isn’t possible, use video chat rather than e-mail.

Lessons learned must be an ongoing feedback loop. Retrospectives should be held at the end of each iteration, when reflection and adaptation can improve development team productivity going forward, creating ever higher levels of efficiency. A lessons learned meeting at the end of a project is of minimal value.

The first retrospective is often the most valuable because, at that point, the project team has the opportunity to make changes to benefit the rest of the project moving forward.

The following strategies promote effective teamwork:

Place the development team in the same location — this is called collocation.

Put together a physical environment that’s conducive for collaboration: a team room with white boards, colored pens, and other tactile tools for developing and conveying ideas.

Create an environment where project team members are encouraged to speak their minds.

Meet face-to-face whenever possible. Don’t send an e-mail if a conversation can handle the issue.

Get clarifications throughout the day as they’re needed.

Encourage the development team to solve problems rather than having managers solve problems for the development team.

Agile principles of project management

The role of project management in agile encompasses three key areas:

Making sure the development team can be productive and can increase productivity over long periods of time.

Ensuring that information about the project’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 ensuring that the progress of the project is clear to everyone.

While all 12 Principles support project management, principles 2, 8, and 10 stand out for me:

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

10. Simplicity — the art of maximizing the amount of work not done — is essential.

Following are some project management advantages of adopting agile:

Agile project teams achieve time-to-market, and consequentially cost savings. They start development earlier than in traditional approaches because agile approaches minimize the exhaustive planning and documentation that is conventionally part of the early stages of a project.

Agile development 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 development 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 I can do to achieve the goal?” instead of focusing on including all the features that could possibly be needed. The agile approach usually means streamlining: less documentation, fewer meetings, reduced e-mail, and even less coding.

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, and you will have more time to focus on supporting the development team.

By encapsulating development into short sprints that last four weeks or less, you can adhere to the goals of the current iteration while accommodating change within subsequent iterations. The length of each sprint remains the same throughout the project.

Planning, elaborating on requirements, developing, testing, and demonstrating occur within the confines of an iteration, lowering the risk of heading in the wrong direction 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 development methodology called extreme programming (XP), the maximum work week is 40 hours, and the preferred work week is 35 hours. Agile projects are sustainable and more productive.

Traditional approaches routinely feature a death march, in which the project team puts in extremely long hours for days and even weeks at the end of a project to meet a previously unidentified, unrealistic deadline. As the death march goes on, productivity tends to drop dramatically. More bugs are introduced, and because bugs need to first be found, then corrected in a way that doesn’t break a different piece of functionality, correcting defects is the most expensive work that can be performed. When you overload a system, it breaks down.

Priorities, previous realities on the existing project, 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 project before, you might have a basic understanding of project management activities. In Table 2-4, I’ve listed a few traditional project management tasks, along with how you would meet those needs with agile approaches. Use Table 2-4 to capture your thoughts about your prior experiences and how agile looks different from traditional project management.

A blank version of Table 2-4 is available at www.dummies.com/go/agile projectmanagementfd

Table 2-4 Contrasting Historical Project Management with Agile Project Management

Traditional Project Management Tasks	Agile Approach to the Project Management Task
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 the project.
Conduct weekly status meetings with all project stakeholders and developers. Send out 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 discuss 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.
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 helping remove impediments and distractions. On agile projects, development teams define their own tasks.

Project management is facilitated by the following:

Supporting the development team

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 longer periods 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 development team from organizational disruptions that could undermine project goals by introducing work not relevant to the project objectives

Understanding that an appropriate balance between work and life is a component of efficient development

Adding the Platinum Principles

Through in-the-trenches experience working with teams transitioning to agile project management — and field testing in large, medium, and small organizations worldwide — I developed three additional principles of agile software development that I call the Platinum Principles. They are

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 project teams can drift toward excessive formalization. For example, it isn’t uncommon for me to find project 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 mobilization and demobilization 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 project, not hampers it; flashy displays, such as well-decorated presentations, are avoided. Professional, frank communications are best for the project team, and the entire environment has to make that openness available and comfortable.

Strategies for success with resisting formality include the following:

Reducing organizational hierarchy wherever possible by eliminating titles within the project team

Avoiding aesthetic investments such as elaborate PowerPoint presentations or extensive meeting minute forms

Identifying and educating stakeholders who may request complicated displays of work on the costs of such displays

Thinking and acting as a team

Project 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 project 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. You can learn more about pair programming in Chapter 15.

Replace individual work titles with a uniform “product developer” title.

Report at the project team level only, as opposed to creating special management reports that subdivide the team.

Replace individual performance metrics with project team performance metrics.

Visualizing rather than writing

An agile project 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.

Our ability to define the features of a system increases exponentially when we step up our interaction with the proposed solution: A graphical representation is almost always better than a textual one, and experiencing the 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 textual description is the weakest form of communication if you are trying to ensure common understanding.

Examples of strategies for visualization include

Stocking the work environment with plenty of white boards, poster paper, pens, and paper so that drawing tools are readily available

Using models instead of text to communicate concepts

Reporting project status through charts, graphs, and dashboards, like those in Figure 2-2

Changes as a Result of Agile

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

Agile approaches changed attitudes toward project 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 project. The same product created by different team members will be a different product.

Agile approaches changed the relationship between business and IT groups. Agile project management addressed the problems associated with the historical separation between business and IT by bringing these contributors together on the same project 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 Manifesto and its principles helped identify change as an opportunity to ensure that the most informed ideas were implemented.

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 software?

4. Are the developers and the product owner working together daily? Are customers and business stakeholders working closely with the project team?

5. Does our environment give the development team the support it needs to get the job done?

6. Are we communicating face to face more than through phone and e-mail?

7. Are we measuring progress by the amount of working software produced?

8. Can we maintain this pace 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 goal of the project?

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 of these questions, congratulations; you are truly working on an agile project. 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 with your project team and the wider organization.