The war of words between some agile
advocates and waterfall traditionalists shows no signs of ceasing, but growing
numbers of project leaders and teams are choosing not to choose sides. Instead,
they recognize value in both approaches, and they apply their techniques based
on the needs and realities of each project.
There’s a war or words raging. On one side are ardent agilists, who advocate managing projects using methods such as Scrum and XP. On the other side are traditionalists, who prefer waterfall methods. Just look at the venom in these headlines and stinging excerpts from recent articles on project management and product development:
“The Agile Method and Other Fairy Tales”
“Rigid vs. Agile”
“Waterfall methods are notorious for leading
one to believe projects are on schedule when, in fact, they are not.”
“Agile proponents are the leaders of a
dysfunctional industry.”
What are these opposing approaches to managing projects? It’s a bit hard to pin down — and that’s part of the confusion — but here’s a broad distinction. “Traditional” methods are planning-driven — they place a high value on early and thorough planning before executing the plan. Agile methods emphasize flexibility and incrementalism over detailed planning through a series of short (typically 2-4 week) “plan-do” iterations rather than engaging in advance planning.
An example may help. Let’s say that you expect to take a month-long vacation in Hawaii. If you use a traditional planning-driven approach, months before the trip you’ll study guidebooks, research event listings, plan your daily itinerary, and procure advance tickets to key activities. When you arrive in Hawaii at the start of your vacation, everything is all laid out, including a pair of hard-to-get tickets to the Jimmy Buffet reunion concert that sold out months in advance.
Alternatively, you could manage this trip as an agile project using one-week iterations. Before leaving for the islands, you’ll make a high-level wish list of activities that sound interesting, but you won’t spend much time on detailed pre-planning. At the beginning of every week on Hawaii you’ll figure out what activities you will do that week based on your wish list, the weather forecast, and the people and places you discovered last week. This allows you to be flexible and explore your emerging interests, such as accepting a spontaneous invitation to attend an authentic family luau with a local resident that you met the first week.
Although this is an exaggerated example, it illustrates some of the pros and cons of each approach. The traditional approach, with its emphasis on advance planning, is efficient when you have relatively clear knowledge about the future course the project is likely to take, the risk or cost of having to redo things is low, or advance preparation confers important benefits such as managing long lead time orders. You plan once and then do (perhaps with minor modifications). This allows you take advantage of opportunities like attending that once-in-a-lifetime Jimmy Buffet concert under the palm trees.
In contrast, the agile approach is most powerful when you can’t clearly see the future of key elements of the project. Frequent short iterations of planning and then doing add flexibility and reduce risk. This flexibility means that you’d have a great time going to the local luau during your vacation, an event you never could have pre-planned because the opportunity didn’t come up until you met a local during the trip. Unfortunately you’d miss seeing the Jimmy Buffett concert because it was sold out months before you started any of your weekly iterations.
Which approach is best? It depends on the type of project you’re doing — the length of its planning horizon, the cost of rework, the value of flexibility for the project, and perhaps even the culture of the organization performing the project.
However, we don’t have to pick sides, either agile or traditional. Sometimes the most powerful solution is to combine elements from both approaches, choosing detailed planning for stable parts of the project and shallow, iterative planning for other parts that are likely to change. This is currently called a hybrid approach, but the idea goes back at least 30 years to project management author F.L. Harrison, who called it “Rolling Wave Planning.”)
A Plea for Peace
It’s clear that both agile and traditional approaches have valuable elements. Either can also be abused, causing a project to fail rather than helping it succeed.
Allow me get on my soapbox for a moment. Stop the caricatures and call a truce to this unnecessary war. Draw the best from both perspectives. The bottom line is that techniques from both approaches should be part of your practitioner toolkit, and you must develop the judgment and skill to be able to apply the best technique to a particular project situation.
I'm definitely in favor of using "a method" and adhering to a process that makes sense and provide the necessary foundation for project success. And I couldn't agree more that "soft skills" need to be combined with "hard skills" for a project to be successful.
It's a challenge to discuss "method" in the absence of a domain and context. In the Enterprise IT domain, there is an ITIL paradigm that spells out a framework for processes and adherence to those process. When Amy uses the word " slavish adherence" she's using a loaded word in the absence of a domain and context.
You'd better be doing " slavish adherence" if you're the SOX compliance officer at a publicly traded firm, or the DCAA compliance officer in the federal contracts office of a large construction company.
In other domains, or even other contexts in a specific domain the "rules" for what is allowable, what is acceptable, and what is desirable, vary widely.
So when Amy says, "Now I manage projects using the orientation I taught - which is 90% showing up to be present to the situation as it is and 10% applying the tools (rigid or not) appropriately. " Does "manage" mean project that deliver products to customers in the field, or manage projects that deliver services to constituents, or what exactly.
There is a huge variety of "methods" used to successfully manage a project. Some can have broad flexibility of exactly how the management processes are applied, some have very little flexibility is that process. If we were to visit our local PMI monthly meeting and randomly stand at the bar and ask "how to you succesfully manage your project," we'd get everyone from people like me subject to DFARS to methods I've heard Amy speak about "which is 90% showing up to be present to the situation as it is and 10% applying the tools (rigid or not) appropriately." In our domain it's very little about working on "showing up" that is the price of admission. It's about 100% compliance with the corporate and government processes and agency procurement process.
So in the end it's tough to pin down what are the core principles and practices for project success without first establishing the domain, context, and culture.
So again, it's difficult to assess the effectiveness of an experience outside the specific domain and context without more information. Now add to that thread Enterprise IT. ITIL, regulatory based - health care for example, retail, general commercial, hard goods, products - Boeing has different PM management processes than would Target on how they plan develop and deploy time keeping or procurement of raw goods using ERP.
To give you some sample to look at please look at this ad for Boeing, but this is representative of many of the programs we work. In this domain, "ruthless adherence to method" is a critical success factor. This is an extreme example and likely outside the experience of many here, but it is represenattive of a domain where "method" and "process" are critical.
In other domains, method and process may not be a critical factor. The discussion of "high method" versus "no method" is completely dependent on the domain. It can not stand alone. Alone the discussion of method has no actionable outcome or purpose
