Agile: The Great Debate

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Recent Posts

My 2018 Goals For All Project Managers

Project Methodology: Help or Hindrance?

Every Project Is a Change

In the Rearview Mirror: The Year in Project Management

A Guide to Perfect Planning

Categories: Agile

Over the last week or so, there seems to have been a flurry of activity in the blogosphere discussing Agile and waterfall software development, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and project management. This is an important debate.

A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies.

However, we can learn a lot with an open dialogue in both directions.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work.

With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.)

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

•    The need for a much lighter "touch" managing an Agile project
•    The need for a higher level of trust in managing Agile teams
•    The need for robust change management and configuration management to track the evolution of the Agile project
•    The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

•    The need to trust knowledge workers more than manual workers
•    Success measured by customer satisfaction rather than quantitative outputs
•    The need to keep the client involved

What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile.

More later.

Posted by Lynda Bourne on: April 08, 2009 12:24 PM | Permalink

Comments (57)

Page: 1 2 3 next>

Please login or join to subscribe to this item
Chris Monteagle
Personally I think keeping the client involved is critical on any project. You need to keep that communication loop flowing all the time - agile or waterfall. I appreciate that its harder to do on large scale projects, is that why large scale projects have a higher rate of failure? Personally the more I investigate Agile project management the more it makes good common sense to me.

Varun Poddar
I have been practicing PMI methods for a long time, and agile methods for the past couple years. Lately, I've been doing more research into the overlap and differences between both. For the record, I am not in favor of one approach over the other, but support a blending of ideas. I am quite surprised to read your stance that agile is not a project mgmt methodology. It is in fact more than that IMO - it is a frame of mind, an attitude shift and a more dynamic approach to project mgmt. Also using scrum does not automatically increase the likelihood that the effort is operational. We have used scrum successfully within a PMBOK framework for multiple projects. I do, however, agree that PMBOK and waterfall are not synonymous, and that PMBOK's approach is compatible with agile's iterative approach. The PMBOK approach helped us create a broader framework, an overall vision and a guide. Incorporating agile methods into certain aspects of it enhanced risk mgmt, change mgmt and client mgmt. IMO by incorporating agile methods into our primarily PMBOK based approach, we reduced our planning cycles, created greater team ownership, visibility and cross-functionality and last but not least, increased customer participation. All of this can probably be achieved with just PMBOK's approach as well, but in my various experiences, infusing PMBOK methods with agile thinking seemed to communicate the message better. Regards Varun Poddar - a blog, wiki (coming soon) and consultancy - dedicated to Project, Client Management

Alberto Dominguez, PMP
Lynda, you're right. I see this misconception every day, agile and PMI aren't incompatibles at all. Rolling wave planning is a good example of iterations. Most of the people believes than PMI BoK is a methodology, and it isn't, it is, a FRAMEWORK. However, Agile is not for everyone. One of the things about self-organized teams is the need of senior team members -seniors mean quality and maturity, and not age necessarily- Self-organization will increase or reduce the success rate depending on the team members and their skills not only as coders but as managers -even they are not project managers. I also read both articles: "Foolish Behavior" (PM Network, November 2008, page 25) and the feedback letter from Patrick Weaver "Not So Fast" (PM Network, March 2009, page 10), and I thing they both are a good example of how thin is the line that separates Coding Leaders from IT Project Managers

Carlos Augusto Freitas
Yes. I agree. The agile is not project management methodology; Agile is a steps for development systens with organization that focus in quality assurance. For example: We have a RUP, SCRUM and others. All this agile methodology's systens complement a IT Project Management.

Jason Beheler
This is indeed an interesting topic in our current economic environment where projects are expected to deliver more value, faster, without increasing costs. Have any of you applied agile methodologies to real-life projects? Specifically, what was different? What was the outcome?

Brendan Kelly
Project Management is only a small part of a corporation's Portfolio delivery process and can not work in isolation. I feel that this article is not really balanced and I would question how much experience the author has of running Agile projects in a large scale environment. The following comment shows a slight misconception about software release schedules work and are funded. "If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work." A professional team generally will work on the software products for an entire portfolio or programme and will assign architecture, development and configuration resources dynamically to the functional and non-functional delivery and testing of the products. ie x number of person hours per release to be allocated to the projects with the greatest benefits to be realised within the shortest time. This is where the role of the Product Owner and Scrum Master is paramount. They barter with the portfolio owner of the software domain for inclusion in the release schedule. The major release does not have to be monthly, even though you will have software products delivered monthly to testing , particularly if you have complex code merger activities with other projects in the portfolio's programme tranches. In execution an agile project has monthly funding gates, suits a corporate portfolio prioritisation methodology, and is more rigorous than Waterfall, particularly if it is test driven.

Ray Almonte
Agile is all about communications & delivering value as soon as possible. It requires more planning, not less. Each iteration is planned with continuous input & feedback from the customer in order to provide the most value as quickly as possible. The main difference is that continuous feedback could very well change the scope, & that in an agile world, this is not necessarily seen as a problem, but as an opportunity. The main objection is that it's harder to set a completion date. The project management processes are used both for each iteration & for the whole process. Planning, communications, change control, risk management, quality control & assurance & all the processes still need to be considered & applied when necessary.

Yves Roy
Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work. This affirmation is likely to be discussed because if you don't consider the SCRUM methodology as a project methodology to endeavor IT project development it's probably because you did not experiment enough SCRUM team situation. Personnaly I did put in place an Agile Methodology process within a development team using SCRUM approach for project we achieved and our achivement are not small (over 800 to 2000 work days) and we did merge the PMBOK guidance with the 2 others methodologies. Of course to do so you need experiment people at the top of the project but it is very productive to integrate the 3 methodologies as a whole and used your jugement to cleverly decided what is the best way to work according to the project. There is no more black and white approach to execute IT project development, nowadays there is many ways and when you want to use Agile process or methodology you have to keep in mind that using the different tools available mastered by the team leader and his direct relevant is still the best way to work properly with efficiency.

Werner Specht
I found the points you make about the PMBOK being applicable also to agile project managements extremely valuable. Applying the project management method outlined in PMBOK in the fashion you describe makes it indeed possible to use it on agile software development, at least in principle. I am not quite prepared yet to accept that there is full compatibility - when taking a PMP prep course last year I found a lot of areas where I wasn't sure how to integrate PMBOK and agile methods in a way that wouldn't seriously hamper the projects I do. Resolving those problems will certainly take a lot of thought and work. However, you have motivated at least me to give it a shot. Thank you very much for pushing me in this direction!

Mike Walls, PMP
You make an important point that agile software development is not automatically an agile project, or vice versa. The two concepts are orthogonal.

Raymond Dickinson
I agree that the Agile system, the waterfall method, and he "overlapping" waterfall methods are purely software development methodologies, and not project management methodologies. Software development managers, as well as software project managers, have confused the differences between the application of methodologies for many years until they have become mirror images of each other within the software development arena, due primarily because of some similarities between the two concepts. These similarities have led these same managers into a false sense of security that "one size fits all" applies to methodologies as well. This false sense of security has allowed them to do away with the harder, more painful (and additional effort) of developing a strategy to apply project management methodology to software development methodology in a fashion that reflects their true nature producing more accurate results (i.e. scheduling, tracking, cost analysis).

Peter Wright
I have worked in businesses using APM(BoK), Prince2, Agile, XP etc. I agree that Agile, XP, SCRUM are not project mangement methods and they are software / IT "development" methods. You have to put the various methods in context to understand this. At the top you will have business strategies (Business Plan, AOP) generally followed by business management and processes (e.g. CIMA, ISO), these then flow down into/or can run alongside, high level Portfolio Management (e.g. Business, IT, Project) flowing down to programme/program management (e.g. PMO, PPM) onto Project management (etc. Prince2, PMI, APM) and finally the activities and operational tasks to complete work (Agile, Scrum, Task planning etc, Six Sigma, Lean). For ease what I have explained above is a one size fits all model as I know Projects can flow straight from the strategy; I have used this to try to show that such methods as Agile are what the actual "workers/task completers" will have to utilise to deliver the task/work package for the PM/Project/business. They way to look at the work "they" undertake is if this were not part of a project would they use a different method? Normally the answer is no and a developer will use Agile whether it is a daily task or part of a project, therefore they do not fit into PM methods such as Prince2 but can be utilised to assist in delivering the project objectives (e.g. a tool). Prince2, APM, PMI are all documented in ways that allow/enable PM's to utilise them like an agile method if needed as you have highlighted in your 5th paragraph.

Kal Majumdar
I have used different methodologies in managing over hundred projects successfully, still PMBOK remains as the basic guidance book to me. I never found a conflict between what methodology I used to manage a specific project (yes, it depends on project) and how PMBOK helped me managing the project succefully. Agile methodology is no exception there. Agile has it's advantage over Waterfall for obvious reasons in our fast paced volatile today's market.

Gordon Masbaum
I work as a Prj Mgr (PMP) in our IT Division PMO and have run all types of projects including App Dev, Infrastructure, Networking, Microsystem and projects that combine all of these. We do have a debate going on now as our iSeries App Dev group has bought into Rational Unified Process (RUP) and demands that anyone running a project they sponsor fill the PM Role in RUP. Now App Dev has all sizes of projects and sometimes they need the help from Infrastructure, Microsystems, Networking areas that don't follow RUP. This has led to the debate that the RUP PM role is project management and should apply for any group. In my area one of our PM's mapped the PMBOK outputs (4th edition) to RUP artifacts and found around an 80% match. Most of the match came from the Requirements, Design, Develop, Test iterative cycle the RUP puts you through. What was missing is things I run into a lot as a PMO Project Manager is the work done before project starts (e.g., doing RFI, RFP for Vendor Selection), Developing Service Level Agreements and performance metrics and most importantly the coordinated integration of multiple platforms / systems including vendor hosted systems. In summary, the iterative, agile approach works with smaller teams that are working in same general area but doesn't work so well in cross functional type of projects.

I have been using Agile for more than 4 yrs now. The form of Agile varies a lot based on industry...which can at high level be equated to strategy. Agile used in R&D and high tech company like Facebook or similar core internet technology company will be completely different from Agile used in traditional companies like Bank, Insurance, Retail.....etc. In tech companies like Facebook, the development process starts with a very high level concept and the final product may look very different from original concept. Innovation is key there and time + budget can potentially take 2nd level interest depending on situation. Where as projects in traditional industry is driven by a more concrete business objectives and time + budget is at center stage of the project. In this case agile is more structured, almost like short burst of many small waterfall cycles. Planning is important here but also a good mix of innovation is required to make Agile project successful. I have used Agile in large scale project and it works excellent provided iteration cycles are planned properly. team involvement and buy-in is a must. Stakeholders (business and technology) need to know what is happening in project, change management process has to be followed well including a good traceability mechanism (tools helps a lot here). The project team has to be empowered a lot and a project manager need to take a leadership role..note not just managing project but lead to stimulate the team, drive the team to right direction and ensure the team/project stay within boundary defined for success of the project which includes all best practices of project management. At the end of the day the Agile development methodology and Project Management methodology should complement each other to make the project successful.

James Peckham
Scrum (not to be confused with 'agile', a very generic term) is not a methodology. (not software nor project management). It is a process control framework wrapper for product development. The processes and tools described in the PMBOK are a project management methodology. Scrum can be a wrapper to the practices and techniques used in the PMBOK and I guarantee you will find quickly which ones work and which ones become impediments when using scrum. Thank you, James Peckham CSP

Navneeth Nayagam
Agreed on the common misconceptions amongst the IT professionals in equating the Waterfall methodology with PMBOK and other models like CMMi. Most of these arguments stem from a basic lack of awareness of the PMBOK. Agile Development methodologies like Scrum do encapsulate Project Management practices including Planning, Monitoring and Controlling (through Daily Scrums), Reporting Progress (through Velocity and Burndown charts) and incorporating Lessons Learnt (through Retrospectives). The role of the Traditional Project Manager undergoes a radical change in Scrum since the team with the help of a Scrum Master delivers the project. However, PM practices are used extensively in Agile Methodologies.

Scott Freauf
Agile can describe an approach to the development of software (or any product for that matter). That approach can be incorporated into defining a project life cycle methodology, but it is not a project management methodology. I am in total agreement with the following assertion… …you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development. With this in mind, I believe that the recent addition of a process called “Collect Requirements” as a project management process within the PMBOK® Guide is inappropriate if the requirements being collected are “product” requirements (as opposed to “project” requirements). In many, if not all, development projects, the front end understanding of the desired output is very fuzzy. There may not be a clear understanding of the conditions or capabilities that must be met or possessed by the output (product) of the project that will satisfy a contract, standard, specification, or other formally imposed documents --- i.e., “product” requirements. When this is the case, the project life cycle methodology must include at a minimum a phase whose primary focus is the collection, validation, and documentation of the product requirements. In the case of an iterative Agile approach, these same requirements must be captured with each iteration. BTW, your assertion regarding the misconception that any new software development is automatically a project is spot on.

Kim Caruthers
I am using Agile for the first time, and I've been in project management roles for over 17 years. For the most part, all of my projects have included some software development requirements. So, I'm no novice in this area. Now that I've grown accustomed to the Agile process, I don't see how I could do without it when it comes to developing software. One of the key challenges I faced in the beginning was how to relate the hundreds of user stories (short descriptions of discrete requirements such as "user can select five color preferences") to my work plan in MS Project. I was appointed to the PM role well after the vendor's developers had started creating the user stories, so I had to move quickly to catch up. I found the best way to overcome this challenge was by working with the software development manager to help him understand what a "work package" was, and the importance of then mapping their user stories to our project work packages. Once we did this mapping, the rest was business as usual from a scope management perspective. The other challenge I faced was regarding scheduling and my ability to set realistic expectations. Our senior management team wants to know when the project will be complete; i.e. when longer-term milestones will be met. The vendor's software development team, in using Agile, tends to focus on more immediate priorities (10 or 20 day delivery cycles). Operationally, this would not be an issue. But from a project management perspective, it has been a challenge, and one which has not been so simple to address. The next time I'm involved in a project that includes software development, I will strongly recommend an Agile approach. Although I'm still learning how to take the best advantige of Agile, I believe it is far superior to the waterfall method.

I believe that Agile has strong definition of project management. Agile is more like project management of product development. I believe that all PM knowledge areas are adequately represented in any Agile framework (Scrum, RUP or others). Agile key difference is that considers the project manager as a facilitator and process advocate. The Agile project manager encourages change to happen. This is philosophy. PMBOK is so preaching that the project manager should influence the causes that lead to change. This controlled manner of handling changes tends to create tense in the relationship between the development team and customer. It is a major source for contention and disputes. I believe by encouraging change, Agile is mature conceptual work agreement between the customer and the project team. We are in dynamic business setups and we should admit the realities of doing business, especially in the current economy.

Page: 1 2 3 next>

Please Login/Register to leave a comment.


We are ready for any unforeseen event that may or may not occur.

- Dan Quayle