Voices on Project Management

> Back to Voices Home

Agile: The Great Debate

| | Comments (56) | TrackBacks (0)
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.


Bookmark and Share


The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: Agile: The Great Debate.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/197

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.


I think that PM can be enhanced with the APM methodology. We as human beings always need to be open for improvement.

It would be very advisable to find out and share the experiences in the application of APM across the world. See http://www.lithespeed.com/resources/2006AgileToolingSurveyResults.pdf

Our future is working in collaborative environments, where people do not need to be physically located in the same geographical location, as long as people are provided with all necessary tools for communicating and sharing information.

Languages and cultures, though, are the worst enemies!

Thank you for your response Vasco, however, I think maybe you misunderstand the message in my posts and adopt the extreme position that is disadvantaging Agile in the serious business market.

To your first point, there is no PMI vs Agile. PMI has a virtual community devoted to the development of agile within the overall framework of project, program and business management, there is certainly a diversity of views in the PMI community but this is healthy. You also seem to misunderstand the intent of the PMBOK® Guide, the PMBOK is a knowledge framework, not a methodology. How the knowledge in the PMBOK is applied to projects ranging from power station construction to small IT developments is a management decision, the PMBOK strongly advocates common sense flexibility in its use!

Certainly where we differ is in the degree of control needed around projects. Certainly some small 2- to 3- person projects to implement a minor change or upgrade can be managed without any serious documentation; the user knows what’s needed and the developers can create the outcome with minimal fuss.

However, the last Agile project I had involvement with involved a team of some 80 developers building a totally new capability for a major business, interactions with some 15 legacy systems, the need for a high level of security and the capability to provide audit trails that could be used in Courts of Law as evidence transactions had occurred. The primary users of the system would be the public. Designing and building this system involved extensive planning and very careful design of the architecture so each ‘sprint’ could build on earlier modules to develop the overall application.

Wandering off in the hope the $30 million investment might work at some time with some 10 to 15 independent teams doing their own thing was not an option (and frankly that would not be smart). There was no attempt to define the project in detail as per the older waterfall approach and flexibility was built in to the management of stakeholders and the design. However, defining the modules, the data flows, system configuration, etc. was crucial to ensuring the development work was undertaken as efficiently as possible. Configuration management was critical; a sprint delivered a module that caused a change in the data structure, the consequences of the change needed to be mapped back to all of the pre-existing work, particularly in the non IT components of the project, as well as forward into the next round of development.

The Agile Manifesto focuses on meeting the needs of stakeholders as efficiently as possible. At times this requires more rigorous (but appropriate) controls than others, some of my other posts have discussions on this and other related points.

Agile is a steps for development systems with organization that focus in quality assurance. I am quite surprised to read your stance that agile is not a project management methodology.

Sincerely speaking, I found your points of explanation on the PMBOK being applicable also to agile project management extremely valuable and useful. Applying the project management method outlined in the 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 undertake. And resolving those problems will certainly take a lot of thought and energy.

However, you have inspired at least a thoughtful person like me to give it a shot. Thank you very much for your inspiration that has directed me on this noble path!

I've written a response to this article from a point of view of an Agilist (someone with some experience in Agile).

In short. I think that PMI still has a lot to learn about Agile, and right now there are a lot of misunderstandings in the PMI community. That actually makes the debate poorer, not richer as intended.

Response here:

I think that Dave Wright hit the best point: first it should be defined exactly what are we actually talking about. After reading all posts I've recalled the tale "The Blind Men and the Elephant": based on different experiences, here we have a plethora of different views and (mis)understandings of Agile and other terms. But what Agile, PMI, etc. realy are; that is, what exactly are the main differences between these? That's the question where we should start from. Though we might enjoy in this discussion so far, I find it would be much more sensible and productive to rely on official definitions and an appropriate comparative ANALYSIS. The Agile Manifesto, for example, is of some help, but it's not enough. So I hope that the most competent members in this discussion could provide us with specifications of appropriate official standards -- if crystallized, agreed standards for all these terms already exist.

Basically, agile project management (APM) theory comprises a set of principles and values. Some practices and techniques have been presented by some authors from this movement, specially in the software development area. This is the first reason to expand the boundaries of the application of agile project management principles, and also, go further and investigate more carefully this approach in order to translate it into methods, tools and practices that can be used in other project types and environments, specially those that have been struggling with uncertainties, high demand for innovationa, pace, and novelty, where some traditional project management practices must be adapted and customized to fulfill project management requirements. Throuth a literature review it's possible to identify some evidences about the lack of empirical studies of agile approach implementation in other areas than software development.
So, we need to keep studying, investigating, researching and testing agile project management principles in order to have a clear vision of its potential and application and how proper adapt our project management methodologies to achieve better results.

Edivandro C. Conforto
Project Management & Product Development Management
Researcher and Consultant

It is interesting that although the Agile principles from the Manifesto are understood, Agile, like any other new direction (and it's not that new), will mean different things to different people. Will/has Agile take(n) on its own life and direction? I speak to people and discover that Agile has a different meaning each time.

Would a published standard, incorporating the key principals from the Manifesto into a framework help for say the guidance of a project manager, trying to apply PMBOK principals to every project and uphold his/her PMP professional responsibility?

If there is a standard, should we certify against that standard?

It would seem logical perhaps for bodies such as the Agile Alliance, Agile Academy and PMI to discuss and agree an approach to this industry-wide clarification. Because all the blogging in the world, although interesting, isn't going to give us a consistent Agile approach.

Dave Wright PMP
Agile and PMP Consultant

This long list of commentary is interesting, even intriguing. The agile community broadly asserts that agile is not a methodology. Agile is fundamentally a development construct whose quintessence is the Agile Manifesto. The Manifesto doesn't describe specific practices - rather it articulates guiding values and priniples - but there are various agile frameworks (e.g. Scrum and XP) that do describe (but not prescribe) practices. Varying from the practices can limit the benefits, but people do so for a variety of reasons (we in Scrum refer to this as "Scrum, but.") It is the notion that these approaches are simple work process frameworks that causes us in the agile community to shy away from the term "methodology," though quibbling over such overt semantics is wasteful.

PMI CEO Greg Balestrero accepted an invitation to speak at the Orlando Scrum Gathering in March and was accompanied by PMI COO Mark Langley. Lots of discussion ensued about agile, PMI, PMP, PMBoK, Scrum, etc. Greg gave a keynote address at one Gathering lunch. As Jesse Fewell posted on his site (jessefewell.com), Greg was positive about his visit: “We’re here because we respect the Scrum Alliance”…”the mission here is collaboration, we can’t afford barriers”…”It’s all about results quicker, faster, with high quality”. Balestrero blogged about his visit and thoughts as well: blogs.pmi.org/blog/a_chief_executives_perspective_on_project_management/2009/03/on-the-threshold-of-agility.html

Even more refreshing, imho, was the later Balestrero blog post that Lynda Bourne referenced in her April 21 comment where Greg wrote about his interaction with one of the Scrum Alliance trainers, Tobias Mayer, at the event: "He [Mayer] said something that really rang a bell. He said that though Scrum addressed software development and project management, it was more about a value-based work framework, driving such values as respect for everyone's opinion and contribution to the project team, consistent and shared vigilance to risk, and more. He felt that it was developed not only to develop software faster and more effectively, but to provide a new culture of work, and new leadership values and principles."

That is the pith of agile and Scrum: instilling a sense that work can be more satisfying for the team and the customer can be more satisfied with the results. Avoiding and overcoming what seems to have become somewhat typical hubris of oppossing argument and opinion about competition or antipathy between agile and PMBoK-based project management is the key to moving the dialogue along healthfully.

What we most have to combat in agile is misinformation and uninformed and often ignorant "noise' - mostly assertions of what agile is not. One commentator wrote "Agile isn't for everyone." Is waterfall for everyone? How do you know who it is for? We have to rely on people to do adequate investigation and research about it, learn it and then try it with an eye towards doing work better. It's seemingly prudent to think of applying agile in the context of continuous improvement.

Tom Mellor
Member - Scrum Alliance Board of Directors

I have been working on Agile model for the last two years. My personal experience shows me that agile and PMBOK go togther. Great planning, attention to detail, clarity of thought, good monitoring and tracking, experienced team members help make agile work. Client communication and involvement gain paramount importance. If these are not in place, agile can unravel into chaos with Change requests becoming the order of the day. The project can turn into a sweatshop every fast with people working all weekends to make the 2-week deliverables happen. Another problem which affects the project is that some clients have heard that "agile" delivers fast results and want it implemented. What surprises them is the amount of time and effort they themselves will have to put in to make it all work. If they are unable to grasp this, they will find that the 2-week deliverables are not as per what they would like to have. As iterations increase to fix the earlier user stories, the project's budget gets affected.
Agile requires some level of maturity and experience among all the parties involved and the project manager should be a leader rather than a just a manager to keep everything running smoothly.

It is obvious that many don't understand Agile, nor have you seen it properly implemented. I think part of the issue is that it is as much a mindset as a framework, so many people end up trying Agile without ever really doing Agile ... Deep down, PMI and Agile come from very similar places, it's the implementation that usually is different (and that’s more the implementer than the framework). Now I’ll admit that I’m not a PMI guy, although I am familiar with it and have done it. I just prefer Agile, and its mindset (the whole is more then the sum of the parts). To me it’s like an 80’s style manager (win-lose) compared to a modern day manager (win-win). Both get the job done, both can be good, I just think this one better.

I've used Scrum on software projects, and just recently wrapped up an integration project for engineering from a company acquisition (data, process and procedures, i.e. no software development of any kind, and it worked great, although modified).

As for budgets and schedules, and discipline, it has it all, but Agile usually makes it all more transparent. Not only can I give you a daily status, but with the high level of interaction and communication (with things like daily standups, and short cycles) I'm essentially forced to. The stakeholders, and the team know what the issues and the successes are, which essentially stops the surprises (which every project has) from becoming a big deal.

Since projects don’t always operate in the physical world (building houses, factories and pipe), we often have a lot of change as we don't know what you don't know (and neither does the stakeholder). This is important to understand and accept.

We have budgets, we just acknowledge upfront that they are probably not as accurate as we'd like, but the only we will know it by doing rather than thinking. That said, I’m usually within 10%, and usually under.

We don’t make decisions / solutions upfront. You make decisions when you need to make decisions, and not before. Not only is this how you adapt to change, but decisions are made in the correct context with the best / most information on hand.

Iterations and waterfall are pretty similar. We go through essentially the same steps, just in much smaller loops which makes everything more transparent. It surfaces issues quicker, your feedback cycle is much smaller which means current issues or misunderstanding will surface in days or weeks instead of months or years.

We have time lines. A project has a start and an end, and delivery cycles, but we also force ourselves to have a bunch of hard deadlines in between so that issues become known quicker.

We have reporting and documentation, and will do as much as a company requires (we just try to keep it lite and flexible).

We work on the most important / highest value stuff first. “Done” can be determined by time, money, or value of remaining work, but it’s an open discussion throughout the entire life of the project. Because a stakeholder doesn’t usually understand what they really need until they can see it and play with it, there is usually a bunch of stuff on the list that never needs to be done in the first place, and a bunch of stuff that becomes important that was not originally required.

I’ve never met a stakeholder that doesn’t love a burn-down chart once they understand it.

Agile does have implementations with frameworks and discipline, but it’s also a mindset (new school versus old school). It works as most of my projects run a little ahead of schedule and about 10% below cost but most importantly they have happy customers that got what they really needed, thanks to communication, collaboration.

Wow what an amazing response. This is obviously a discussion that is starting to create a difference, even PMI’s President & CEO is engaged (see: http://blogs.pmi.org/blog/a_chief_executives_perspective_on_project_management/2009/03/a-conversation-on-agile-long-o.html).

First to clear a couple of points:
A project management methodology should be capable of managing most types of projects. Product development methodologies structure the way a product is created. Agile, Waterfall and Scrum are product development methodologies. Where the two interconnect is the way the product is created influences the project team structure, the way risk and quality are managed and the way the project is planned, executed and controlled. If an engineering project decides to use off site fabrication, the location of workers, the sequence of work and just about everything else is different to a similar project using on site fabrication. Agile and Waterfall are the same—whichever is chosen the way the project’s work is accomplished will be completely different. The project management methodology needs to adapt to effectively manage the work environment. My next post will take a close look at this challenge.

The flip side of this is Agile is based on a distinct mindset. The focus is on collaboration, trust, flexibility and delivering value. Can this philosophy be of value in traditional project environments? My feeling is definitely yes! But there is a need for a major culture shift in management think. Concepts, such as the one raised by Oliver about requiring a fully defined plan before committing budget, have to go. The replacement is a collaborative approach focused on maximizing value within constraints of time and budget. I will be taking a look at this topic in a few weeks time.

Lastly, not everything is a project. Projects are temporary! Once the project is delivered the team members are reassigned to their next challenge. Operational work still has to be planned and managed within budget constraints but the focus is different. Operational managers focus on making the most efficient use of a stable team and continuous improvement. Scrum and Agile software development techniques can work exceptionally well in either environment (unlike Waterfall). There’s nothing wrong with maintaining and enhancing software using an operational management approach with stable teams and prioritized work lists. Other maintenance managers have been doing this for years in plant and facility maintenance space. It’s just not a project by any accepted definition.

Visit Voices soon, my next post will be up in a few days …

I think agile is more then just managing a project. It also push team to be more efficient. It help developing engineering practice like TDD, DDD, BDD, ... and more.

Also i think waterfall project can adapt to agile, because my previous job was mainly following waterfall to manage the projet but the software development was using scrum.

One main aspect of agile is also to inspect and adapt. So you try something if it doesn't work change it and learn from your mistake...

Each Software Release, regardless of which methodology is used (agile or waterfall), requires project management processes. The key is the application of the processes considering:
a) the corporate culture
b) the maturity of the company in terms of project management maturity model
c) the type of software methodology in use

As long the Project Manager is cognisant of these and is able to apply the processes as required and makes sense for the organization, then there really is no issue. The challenge becomes the normal ones such as managing resources, schedules, costs etc.

A few comments:

1. Not all ITC projects involve Software development!

2. The Agile concept is not scaleable to large, complex change programs

3. Agile relates to requirements-design-build loops and pre-supposes high end-user, stakeholder availability (with trust being axiomatic)

4. Agree that some concepts are generic such as; high levels of trust, robust change and configuration management

5. Ultimately, PMgmt is about governance of finite change as opposed to governance of continuous change (which would be my definition of Operations management).

Good article. As a Certified ScrumMaster myself, I don't see any reason why a smart PMP with a flexible disposition should have any trouble succeeding with Agile software development.

I'm not sure, however, why the article states that Scrum projects are more likely to be operational than project work. In my view, Scrum applies perfectly to project work.

When you use SCRUM you have the sprint planning meeting with the product owner and when you finish the sprint you have the Sprint Review with Lessons Learned. SCRUM is one of the Methodolies used for Agile Development.
If we think that we have the business requisites in a high level and we plan a project to have for example, 6 sprints, we can use the PMBOK Metodology to manage the whole project.
The main problem is that as we are planning the details in each sprint how can we use for example an S Curve for the whole project?

Can I achieve investement decision making discipline with Agile?

One of the key challenges I face trying to use Agile Methodologies in a large corporate is balancing Agile, with the waterfall approach to investement decisions and project portfolio management. Funds are released as the project moves through the lifecycle, only once the project i) requirements are well documented and understood, ii) with a design, iii) strong business case, iv) project plans & costs are at a high level of certainty, are the final funds for the project released. I would welcome any thoughts / experience people have had trying to square this circle.

Good post! This debate is very clearly an important one, if not the most important debate in the IT PM world right now. An open dialogue is indeed key to have a constructive debate. Many conceptions need to be revisited. I would suggest looking at the distinction between projects and operations. Clearly, operations are not supposed to turn organizations upside down, "reboot" projects and boost morale; but this has been said of some Agile migrations... Maybe organization management doesn't really care if the teams are stable or not, they just want their projects to be temporary in the sense that they want their products completed at some point in time, and not linger forever. Maybe temporary teams are just a side effect, a not a desirable one. From the perspective of the organization, if it has invested time and resources to train and form teams during a project, it makes sense to try and reuse those teams for other, similar, projects.

Hi Lynda...I've been practicing the PMBOK approach for the past decade, and agile methods for project management over the past three years or so.

While I agree with you that PMBOK and waterfall are not synonymous, I do feel that agile is a project management methodology. It presents a powerful mindset which when used properly can help better manage risks, changes and customers. I do not subscribe to any one school of thought, but promote a blend of ideas from both.

In our experiences, we have successfully used agile methods on software development projects (not just operational activities) within a broader PMBOK framework and vision. There is more in common between the two than meets the eye, and it is worthy of further exploration.

Our organization has implemented the Scrum methdology. Ideally, a Scrum team is stable, retaining members from sprint to sprint so that it can maintain a certain velocity. And, the prioritized list of requirements on the product backlog is constantly evaluated and reprioritized based on customer and business need. For these reasons, I disagree with your statement that "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." We are very much working on projects.

Our Blogger setup does not support TrackBack. We have weighed in on this article at theaspeblog.blogspot.com

Some Agreement. Some Disagreement.

I think that "Agile" is neither a project management methodology nor a software development methodology.

"Agile" is simply a descriptive word that encompasses so many specific approaches to project management, software development, engineering, release planning, management philosophy, manufacturing techniques, and many other things. We hope that anything that calls itself "Agile" with a capital A, relates in spirit to the Agile Manifesto which is admittedly software-centric. But I'm very worried about the increasing prevalence of folks who think they're doing "Agile" but aren't really making strides towards success.

The danger in thinking that any generalized framework without clear definitions is good for running software projects or any other kind of project is that by using a very general descriptor, we can convince ourselves we're practicing quality habits while our practices (whether meaninglessly regimented or not disciplined at all) yield no results.

It's important regardless of what framework a team chooses (Waterfall, Scrum, XP, Crystal, Lean, etc.), they commit to really giving it a go for a reasonable period of time to evaluate whether it yields results after which they can add or subtract practices based on real-world experience doing it.

Ultimately the objective is results, regardless of what framework is used. So I vote that teams pick whatever method seems to be a best-fit for their project and culture and commit to trying it completely. You can always change it if the results don't materialize!

I sounds good for debates between waterfall and Agile projects.

I think that we must look for the benefits of SCRUM and PMBOK brings to us.

Lynda makes some good points, especially about the PMBOK® Guide as a "big tent" that supports many PM tools/methods, including Agile.

However, readers may be interested to know that Agile Project Management is NOT just for software development. With its IT successes well documented, Agile PM is now becoming a desired cross-industry approach to delivering project results. For example, the emerging PMI Agile virtual community is using an Agile PM framework to build out an all-volunteer organization. We've delivered business plans, chartered functional teams, and networking events in a way that embodies the PMBOK® Guide ethic of "progressive elaboration"

To see other examples of non-IT Agile Project Management, join the information dicussion here:

To follow the formation of the PMI Agile virtual community, watch the collaboration happen here:

Agile methods certainly offer improved development scenarios in cases where stakeholder (client, end user, et al) involvement makes sense. Their inclusion on Scrum teams makes great sense in terms of buy-in and ensuring the customers’ requirements are met. Unfortunately, software developers occasionally reinforce the following stereotype… Application developers go out for drinks at their favorite geek bar and brag to each other about how they wrote “neat code.” But they don’t care whether or not it helped the end user.” Scrum can perhaps mitigate such disconnects.

Even so, Scrum might not be as appropriate for projects delivering upgrades to an existing system whose architecture and functionalities are well suited to current scenarios and accepted by user communities. If there is a trend to embrace Agile methods in place of more appropriate choices, it could be a function of the phenomenon described by the young, inexperienced carpenter who just got a brand new hammer… For a little while, everything looks like a nail.

I believe our Aussie friend Chris Monteagle was absolutely spot on in pointing out how crucial stakeholder involvement is to any project. In fact I’m perplexed at how little emphasis the PMBOK places on this. Robust and rigorous analysis of all groups of project stakeholders and appropriate inclusion of certain ones as consultants and participants is a key contributor to success, whether the project involves software development or any other deliverable. I suspect this could be part of the reason Agile methods seem resonant.

Although Waterfall and Agile are generally seen as software development methodologies, I disagree with the implication that nothing under the "Agile" umbrella can be considered a project management methodology. Scrum falls in this category, and the Scrum framework can indeed be used to help manage non-software projects where a high degree of client involvement is possible.

Traditional Project Management practices are not always entirely compatible with Scrum. The biggest conflict I see is that requirements for a Scrum project are emergent, and the framework allows for things to change. Change is expected. These differences are built-in to allow delivery of the highest business value in the shortest time.

My thought is that at a very high level, established project management practices are still necessary. High-level scope management may be possible, depending on the project. However, a detailed WBS at the outset is not possible if you are truly using Scrum, and trying to manage scope and time at a detailed level does not allow the full benefit of Scrum.

I have been involved with both the traditional waterfall project life cycle and agile “Scrum” S/W development.

What I find of interest with Scrum is you run the “project” in very short iterations, from 2 weeks to a month – within that time you deliver something that is functional to the end user each iteration. And you can have 5, 10, 15, 20 iterations. The advantages are that you are constantly prioritizing and reshuffling your requirements (if you need to) and you don’t spend the time and effort building useless requirements that drop to the bottom of the priority list.

My only concern is that you have little to no control over the scope of the project. We can do estimating but I find it is very “loose” and never a concrete number. As the rqmt’s change so does the scope of the project – it is very fluid.

Agile is not for everyone – that is for sure and yes it does fall somewhere between a project and operations as noted above. You can lose control of the scope of the project very quickly. The trade off is the incredible flexibility agile development give you.

I would be interested in hear other people experiences


Another common misperception among project managers is that classifying their project as Agile will somehow exempt them from following good project management practices and project methodology. I find the opposite to be true. Certainly the volume of formal documentation may decrease, but the need for solid planning, communication, and trust among team members increases.

I have not run an Agile project and had a question about a typical Agile project. It seems to me that there would be a lot of up front work to plan all the work. That is story cards etc. Does creating and breaking down all the work into story cards and then fitting them into iterations etc, take more time than waterfall? Seems like one would need to be more detailed for Agile than for the traditional methods. I may be way off here, so I would appreacite any insights anyone would like to provide! Thanks!

I have been studying up on Agile, and I am not convinced that it is applicable in every project like some seem to think. To me, it seems to equate to "We don't need no stinkin' project management."

True Agile development does not include processes for budget or comprehensive risk management. In addition, large scale projects should require solid change management. Agile tends to "miss" those pieces.

I think that certain shops should use Agile. Some industries have to move quickly to keep up with market conditions. In those cases, Agile seems to fit best.

For large-scale projects, however, I would not recommend Agile for the software development methodology. Larger projects carry large budgets and demand more oversight and controls than Agile allows.

There are similarities and some new takeaways.

It's important to remember, keep the client/company in mind, culture and all. 'Right sizing' is key.

It's about transparency of information so that we have value add to the strategies of a company, no matter what we use - be it agile, waterfall, sdlc or traditional pmbok. Start with the end in mind.

I for one have been using this before I ever heard it was called agile, it makes sense even in the most simplified 'KISS' approach, keep it simple s--!. Inclusion and leveraging of people's talent, client involvement, quick returns/successes to show progress in the right direction (& make the right adjustments as the situation demands), transparency turns into accountability and making the right decisions at the right time. It takes a team to succeed, it takes a team to fail - everyone has a stake in the results. These are good and effective things to adopt, it makes sense.

I agree that Agile is not a Project Management methodology. I believe it is a product development methodology and is very effective for new product developments for product development firms. They probably don't have a customer paying them to develop the product. Most paying customers won't be very receptive to this approach for developing a brand new product (never done before). If we go outside these constraints (new product/willing customer) then I believe it is viewed as a silver bullet for situations where it probably won't work. The customer must be willing accept an unknown final cost and completion date for this product development methodology to work. A project has a defined start and end date. Does the agile approach comply with this definition? I don't think so.

The tenants of agile are attractive for developers and are laudable principles for any project;

ie: People over processes, working software over documentation, collaboration over contracts, rapid response over planning.

However in a world where financial responsibility is becoming more important these should not be your only guiding principles.

If i failed to deliver what was required and we still needed another $100K because we built our software on trial versions that the vendor verbally assured us would be OK, i would hate to tell my sponsor that it was because we were being "agile".

Well, while doing this debate, there is an important detail being overlooked - The scope of application of the methodologies. While there is no rule as such, Agile is for knowledge workers and is mostly in software development field. PMBOK's approach, on the other hand, is more general and applies to a wide spectrum of projects. In most of the scenarios outside the software world, perhaps, agile won't work! I think, Agile still needs a significant part of processes described in PMBOK to manage the project as a whole.

Besides, in a general scope of application, building teams that are more trustworthy, is an arduous task and that is almost never the thing what the customer pays for. If the malignancy starts creeping in, its tough to control especially the large to very large projects.

May be, I am more tailored towards thinking in PMBOK's way... does anyone think like this or otherwise?

"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 is too harsh, but conceptually true. PMBOK presents levels of 'projectized organizations'. Fact is that professionals apply PMBOK concepts for stable teams.

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.

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.

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.

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.

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

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.

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 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.

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.

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).

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

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!

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.

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.

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.

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?

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.

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

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.

Varun Poddar

PoddarCo.com - a blog, wiki (coming soon) and consultancy - dedicated to Project, Client Management

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.

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll