1. Agile Manifesto
2. 12 Principles of Agile
3. Agile Declaration of Interdependence
4. Agile vs Waterfall

Back in 2005 (the year of the Declaration of Interdependence for Agile PM) I first learned details about Agile project methodologies and I could distinguish some benefits of the method. While it was clear that fresh air was coming in PM methodologies I had the feeling that, for most real life projects, Agile was a bit “frightening” for customers and for development companies and unknown to people sticking on traditional PM and software development methodologies.

Recently (2012) PMI announced its Agile certification program (PMI-ACP) and Agile drew my attention again. Some may wonder why PMI should get involved in another methodology as they already have PMBoK well established. I think that the reason is the fact that more and more projects use Agile methodologies and tactics and some statistics showing improved results on delivery of products and services (according to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects).

Software industry was always rapidly changing by itself and software projects were always projects where changes often appear; Agile is gaining more space.

With a series of articles I will try to briefly cover the key points of Agile Methodologies in the framework of my PMI-ACP certification.

The Agile Manifesto

In 2001 the Agile Manifesto was published.

“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.”

What follows are some comments on the above. First, I would like to mote that Agile came out mainly from Developers (not PMs or theoreticians on the field) as “a better way of developing software”. While most PM methods followed have their origin in an era when we didn't have software development -at least in the scale we have nowadays-, Agile started with software development in mind. Later, some new literature and bibliography for applying agile methodologies on any other project appeared from some of the authors of the Agile Manifesto.

Individuals and interactions: Agile focuses in repeated iterations of people that form a working team - Group. The teams have short term plans compared to other methodologies. That doesn't mean that we don't have a plan for the whole project, but, within this main plan, teams may be flexible to decide what comes next.

Working software: We should minimize the time we spend on reports and plans (we should have “just barely good enough” documentation and we should focus on working software.

Customer Collaboration: Customers should be involved constantly while developing. We should deliver small working parts of software more often and not big parts after long periods of development.

Responding to change: When a change request arrives, we should spend our time on how we can do it and not on how we will avoid it.

Twelve Principles of Agile Software

These 12 principles accompanied the Manifesto and are quite explanatory by themselves.

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

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

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

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them 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.

Working software is the primary measure of progress.

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

Continuous attention to technical excellence and good design enhances agility.

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

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

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

Declaration of Interdependence (DOI)

In 2005, the DOI was published by a “a community of project leaders that are highly successful at delivering results” in order to show what they do to achieve these results.

“We are a community of project leaders that are highly successful at delivering results. To achieve these results:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.”

Some comments on the above:

Flow of Value: We deliver value to the customer. Something that works is fine; something that, for example, works in a way that outperforms competition is Value.

Shared ownerships: The Customer is so much involved in the deliverable that s/he feels part of the development team and not just a controller or an auditor.

We expect uncertainty: Change is something we expect and not something we are afraid of.

Group accountability for results: The Group is accountable for the deliverable not the individuals. To my mind, this links perfectly with one main characteristic of high performance teams where the problem of someone is considered as everyone’s problem.

Situationally specific strategies: The Group should be free to change tactics and processes based on situations that may vary during the project life cycle.

Agile vs Waterfall

In my opinion, the main difference is that Agile focuses on how to do things while other methods focus on what to do.

Here is a list of differences regarding the methodology.

Finally, Agile, as every method is not suitable for all projects but it can be a real relief for projects that fit.

References
Agile Manifesto: agilemanifesto.org
Declaration of Interdependence: pmdoi.org
wikipedia.org: en.wikipedia.org/wiki/Agile_management‎