Guide to Agile Project Management

In case you haven’t noticed, agile is the new buzzword in project management.  That’s because it speeds up project completion times, increases customer satisfaction, and decreases project costs.

Agile started in software development but it’s spreading to other industries.  It’s truly the new way to do project management.

But what is all the rage about?  In this article, I will explain how it works and how it’s different from traditional project management practices.  To get you up to speed on Agile, there are 7 things you need to know.

1. The Agile Manifesto
2. Agile Principles
3. Agile Frameworks
4. Iterative vs. Predictive
5. Agile Artifacts
6. Agile Roles and Responsibilities
7. Benefits of Agile

The Agile Manifesto

When Agile was originally developed, seventeen members of the software development industry met at a retreat in the Colorado mountains and drafted the Manifesto for Software Development.  Today this is called the Agile Manifesto and it is the governing document for the methodology.  It says:

That’s it.  68 words that are changing project management!

Unlike the Project Management Body of Knowledge (PMBOK Guide) or PRINCE2, Agile is not a set of tasks that must be performed to achieve project success.  Rather, the massive project management plans of the past are replaced by a culture of responding to change, as can be seen by the last bullet.  In that way, Agile project management is the antithesis of the obsessive planning of traditional project management, but that said, Agile does not oppose planning.  Only that detailed planning should happen for near-term work where it has more value, rather than distant future work that is likely to change and render the planning effort obsolete.

But how then, does one implement Agile project management?  The Agile Manifesto is concise and powerful.  Although it packs a whole bunch of methodology into its few short paragraphs, the 12 Agile Principles serve to further clarify the working details of the method.

The Agile Principles

In the few months following the publication of the Agile Manifesto, the Agile founders continued to communicate.  The 12 Agile Principles were formed to further clarify the methodology and provide a litmus test to determine if an implementation framework was Agile.  The 12 principles are:

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.

As you can see, the Agile principles move the Manifesto into smaller, more detailed statements which can be used in day-to-day project delivery.  But they still don’t give you direct implementation steps.  In fact, Agile is not a step-by-step method.  Instead, it relies on frameworks to do the heavy lifting.

Agile Frameworks

After the publication of the Agile Manifesto, various Agile frameworks began to pop up which provided the nuts and bolts of the methodology’s implementation.  The frameworks provide the tasks, similar to the PMBOK Guide or PRINCE2, and the Agile Principles provide the litmus test to determine if the framework is Agile.

The Agile Frameworks include:

1. Scrum
   By far the most popular, the scrum framework utilizes a scrum team which consists of the product owner, development team, and a scrum master.  The scrum master is an agile expert who guides the team and removes obstacles to their productivity.  Each iteration, or “sprint” lasts between one and four weeks at which time completed, working product is presented to the product owner.  At the beginning of each sprint, a sprint planning meeting is held which determines the tasks which will take place during the sprint, taken from the “product backlog.”  At the end of the sprint, two meetings occur, a sprint review and a sprint retrospective.  The sprint review presents completed, working product functionality to the product owner, and the sprint retrospective meeting provides a place for the project team to look inward and find areas of improvement.
2. Extreme Programming
   This framework gets its name from the practice of taking good software development practices to the extreme.  For example, since frequent delivery of working, tested software to the owner is normally considered good practice, extreme programming seeks to deliver software every single day instead of weekly or monthly.  The sprint is shortened to the smallest possible cycle, and testing happens in conjunction with development.
3. Lean Software Development
   Lean is actually a well used system for production floor manufacturing (i.e. factories) originally developed by Toyota in the 1940’s, however the method has been adapted to software development.  It is a just-in-time philosophy where the assembly line is designed such that raw materials are supplied as needed rather than stored in large inventories.  Kanban cards follow the input resources through to the final product.  In lean software development, a kanban board is a simple board with four status categories (backlog, in-progress, in-testing, and complete), and each product feature proceeds through them as it gets developed.  Some kanban boards use other project-specific categories, such as accepted or waiting for others.

There are many other agile frameworks, and more are being developed.  Some don’t even have a name, and will never have one.  Basically, if you use a system that conforms to the Agile principles, your project is considered Agile.

Iterative vs. Predictive

First and foremost, Agile project management is iterative.  That is, projects are planned and executed in smaller steps rather than planned completely and executed in one huge step.  In contrast, traditional project management is called predictive, because it seeks to plan and predict the outcome of the project before the work starts.

Although Agile is taking over the project management world, it is not that agile is a different method and traditional project management is being rendered obsolete.  Rather, Agile and Traditional project management fall on a continuum, like this:

 

• A fully agile project would perform no planning up front, and deliver the project in increments that are planned during each increment.  Budgets and schedules would, naturally be in flux, but the lack of up front planning would deliver the project cheaper and faster overall.
• A fully traditional project would perform all the planning up front, and attempt to delineate and define the entire project budget and schedule before any work starts.

As you can see, the answer lies somewhere in the middle, and the ideal spot on the continuum might vary for different projects, people, and industries.  Traditional project management has fallen on the far right end of the spectrum and the agile revolution is pushing the project management profession to the left.

Agile Artifacts

Like traditional project management, the agile project manager maintains control over the project using various documents, called artifacts.  Unlike traditional project management, however, the documents are not a fixed structure that must be maintained.  After all, the response to change must always take precedent over sticking to a plan.

The following list will blur the lines between the overarching Agile project management methodology and the Scrum framework, but because the scrum framework is by far the most popular way to deliver agile projects, we will present this list of documents as a structure to deliver agile projects:

• The Product Vision
  Although it may seem like agile projects “fly by the seat of their pants,” due to lesser up front planning and rapid response to change, there is actually a strong infrastructure in place that keeps the entire project on a firm foundation.  The first of these is the product vision.  Since it’s hard to identify every detail of the final product up front, the product vision is the definition of the end goal.  For example, what features are must-have, what need the product will fulfill, or who will use the product.  When tough decisions about features need to be made, the product vision provides the guidebook.
• The Product Roadmap
  The roadmap is the closest thing to a project management plan in agile.  It specifies the main project features and delivery dates.  It keeps an overall view of the project and provides a guideline for the general product functionality that is expected to be delivered and its time frames.  It also provides budget estimates for each feature.  When product features are not being delivered according to the product roadmap, decisions can be made to remove certain features, or otherwise alter the project.
• Product Backlog
  This artifact breaks the final product down into its constituent project tasks, similar to an Activity List in the PMBOK Guide.  Each task is assigned a tracking kanban card, which is often a simple sticky note on a whiteboard but more sophisticated software kanban boards can track many activity attributes as well.  When a task needs to be added due to changing project requirements, another kanban card is added to the product backlog and a corresponding card must be removed (or the project budget and schedule must be increased).
• Release Plan
  Each iteration does not necessarily need to be associated with fully functional product, and it is often better to keep the iterations smaller than peg them to a release of product.  For that reason, the release plan can be different than the product roadmap.  It specifies when the project expects to release functional product to the owner.
• Sprint Plan
  At the start of each iteration, items from the product backlog are moved into the iteration backlog.  In scrum, this is called a sprint backlog.  The iteration plan is the set of tasks that the project expects to complete within the iteration.  The iteration should be small enough that the ability to meet the goal is fairly certain.
• The Daily Scrum
  In the scrum framework, a meeting takes place every morning which is facilitated by the scrum master and attended by the development team and product owner.  In this meeting, each member of the development team answers the questions:
  • What did I do yesterday?
  • What will I do today?
  • What impediments are in my way?
• Sprint Review
  At the conclusion of each sprint, a meeting attended by the full scrum team (scrum master, development team, and product owner) meet to discuss what was accomplished and deliver the completed product to the product owner.
• Sprint Retrospective
  Also at the conclusion of each sprint (usually right after the sprint review meeting) a sprint retrospective is performed by the scrum team to assess their processes and make adjustments.  This is the essence of agility, to adjust the project team’s methods at regular intervals to “turn the ship” quickly if necessary.

Hence, each sprint contains the same level of planning as traditional project management.

The planning is localized to the iteration, hence there is little wasted planning effort.  Budget estimates, schedules, quality criteria, and risk planning are all undertaken at the sprint level and refined at each iteration rather than once for the whole project.

Agile Roles and Responsibilities

Once again, this list will blur the lines between Agile and Scrum, however since scrum is by far the most popular way to deliver agile projects, we will present the following agile project roles:

• Scrum master
  The scrum master is, in strict scrum terminology, not the boss of the project management team.  Rather, they are the member with the most knowledge about agile and scrum methodology, and their job is to keep the project at its maximum agility.  They promote agile practices, facilitate the scrum meetings, and remove impediments out of the development team members’ way so that productivity can be maximized.
• Development team
  The development team is the traditional project team that works together to produce the project deliverables.
• Product owner
  Unlike most traditionally managed projects, where the owner (project sponsor) doesn’t talk to the project manager unless things go wrong, the product owner is an integral part of the agile project team.  They attend the daily scrum meetings, provide input to the product backlog, and provide comments on completed functionality.  If more work needs to get done in one area, the development team creates a new item in the sprint backlog, but the product owner must make decisions as to what to remove in its place.
• Stakeholders
  Although not strictly part of the agile team, many projects have other stakeholders like financial people, product end users, affected parties, and so forth.  These stakeholders are kept informed by the scrum master and may attend daily scrum and/or sprint review meetings.

Benefits of Agile

Why is agile so much better than traditional project management?  The answer lies in four steps:

1. Greater customer satisfaction because the owner is intricately involved at every step, accepting completed product and guiding the development team in product development.
2. Faster response to project change which reduces project cost and schedule overruns.
3. Projects are delivered cheaper because of the elimination of massive up front planning initiatives that are rendered obsolete once the work takes place in the distant future.
4. Higher quality products because the product owner is delivered the product in increments and can easily make changes until it is refined just right.

In an era when so many projects suffer from budget and schedule overruns, product quality issues, and general owner dissatisfaction, most project managers would be wise to consider agile project management techniques.

It’s definitely a buzzword that’s deserved.