A Project Management Article by Mark Tolbert
In January 2012, Mark Tolbert presentated a popular PM Tools Workshop "Agile Project Management versus the PMBOK Guide and Earned Value Management". This article is Part Two of a seven part series that he wrote on the topic. To read Part One, which ran in our March 2012 newsletter, please visit www.pmiwdc.org/articles. Be on the look out for the May - September Newsletter for the remaining five sections. You can also access a print friendly version of the article.
APM’s (Agile Project Management’s) criticism of the Waterfall method
Let's take a step back, and describe how software projects were often done in the past with the waterfall method, and contrast this with the much more iterative approach that's recommended in Agile Project Management.
In the past, the classic way most of us designed new software applications was to use the “waterfall method.” A precise sequence of phases was undertaken to plan the project, execute, test and close out the project. We first captured our high level requirements – (user requirements, functional requirements or business requirements). In the old way of doing things, this might take a couple of months alone.
We then defined the "subsystem specifications,” or the system architecture including file layouts and the modular layout of key program pieces. Again, for a large application, this might take a couple of months. Then the programmers could begin their work, and start the development phase coding all the modules. Depending on the size of the software application this could take a year or even longer. Then the application went through unit testing and integrated testing, and this continued until the application passed all of the acceptance tests. Again, this could take months. Therefore, it might easily be more than a year before the customer actually saw the working application!
What has happened in this timeframe, - in this one to two years? Of course, the customer’s requirements have changed. Also, it's not until the customer has seen the application and used it, that they understand what they truly need. And, even worse, it may not be until the customer actually sees the application that we learn if we really understood their requirements to begin with. So, in a very large percentage of cases, there's going to be some disappointment when the customer does see the application, and major corrections are going to be needed.
Depending on the number of changes, and the level of these changes, it may be a significant amount of time before the customer gets the application they truly need, and significant additional expenditures could be required. We have many of the ingredients of project failure: scope creep, schedule delays, cost overruns and an unhappy customer!
Agile’s Iterative Approach
Again, Agile is meant to address situations where it is a given that at the beginning of the project where the requirements are very undefined: the customer does not really know in any depth what they need, or what they want. Therefore, we will undertake the project in such a way to let these requirements emerge, or be discovered. Therefore, with Agile Project Management (APM), we will use a very iterative approach to tease out these requirements.
We must have a strong "product owner" (or product owner team) that can analyze and identify key requirements – or the product backlog – at the outset. We then go through a series of iterations – (or in Scrum–“sprints.”) An initial set of the product backlog is chosen for the first iteration, and this is developed by the project team very quickly – usually within a two week to four week time frame. (Again in Scrum, this would usually be a one-month “sprint.”) In all cases, in APM, it's a defined "time boxed" short period of time.
The team is given complete freedom and authority on how to best develop (or elaborate) the “stories” (or requirements) for the first iteration. The team usually consists of 7 to 8 cross-functional, co-located dedicated individuals, and they (not the project manager) are responsible and accountable for creating the backlog within the defined timeframe. They are empowered, and given complete autonomy and independence on how best to achieve this backlog in the required timeframe. They should not be interfered with during this iteration by upper management, or other stakeholders. The project manager – (in Scrum – the scrum master) is acting principally as a facilitator, and his or her key job is to remove barriers and obstacles that could impede the team from achieving their goals, and ensure that they are not interfered with.
The team meets on a daily basis, – (in a “standup meeting” – or in a “Scrum.”) This is a short 10 to 15 minute meeting where everyone remains standing (resembling a rugby scrum). Assuming the meetings occur at the beginning of each day, each individual describes what they have accomplished the previous day, what they will do today, and what issues they may be facing. (At the standup meeting, the purpose is not to solve any of these issues, instead, they are taken off-line, and the team members independently decide best how to resolve the issues.) At the end of each iteration, the customer - along with the team and product owner - reviews the product backlog (prototype) that has been created, and it is either accepted or not.
Ideally, the product backlog created during the iteration is something that could be put into production, and truly used. Also, at the end of each iteration the team goes through a “review or adaptive process” – to catch their breath and get reenergized, and to reflect, learn and adapt. This is usually just a half-day meeting. After each iteration, a new backlog is chosen for the next iteration, and new features and requirements are added on to the previous prototype.
The prototype is progressively elaborated in repeated iterations (or sprints), in a very efficient manner. The customer (product owner) gets to see real tangible products very quickly, and determine the features that are most important and those that are not. In APM, they say we are able to “identify fast failures."
This Iterative Approach Used in Agile Solves Most of the Problems of Waterall
By using the Agile approach, this will solve most of the problems previously mentioned with the waterfall method:
- We will quickly get feedback from the customer – (not wait the traditional amount of time of more than a year as we did with the waterfall model).
- As Doug DeCarlo says, we will be able to “Identify Fast Failures:” – early in the project we will learn what is not working.
- Determine if we did understand the requirements properly
- Also, oftentimes, it’s not until the customer sees and uses the product that they truly understand what they need.
- Oftentimes, requirements they thought were essential, they realize are not!)
- So, we don’t waste time on non-essential requirements.
- We won’t waste time planning and trying to estimate the unknown.
- We have a cross functional team working together creating the prototype – (or the iteration) – and this is all centered on capabilities, and features that provide functionality for the customer. During the iteration, we come up with a working prototype that is tested and documented. Therefore, the work that would normally occur across several phases in the traditional model – (design – implementation – testing – documentation) – all occurs within a one month iteration, and the cross functional team is responsible for the iteration. Therefore, we do not have the scenario where business analysts define the customer requirements, and then hand these off to the engineers to try to implement who then hand off their products to testing and quality control, and then, finally, we document the product or service. Oftentimes, in this scenario, there will be a number of disconnects and places where the original customer requirements get lost in the translation.
- From Doug DeCarlo's book:
- “If a picture is worth a thousand words, a prototype is worth a thousand pictures!”
So, again, most authors of books and articles on Agile Project Management view APM as a complete departure from practices described in the PMBOK® Guide. They describe it as a new revolutionary approach, 180° in the another direction from the PMBOK® Guide, As noted above, in APM, most of the traditional terminology has been replaced by new terms and jargon.This is on purpose!
The authors of these new approaches are very aware there are similarities in meaning between the new terms and traditional definitions, but they want to use new terms to emphasize that in APM, teams will be managed in a different way, requirements will be handled differently, and in general, it will not be the old standard way of doing projects. Also, they go to lengths to describe different approaches for managing projects: from planning, through monitoring and controlling, change control and documentation. For these authors, this is a new revolutionary approach.
In APM, it's a mistake to try to plan the project in detail upfront, and then stick to these plans or baselines. There is less focus on meeting the classic “triple constraints” and holding to these. Instead, according to the Agile manifesto of 2001, the key areas of focus 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
That is, while there is value in the items on
the right, we value the items on the left more.
In APM, a key theme is that the requirements will be allowed to emerge as we move through the project. Doug DeCarlo describes the traditional method as, "Ready-Aim-Fire,” and the Agile approach as "Ready-Fire-Aim!” We are allowing for continual adjustments and changes to requirements as a move through the project.
Ken Schwaber, in his book, Agile Project Management, uses the analogy of planning a car trip to illustrate the APM approach. Perhaps we are planning a trip from Washington, DC to Burlington, Vermont. Do we want to plan the route out in detail before leaving Washington, DC? Probably not with today's GPS devices, and the ability to monitor traffic in a real-time way. Starting out, we may make some general plans for our route, but allow for adjustments and alterations in real-time during the trip.
Note: this article reflects the viewpoint of the author, Mark Tolbert, and does not necessarily represent the views of PMIWDC. If you disagree with or object to the views expressed here, please let us know