The Agile Manifesto and Principles

  • Agile
  • The Agile Manifesto and Principles

I think it is best to start off a discussion of agile development with reference to the formal origin. The Manefesto for Agile Software Development is the definition of the approach, or methodology, to agile software development. Created in 2001, by a group of 17 developers, the Agile Manefesto stands as the basis for what is defined as 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.

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

What is the Manifesto declaring here? It is a list of principles and intentions. A public policy that states that we will value individuals and their interactions with one-another over the processes and tools that are used in project development. Individuals and their interactions are about people and organizational culture, the environment they are in when collaborating on a shared set of goals. A culture that supports individuals in a fluid structure, allowing for a sharing of roles and creativity. People are empowered in this culture, empowered to create and contribute, to provide solutions to problems and interact with anyone else on the project team. This culture is not about blame, it is about honesty and accountability where mistakes are leveraged as a tool for improvement and learning.

The Manifesto states that we will value working software over comprehensive documentation. Indeed, what is really the most important deliverable we can give the stakeholders? Working software. Additionally, the tenets of “Clean Code” provide that well written code is self-documenting. By using techniques of convention within software development, we are able to produce documentation as a byproduct of well written code. During discovery, using techniques such as user stories, we are able to capture user requirements documentation directly from the customer, which then is developed into the functionality of the project. As such, we have allowed the client to participate in, not only the definition of the project, but in the development of the project documentation. The point is that we can develop a set of documentation that provides nothing without working software. Obviously, we as developers need to understand what it is that we are going to build. In planning, we use tools to define such aspects as the functionality, the integration and flow, the user interface design, etc… These are very important to our discovery of what it is that we are building and ensuring that what we are about to build is aligned with the vision and roadmap of the project. In the end, however, it is the working software that determines success or failure of the project, not the documentation.

The next mantra of the Manifesto is customer collaboration over contract negotiation. Are you really arrogant enough to think that you know what your customer needs? Should customer collaboration be limited to a requirements document, an executive summary, change orders, project documentation, and a contract, not to mention several other standard project documents? What about interaction with the client throughout the process? Client involvement IN the project, throughout the project, has the intended effect of empowering their ownership in the project. Involving the customer in the day-to-day development ensures their accountability in the project. Customer collaboration provides that we may develop intricacies in the project that not only meet the customer needs but that are within the project scope; scope can be determined and developed in real-time with the interaction of the stakeholder. What is this collaboration thing? Collaboration is effective, ongoing, communication with the client that gives us, as developers, the means to listen and understand the client requirements. Collaboration is our opportunity to provide alternatives, point out potential problems, to guide and consult from our professional point of view how we might best achieve the client’s vision.

Lastly, the Manifesto states that we value responding to change over following a plan. We are fluid, adaptable, able to bend and redirect the project flow without causing a project failure. We are able to write code in such a way as to easily incorporate new features, change existing functionality, and provide for changing needs within the project’s lifecycle. Any plan, no matter how accurately drafted, is subject to change. “Plans in the sand”. Obviously, we must have plans in order to communicate processes. However, it is the plans themselves that must be adaptable and their authors understand that they are but a draft. Changes need to be assessed and it is important to perform impact analysis on these changes. It is important to address changes to scope and cost. The point is, that a plan be able to adapt, to communicate the effects of change, and to incorporate resulting information relevant to deliverables, risks, costs, time, and the impact on down-stream resources.

The Manifesto was created, based upon 12 self-explanatory principles as a guide to software development practice:

Principles behind the Agile Manifesto

We follow these principles:

  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.
Series Navigation<< Agile