The Manifesto for Agile Software Development
Seventeen anarchists agree:

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

TenStep® Project Management Process

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

The experience of the author is that projects executed in an organization have a much better chance of success with a flexible and scalable set of consistent processes. If these processes have been utilized successfully before, there is a greater likelihood that yours will be successful as well.

We consider the TenStep Process to be very “light” but it does represent the minimum requirements to successfully manage projects. Most (but not all) of the philosophies of the TenStep process will support Agile development.

That is, while we value the items on the right, we value the items on the left more.

We follow the following principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The Agile philosophy promotes iterative development, with early requirements followed by working code, followed by more requirements and more code. This is fine, but iterative development is not the best approach for all software projects. Where it can be implemented, it should be tried.

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

Under general iterative development, requirements do not need to be locked down early. However, even with traditional iterative development, at some point, the requirements need to be locked down for the sake of delivering something. At that point, scope change management comes into play.

In Agile, development requirements can change at any point. The thought is that the client can continue to make changes, as long as they prioritize these changes in the appropriate iteration. For example, if the client asked for three reports and later wants a fourth, the fourth report can be added to the requirements list with no problem. At some point, the client will need to prioritize this new report and when they do, the new report will be written. If the client’s budget is open ended, then there is no formal scope change process – whatever the client wants and prioritizes, will be delivered. If the client is on a fixed budget, then prioritizing one change to complete will, in essence, mean that some other piece of work will not get done. In this scenario, the client is enforcing scope change management by ensuring that only changes that are of the highest priority get prioritized while others do not.

The TenStep approach states that when business changes happen, the project team must be prepared to respond. However, requirements changes have consequences in terms of budget and delivery dates and these must be approved by the sponsor. If the team does this, they are practicing scope change management.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The TenStep process recommends that large projects be broken down into a series of smaller ones, each of which can be delivered more quickly and repetitively. Not all projects have this flexibility, but the preference is toward smaller projects when possible.

Agile processes can take the short delivery cycle is to an extreme. Some extreme programming projects deliver on very short cycles of even every week. Although this can be tough to manage, there is nothing inherently wrong with this.

Business people and developers work together daily throughout the project.

This is the best approach to staying in touch with the customers' needs.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Sometimes very motivated people get into trouble delivering projects on time (Deming recognized this a half century ago). They can focus too much on the development details and not enough on managing to a budget and deadline. If motivated people always got their projects done on time, there would be a higher percentage of successful projects. Sometimes you need to place motivated people into a more structured environment where they can be successful. The author believes the best approach is to build projects around motivated people, and then make sure they have the right tools, processes and skills to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

There is no question that personal communication is best in many circumstances. However, there are times when other communication media are fine; for instance, email may be fine when sending status updates to 20 people. Some relevant documentation also needs to be written down – if the information is needed when all the original developers are gone. This documentation should be for important information only.

Working software is the primary measure of progress.

In iterative development, having working software at the end of each iteration is a good measure of progress. However, not all projects can be done using iterative development; for instance, package implementations. So on most projects, you can continue to monitor the plan by major milestones to ensure you are on schedule.

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

Agile development stresses a 40-hour workweek and a pace that can be maintained indefinitely. Of course, with proper planning and management, this is the best approach.

Continuous attention to technical excellence and good design enhances agility.

Technical excellence and solid up-front design decisions are essential to making Agile processes work.

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

Agreed. Software developers and customers should focus on delivering the core requirements first. This "maximizes the work not done." It also allows software to be delivered more quickly.

The TenStep Process follows this simplicity model as well. Projects should be managed according to the size and complexity of the work, with a view that all project management should result in value.

The best architectures, requirements and designs emerge from self-organizing teams.

If every team were high-performing and technically superior, this point would be easier to agree with. However, some project teams are not mature enough and do not have the right skill level to develop the best designs and architectures. It is important that the right people be chosen for these Agile projects.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agreed. Teams should constantly strive to understand their strengths and weaknesses and how the processes can be improved. The TenStep process also believes these recommended changes should be surfaced to the organization so that the improvement ideas can be leveraged by the entire staff.

—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
www.agileAlliance.org