Understanding the Agile Manifesto

The agile project management revolution has transformed project management.  Instead of the fully planned and predictive methods of the past, the world now recognizes that an iterative, cyclical process is significantly faster and cheaper, even if you can’t promise everything up front.

The origins of this revolution trace back to the creation of the Agile Manifesto.

To begin, we will quote the Manifesto in its entirety.

The Agile Manifesto

The Agile Manifesto lives permanently at its home at agilemanifesto.org.  It is available for reference by anyone at anytime.

The Significance of the Agile Manifesto

While it doesn’t seem to provide any practical day-to-day project management instructions or processes, what makes the Agile Manifesto so significant is the change in top-level priorities it brought about.

This is because, prior to the agile revolution, project management consisted of a group of processes that were focused on planning the route between A and B in the highest amount of detail.  The more you could plan, it was thought, the better your project would go.  Every step of the way was meticulously scrutinized to ensure that realistic expectations were established, and then those expectations will be met.  In fact, even changes to the project plan were planned.  That is, Change Management Plans identified when a change to the plan is necessary, what is considered a change, and how the change would be made and approved.  These plans are not totally obsolete, as they can still have value on large projects, but they are considered unnecessary bureaucracy for most projects.

Of course, when things didn’t go according to the plan, which any seasoned project manager knows is most of the time, the resulting changes to the plan were considered net negatives.  They were considered problems to be solved.

The creators of the Agile Manifesto recognized that there is more to project management than this.  Essentially, they valued the “soft” side of project management over the “hard” skills of planning and administration.

• Individuals and interactions over processes and tools
  The first item states that people are more important than processes.  It is clear that even if the project is executed perfectly according to a plan, poor relationships could render the project unsuccessful.   This includes both with the client/customer, and with the project team who performs the work.
• Working software over comprehensive documentation
  This item states that it is important to provide intermediate results on a regular basis.  That is, even if the project is executed perfectly according to a plan, it may not have been a success if nobody had the opportunity to work with the project team to see it coming together.
• Customer collaboration over contract negotiation
  This item makes it clear that working with the customer to achieve a result they are satisfied with is more important than identifying lists of requirements and codifying them into contracts.
• Responding to change over following a plan
  Sophisticated planning and then making changes to the plan costs money.  Since change is inevitable, the planning and change management effort should be addressed during project execution rather than creating a plan that won’t likely be followed anyway.

The History of the Agile Manifesto

The Agile Manifesto was created in 2001, when 17 people descended upon the mountains of Snowbird, Utah, to hold a convention about the future of software development.  They were frustrated with the status quo, which focused excessively on the planning and documentation of software to the point of losing touch with the more people-oriented facets of customer satisfaction.

The conference produced two items:

• The Agile Manifesto
• The 12 Agile Principles

Although the Manifesto and the 12 Principles were developed for the software development industry, other industries have adopted the principles of customer satisfaction over creating and executing detailed plans.

The Implementation of the Agile Manifesto

Guided by the Agile Manifesto, Agile Frameworks provide the day-to-day processes and procedures that implement the agile project management methods.  Agile is the guiding philosophy, the overarching doctrine which steers the ship and the frameworks are the individual actions that ensure it arrives at its destination.

The frameworks are developed within the guidelines of the agile manifesto.  Several agile frameworks are:

• Scrum
• Extreme Programming
• Kanban
• Scaled Agile Framework (SAFe)

The most popular of the frameworks is Scrum.  So popular, in fact, that Scrum and Agile are often mistaken for one and the same thing.  In actual fact, Scrum is underneath Agile.  It is an Agile Framework.

Scrum involves performing the work in a series of sprints each with a duration of 2-4 weeks.  This duration is chosen because it is the typical amount of work which allows for visible progress.  Following each sprint, a Sprint Review meeting delivers and presents new product development functionality to the product owner.  At the same time, a Sprint Retrospective meeting takes place between the project team members, with the purpose of identifying potential changes to their development processes for the next sprint.  A scrum master is not the boss of the project team, rather, they facilitate the meetings, communicate with the product owner, and maintain a sprint “backlog,” which is the priority development items for the current sprint and the next few beyond.

It is difficult to underestimate the impact of the Agile Manifesto on the profession of project management.  It still remains as the rock that holds the entire Agile project management methodology together.