The Agile Manifesto of project management

The Agile Manifesto of project management

Manifesto for Agile Software Development

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.

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.

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.

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.

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.

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.

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.

By contrast, agile projects accommodate change systematically. 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.

The Manifesto focuses on

    \

•  People
• Communications
• The product
• Flexibility

Outlining the Four Values of the Agile Manifesto