What Does the Agile Manifesto Mean?

24 April 2013

Scott Ocamb
Creative Business Solutions

As we all know, the Agile Manifesto was authored at a ski lodge in Utah in 2001. These important guidelines and principles drive much of what we do. These simple, elegant words are very difficult to use in the real world and sometimes, in my opinion, are misunderstood.

I thought I would write some words about Agile from the direct perspective of the Agile Manifesto. If we remember the overall idea these people had in mind and allow for flexibility, we can increase our chances of success.

I will start with the four main points of the Manifesto. They are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Directly following these points is the following sentence: "That is, while there is value in the items on the right, we value the items on the left more."

The phrase "while there is value in the items on the right" is often left out of our thoughts as we deliver Agile solutions. I will explore each of the four points and provide my thoughts as to what they mean to me.

Individuals and interactions over processes and tools

People are required to deliver software. The people who want and need the product must explain it to the team that delivers it. This is a very hard thing to do. The people who need the software are overworked at their normal day-to-day jobs. When it's decided that a software product is required, these people must take the time to think about what's needed in addition to doing their regular work.

As detailed processes and sophisticated tools were developed, the focus shifted from the people to the tools and process. Vendors would sell a process or tool as a solution. All along, it was still people. What this point means to me is that the focus should be on the people and the communication between them. The process and tools should be the minimum needed for a given situation.

For a start-up firm that's building a product with a short time to market, a simple, lightweight process and few or no tools may be the proper solution. Here a large whiteboard and 3x5 cards may be best answer. For firms that are regulated and audited, more process is necessary and more formality is required. Here, very formal tools and process may be required. This will be different based on each situation. An objective should be to use the minimum amount of process and tools and no more. Use just enough to get the job done.

Start with the people and then decide what level of process and tools is necessary for a given circumstance. Use established Agile techniques to facilitate individuals and interactions.

Working software over comprehensive documentation

Many projects that have thick binders of software requirements have failed. This is the model for the typical Waterfall approach. Under this approach, the delivery team interviews the customer and documents the requirements. The customer is asked to read the requirements and sign off on them. Then the delivery team builds and tests the product described in the requirements.

We have learned that it is virtually impossible for customers to document the computer system they need. Even if they could do this, it's likely that the needs will change between the time the requirements were signed off on and the product ships.

I believe the Agile approach of building potentially shippable increments of the product in short periods of time is one of the most tangible changes and benefits an Agile process provides. This demonstrates progress and builds confidence between the customer and delivery team because useful software is constantly being delivered. The customer also sees an evolving product and will notice things that never would have come to light if a thick binder of requirements had been used.

So what level of documentation is proper? The philosophy of Agile is to do the least amount of something and no more for a given situation. A regulated industry will require much more documentation and trace matrices than an unregulated one. Agile process can accommodate this whole spectrum of needs.

Customer collaboration over contract negotiation

I believe this is one of the most misunderstood points of Agile. No one is saying that we don't need contracts and all collaboration is informal. I take this to mean that the iterative delivery approach will have a better chance of delivering a product that provides the customer with a competitive advantage than a contract that is signed early in the lifecycle and is difficult to change.

When we focus on a contract, we get a false sense of security and think everyone agrees to what is being done. After all, we have a signed contract, so we must be OK. In reality, we do not know what we do not know. An iterative approach is the best solution to this problem.

We need contracts. They just need to be flexible and have the proper change control built in to accommodate an Agile process. There is a "sales" effort that's required to convince the customer of the benefits of a more "flexible" contract approach. We need to explain that there will be many opportunities for change and that the customer will be in complete control.

What if we are forced to use a fixed-price contract? Does this mean we cannot do Agile? I believe we can. Although this is not the preferred approach, Agile still provides a process that increases our chance for success. With fixed-price contracts we need to include proper language in the change-control section and include this in our process. We can discuss changes in our release planning and sprint review meetings and obtain the proper approval for them when they're required.

Responding to change over following a plan

Many projects that have elaborate project plans with detailed Gantt charts have failed. We make the plans so complex and detailed that they're difficult to modify when changes occur. Agile process replaces project plans with release schedules and burn-down charts that can accommodate change. We can still track progress and, in fact, progress is more transparent than in a typical Waterfall project plan.

Agile is actively transparent. This means that the progress on the project, good or bad, occurs as a result of the process. There is little need for separate updating of progress reports.

In conclusion, it's the results that matter

The whole purpose of the Agile Manifesto is to deliver better software. We need to focus on value and results that add to a firm's competitive advantage.

Of course, this was always the intention of Waterfall projects. It simply did not happen very often. All too often we focused on the process and documentation, which resulted in a false sense of security; and we didn't communicate with the people who, in the end, are most important.

However . . .

There are also examples of Agile projects in which people forget the importance of the "items on the right." This is also an improper choice. Delivering the proper software product is still very hard. Agile doesn't change that.

Using an Agile approach gives us permission to lessen the need for formality, but we should not disregard it. We will close with one of the 12 principles of Agile that is pertinent to this discussion: "Simplicity — the art of maximizing the amount of work not done — is essential."


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.2 (5 ratings)

Comments

Rex Lester, CSM, 4/24/2013 2:51:36 AM
Thank you for a very illuminating article.
It appears that right or wrong more and more of our customers are insisting on fixed price contracts. This is driven by the contract negotiators who want to transfer risk to the supplier.

You must Login or Signup to comment.