Agile Project Management and Planning – An Overview (Part One)

Agile project management, (also known as Agile Software Development, eXtreme Project Management among others), is a non-traditional approach to planning, controlling and sustaining a project. Traditional project management methodologies approach project management with a focus on the specifications being the model for the final deliverable, and therefore focus on the final deliverable. This view, although very useful in certain situations, does not in itself logically mirror real-life projects. When approaching projects in the traditional way certain things are inherently unnatural:

1. Molecular Viewpoint – Also called ‘stakeholder viewpoint’. This is the very specific perspective of need from a specific stakeholder. Traditional methodologies are interested in the molecular viewpoint in so much as it defines specifications. The molecular viewpoint is therefore used only for that purpose, and the specifications that result from the molecular viewpoint become the viewpoints definition.

2. Final Diagnosis – Also called ‘final estimate’. Traditional project management states that there needs to be a complete understanding of what will be delivered, which can only be found through specifications. This approach creates a view of deliverables that is limited in its quantification, due to the limitation of specifications collected. This is very appropriate for some projects.

3. Grossly Focused – With a general focus staged at a high-level, traditional project management tends to emphasize delivering the project on-time, within scope and within budget; with very little awareness of actual acceptance.

Although any project manager reading this may say, “But I care about what my stakeholders think!” or even “If we don’t give an estimate, based on what we believe needs to be delivered, then what would we estimate on!?”. These are very good and all too common responses from someone with a traditional project management background. That isn’t to say that these statements are true or false, because they are actually both.

When beginning any project there is one very important thing to be aware of: Knowledge. How much do you know about the organization? How much do you know about the product that the project hopes to deliver? And depending on the product, how much do you know about the stakeholders, and their anticipated usage of the product? This last question is where Agile and Traditional project management depart, and the above two statements become both true and false. In a sentence; Agile project management is stakeholder/user centered, while Traditional project management is product/deliverable centered. Demonstrated in point one above, Traditional project management appeals to stakeholders for their feature, functionality and even style requests; which is usually done during the initiating and planning phases. Agile project management follows suit and additionally seeks to continually revisit with the stakeholders to acquire a fresh understanding of the molecular viewpoint, before moving on to another portion of the project. Do not confuse this with stage gates. Stage gates are the immeasurable instances in a project where a previous phase is verified/OK’d/signed-off, before the next phase can begin. Iteration points in an Agile project are a completely different animal. They are the close collaboration of developers and end-users, going through iterations of build/rebuild, test and feedback; seeking to eventually reach deploy. By approaching the project in this ‘piece-by-piece’ style, there is an innate successful handling of changes in scope; there is also the safety of being able to bail before being too deep into an unnecessary project. Here is a simple diagram to give you a better feel for Agile in action.

And here is a simple Diagram to help you understand a Traditional approach, also referred to as ‘Waterfall’.

Hopefully seeing these two methodologies in graphic form makes it easier to understand the differences, as well as the similarities. It’s obvious that there are projects for which a Traditional/Waterfall methodology would be best, such as:

• Projects with very well-known objectives in regards to functionality and deliverables

• Projects with little or no requirements/specification changes

• Projects with a larger number of participants and stakeholders (>40)

• Projects with a larger number of developers (>20)

• Projects in environments with weak or poor communication standards

• Projects in an organization that shuns negotiation

• Projects in institutions lacking trust/camaraderie amongst employees

Likewise Agile tends to flourish under certain conditions for which it was intended, and has been demonstrated to excel:

• Projects with little, unknown or constantly changing requirements/specifications

• Projects with teams that are co-located

• Projects with an Object Oriented focus

• Projects within organizations that have rapid communication standards

• Projects with stakeholders that are good communicators and very competent

• Projects with several (<20) developers who are very competent

• Projects within organizations that trust and rely on developers for guidance/decisions