PMI vs. Agile, what is different, and why should we care
The PMI people don't seem to stop trying to "guess" what Agile is. Guessing is the right term, because anyone with more than a few hours experience in Agile software development can see their cluelessness from afar!
Take this article by Lynda Bourne DMP, PMP (no, I'm not making those TLA's up, she uses them). She says that Agile is different from waterfall because:
Someone that says that in Agile project management you need "robust change management and configuration management" probably does not even understand what those are, let alone Agile. Hear me out: Change Management is not needed in Agile, Agile *IS* change management. Take Scrum for example, the whole idea with Scrum is to provide a framework for accepting and managing changes. Scrum *IS* change management. To say that Agile project management "needs" strong change management is to miss one of the most elementary points of Agile Software Development.
Then comes the killer: we Agile project managers (supposedly) need to focus on "developing the correct strategy and architecture at the beginning of the Agile project", missing this - Lynda writes - will lead to failure. Only one word: WTF? C'mon Lynda, that is probably the largest mis-conception of Agile Project Management that I've seen in my (admittedly) short life!
There are thousands of posts about why Agile people focus on "growing" architectures rather than "getting them right up-front" (aka BDUF). Please read up, just google for Agile Architecture and you will find many articles that explain how in Agile we look at Architecture development (here's an example link).
There seems to be a lot of discussion happening in the PMI circles about Agile, but PMI people need to understand that the practices they've developed for building, acquiring companies, etc. don't all apply to software. PMI people should first learn about software and then Agile. Trying to bypass software and going straight for an Agile take-over will only get us (the software industry) another 10-years back in time and lose so much of the evolution we gained with the Agile movement.
at
10:09
Take this article by Lynda Bourne DMP, PMP (no, I'm not making those TLA's up, she uses them). She says that Agile is different from waterfall because:
- 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
Someone that says that in Agile project management you need "robust change management and configuration management" probably does not even understand what those are, let alone Agile. Hear me out: Change Management is not needed in Agile, Agile *IS* change management. Take Scrum for example, the whole idea with Scrum is to provide a framework for accepting and managing changes. Scrum *IS* change management. To say that Agile project management "needs" strong change management is to miss one of the most elementary points of Agile Software Development.
Then comes the killer: we Agile project managers (supposedly) need to focus on "developing the correct strategy and architecture at the beginning of the Agile project", missing this - Lynda writes - will lead to failure. Only one word: WTF? C'mon Lynda, that is probably the largest mis-conception of Agile Project Management that I've seen in my (admittedly) short life!
There are thousands of posts about why Agile people focus on "growing" architectures rather than "getting them right up-front" (aka BDUF). Please read up, just google for Agile Architecture and you will find many articles that explain how in Agile we look at Architecture development (here's an example link).
There seems to be a lot of discussion happening in the PMI circles about Agile, but PMI people need to understand that the practices they've developed for building, acquiring companies, etc. don't all apply to software. PMI people should first learn about software and then Agile. Trying to bypass software and going straight for an Agile take-over will only get us (the software industry) another 10-years back in time and lose so much of the evolution we gained with the Agile movement.
Labels: agile, design, pmi, project, project management, projectmanagement, scrum
RSS link
35 Comments:
Actually, I do think that you need robust change management and configuration management. I would like to see someone trying Agile without version control or build system. After reading Wikipedia articles on change management and configuration management, I would also add bug tracker and test automation. Reading those articles I thought:"Yes, that's one way to develop software, but wouldn't it be simpler to just do the first five items in The Joel Test?"
By
Unknown, at August 10, 2009 1:38 PM
@jautero
You are talking about code-level change management. PMI is about project management, not code-change, but requirements change.
Requirements change is what is Agile about, not an extra process...
By
Unknown, at August 10, 2009 2:29 PM
Seems to me like Lynda Bourne came across a typical "my first agile project" ...uhm... project. That's one of those where BDUF dies for little-design-up-front and everyone is happy that it got cheaper and faster.
And then someone decided that it is even cheaper not to add design improvements during the process. And, bang, you're dead.
From there on you can come to one of two conclusions: Either trust the developers more (agile) or again go for BDUF.
You can do really nice and interesting mistakes when going agile. Agile is one of those "simple, but not easy" things.
Other ideas?
Thanks to @mfeathers to twittering this.
By
Tobias Prinz, at August 10, 2009 3:19 PM
@Tobias
You are absolutely right when you say that Agile is "simple but not easy".
That's why I laugh when I see companies with Agile adoption projects of a few months and think that's it. Wait until they hear the loud bang in engineering...
By
Unknown, at August 10, 2009 3:33 PM
First let me say "hello". You made a very good point: "agile is changemanagment". Additionally I see a fundamental difference about the view on people and teams. Agile is about "trust in people". Classical pm is often about "how to control people".
By
Eberhard, at August 10, 2009 5:15 PM
I just read the article, and I think I that what she wrote is not that far off from what you are suggesting. She's not that far off on Agile, it's just that her suggestion is that it is not a project management approach is based on the fact that she assumes the PMBOK is all encompassing, and that project management approaches that leave out things aren't project management approaches.
I think the most interesting comment was where she said that it was more like operations than like a temporary project. I think this is getting to the point a little bit. Depending on what sort of software is being built, I tend to think of agile as being more similar to operations once you get the first version deployed. In new product development, it is a lot more like research oriented processes, such as drug discovery.
The commonality between these things- and the place where software development emphasizes the weakness of PMBOK- is that the duration and the definition of tasks has a very high uncertainty. Agile is about accepting that uncertainty, to some degree. As others have pointed out, this is a problem when you have a manager or customer that wants to apply deadline pressure to everyone.
By
Matt McKnight, at August 10, 2009 7:17 PM
Vasco,
Nice blog. I like what you write and appreciate that you have a strong experienced point of view. I don't agree with your point of view on this post. I started to write a response but it became big and broader so I turned it into a blog post on my site. I don't typically do that but please check it out PMI Agile, Debate or Learning Opportunity at http://www.dennisstevens.com/2009/08/10/pmi-agile-debate-or-learning-opportunity/
By
Dennis Stevens, at August 10, 2009 8:29 PM
Vasco,
I agree with some of what you said here but I wish you would have not generalized Lynda's position to be that of the PMI or the Agile/PMI Community of Practice. The PMI crowd is as diverse in perspective as the agile crowd.
The leadership of the Agile/PMI CoP is full of very senior agile practitioners, very well respected in the community (Michele Sliger, Sanjiv Augustine) who really understand this domain.
There are things that the agile community can learn from PMI and things that PMI can learn from the agile community.
Unless you are on the inside... trying to bridge this gap... be careful how you characterize the position of a large and thoughtful community of active agile practitioners.
Mike
By
Mike Cottmeyer, at August 10, 2009 9:28 PM
@Eberhard
Indeed, there's a fundamental philosophical difference between agile and "other" approaches (PMI's being one).
Agile was created by practitioners of the software craft, not project managers. That in itself builds/enlarges the differences.
We still have a lot to learn from the project management community (myself I did the IPMA certification some time ago), but the project management community also need to understand that their knowledge does not apply directly to the context that is software, that's one of the major advances from the Agile movement!
By
Unknown, at August 10, 2009 10:43 PM
@Matt
The point you make about software development being closer to operations than project is an important one (even if it does not apply to *all* software endeavours).
That in itself highlights the problem of trying to apply project management as a "template" to software development.
I worked for many years in a company that did that, and even if it did improve the "control" on the work being done (that was an advantage) it also destroyed the flexibility that was inherent the previous approach (that was the down-side which happened to be business critical).
By
Unknown, at August 10, 2009 10:46 PM
@Mike
I appreciate your concern. Not all Agilists are alike just as not all PMI people are alike.
There is however a core practice and set of beliefs that inform both of these groups and it is vital that we discuss those.
This BTW also highlights why PMI people will never "embrace" agile, because it would mean renouncing some of their core practices and belief systems.
That said, I believe that both communities have a lot to learn from each other and should/must continue the debate. Care to take the next step? ;)
By
Unknown, at August 10, 2009 10:48 PM
I would like us to expand and discuss the original dilemma Ken Schwaber run into. Software development is not a predictable process. Building the 10th home based on the same blue prints is.
Software development, empirical process, needs another kind of control, continuous feedback to be managed. The predictable process needs a plan and control to stick to the plan and maybe adjust it a little bit when needed. These are very different domains. Using the wrong control method for the wrong problem results in problems.
Somehow at the front of the religious wars people tend to forget this basic difference which Ken discovered. It is very important.
Also, I have seen hardware development projects. They are also empirical, not predictable. I claim it is not only software development that needs agile. It is development in general. When you are doing something for the first time, look into empirical process control methods. At its best, agile software development should be that.
By
Jukka Talvio, at August 10, 2009 11:21 PM
@Jukka
Great point! I knew I could count on you! ;)
Starting tomorrow I'll publish a series of posts about some of the key differences between Agile and PMI-style project management.
We need the dialogue before it's too late!
By
Unknown, at August 10, 2009 11:36 PM
Vasco,
I look forward to providing feedback on your comments. Check out some of the existing posts that compare and contrast Agile with PMBoK. Mike Cottmeyer over at http://www.leadingagile.com has several posts on this.
By
Dennis Stevens, at August 10, 2009 11:41 PM
Hmm, I guess I understand what Lynda meant. If you just stick to the agile YAGNI (you aint gonna need it) principle and just "evolve and grow" the architecture, it might become difficult to react to changes that you might have been predictable, if you would have thought about your business goals a little longer upfront. I know it, because I made the same mistake with one of the systems I built.
So, nowadays, I think much longer about the business goals and their possible impact on system architecture before starting a development project.
By
Erich Meier, at August 11, 2009 12:38 AM
@Erich
You are right that sometimes *even* agile projects go down the wrong path. There's no process that would immunize us against missing important pieces of the puzzle.
I'm not disputing that you can succeed with *any* process. My points are related to the fact that the PMI community is adopting Agile in a hurry, but they are not starting to study and listen to the Agile community, many of whom actually were/are part of the PMI community.
Also, Agile people who do not have the benefit of being part of the PMI community need to understand the fundamental differences in approach between the PMI approach and Agile approaches. These differences I'll try to make clear a series of posts that I'll be publishing here.
By
Unknown, at August 11, 2009 7:26 AM
There is nothing at odds in the "core" principles or best practices espoused by PMI in PMBOK and those found in the Agile Philosophy or the mainstream of Agile practitioners. There is inherently no "philosophical" difference at all; quite the opposite, in fact.
As has been noted here previously, there is a great need to understand and differentiate between the opinions of a particular practitioner and those of a certifying authority... and that blade cuts on both sides.
"Command and control" is not a PMI philosophy, it is an organizational (e.g. business) philosophy, approach, or culture. Agilists are spinning their wheels attacking PMI on this basis... it is erroneous; a battle without substance among unwilling participants who are more likely allies than antagonists.
By
Smiling Coyote, at August 11, 2009 2:31 PM
Vasco, you seem to completely misunderstand the message in Lynda’s 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.
There are differences in the degree of control needed around projects. Certainly some small 2 to 3 person projects for low risk change lasting can be managed without any serious documentation; the user knows what’s needed and the developers can create the outcome with minimal fuss.
The last Agile project Lynda and 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 would have been stupid). 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; when 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 and forward into the next round of development.
The Agile Manifesto is not an invitation to anarchy; it focuses on meeting the needs of stakeholders as efficiently as possible. At time this requires more rigorous (but appropriate) controls than others. There is a world of difference between blind faith and pragmatic trust.
By
Pat Weaver, at August 12, 2009 10:18 AM
@Woody
I would have to disagree with you. The focus on "best practices" that you mention is already a significant difference.
In Agile project management we try to define high-level frameworks and allow for the actual actors in the project to figure out the practices that suit their context. Agile is not prescriptive in nature, and I believe that anyone that has read the PMBOK could not argue the same about that document.
However, I agree with you that PMI is not "command and control" focused. It is however the reality that PMI-certified project managers are, in many instances, "command and control". And yes, some Agile project managers are too, but Agile provides a framework to balance those tendencies, PMBOK does not.
By
Unknown, at August 12, 2009 11:51 AM
@Pat
You make too many points for me to comment on them all, but let me comment on at least on the project example you give.
There are places in which Agile (a high-level philosophy) and some of it's methods (high-level project management methods) are not fully adequate. I agree with that. That's why I started this series of posts where I try to explain that the PMBOK is useful, but not enough!
Even in the project that you mention there are many things that can be done better if done within the scope of a high-level project management framework like Scrum.
To your point about "code-level" change control I'd like to remind you that the Extreme Programming (XP) movement is an Agile movement (not a PMI movement) and XP is extremely focused on engineering practices (but also project management). Code-level change control/configuration management is something that in the software community we don't even consider as an "option".
To your point about pragmatism: Agile methods like Scrum or XP are all about pragmatism. They are practical methods, unlike PMBOK which is a theoretical description of what an all-emcompassing project management effort should consider.
BTW: you seem to have quite a lot to say, would you like to publish a reply from you on my blog? I'd be glad to :)
By
Unknown, at August 12, 2009 11:58 AM
I'm not really surprised that agile practices in a PMI culture will sometimes result in cargo cult umplementations where people go through the moves without understanding the principles and then act surprised when the results are not as expected.
I think the most important thing agile gives us is a new model to look at the world of software engineering, a model based on the idea that in complex situations like a development team you need responsible individuals working together to create quality software.
Agile practices are derived from that model. You can apply these but if the day to day decisions you take are based on a different model things can start to go wrong. If you feel safety comes from having a well defined set of requirements and a stable architecture from the start of your project then agile practices dont fit. Or if you base your teams around scientific management ideas and a command and control structure then people in your team will probably not show the individual flexibility needed to succesfully operate within a agile environment.
Unfortunately the agile community is to blame for this situation. We're not that good at communicating our values. Try to buy a random book about agile and look at the contents. They're mostly about practices not principles. Agile organizations like the Scrum alliance and agile alliance focus on teaching practices too. I think instead of making fun of 'those silly PMI people' we need to fix our message.
By
Unknown, at August 12, 2009 12:51 PM
@Mendelt
I agree with your comment. We, in the agile community are not very good at explaining our principles, but rather tend to focus on practices.
I hope to remedy that (to some extent) with the series of posts I'm writing in this blog. Check those as well!
By
Unknown, at August 12, 2009 1:22 PM
I really subscribe to Woody's comments: This is very much a false dichotomy and an unnecessary contretemps. Remember "The Cathedral and the Bazaar" discussion? Both PMBOK and Agile have their values, flaws and, most importantly, areas of applicability. They are contextual approaches to be used for different ends and purposes, with some degree of overlap in the semantic domain; that is all. Neither claims to be the Holy Grail, although some of the proponents in either 'camp' do make such claims.
BTW: WTF is three words, not one. ;)
Mats Andersson
By
Anonymous, at August 12, 2009 4:13 PM
@Mats Anderson
I agree that there is some "extremism" in some of the positions, which is not necessarily helpful to find a middle-ground in our discussions.
We should be looking to what we can learn from each other.
However, I do feel that there is a significantly different set of beliefs between Agile project management and PMI-style project management. Those differences need to be exposed if we are to have a productive dialogue. That's BTW what I'm trying to do with a series of posts that I've started in this blog.
By
Unknown, at August 13, 2009 9:44 AM
Vasco,
Agile is a family of iterative software development methods based on ODD.
Feature Driven Design and Development, Crystal and RUP are mainstream agile frameworks that advocate up front modelling.
Are you completely rejecting these Agile approaches?
By
Murray Robinson, at October 07, 2009 2:43 PM
@Murray
On the contrary. I'm trying to make a case in this post (and some others published after this post) that PMI cannot be Agile because they have fundamentally different beliefs about Software Project Management.
I believe only Agile project management practices are adapted to the software projects we deal with today. PMI actually rejects or does not consider some of the key aspects of Agile Project Management (see my subsequent posts for more details on this).
By
Unknown, at October 07, 2009 3:06 PM
PMBOK V4 is compatible with and supportive of Agile processes. Here are some relevant quotes from CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION
"There is no single way to define the ideal structure for a project"
"it is up to the project manager and the project management team to determine the most appropriate method of carrying out the project"
"There are three basic types of phase-to-phase relationships:
• A sequential relationship, where a phase can only start once the previous phase is complete. Figure 2-4 shows an example of a project with entirely sequential phases. The step-by-step nature of this approach reduces uncertainty, but may eliminate options for reducing the schedule.
• An overlapping relationship, where the phase starts prior to completion of the previous one (see Figure 2-5). This can sometimes be applied as an example of the schedule compression technique called fast tracking. Overlapping phases may increase risk and can result in rework if a subsequent phase progresses before accurate information is available from the previous phase.
• An iterative relationship, where only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can reduce the ability to provide long term planning The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases."
refer to http://www.slideshare.net/vivirib/pmbok-guide-fourth-edition
By
Murray Robinson, at October 08, 2009 5:15 AM
@Murray
PMBOK v4 is rather new and I have to admit I'm not familiar with it.
However v3 completely ommitted the discussion about phase-to-phase relationship in the way you defined it in your comment.
Another aspect that is seldom discussed is that in IT projects (specifically Software Products) we are very quickly distancing our methods from the project-concept.
In many companies where I've worked projects no longer represent in any meaningful way how the company works.
Another caveat is that Linear-iterative projects (like RUP proposed) are significantly different from Incremental-iterative projects like Scrum proposes.
All in all, there are significant differences that warrant a very skeptic look at what PMBOK has to offer.
By
Unknown, at October 08, 2009 9:00 AM
I am a novice in the Project management space.. looking at the discussion i get an impression that there are two (Agile & PMI) which is trying to "push" their respective methology..
I am trying to understand which methology (PMI or Agile) would be suited for our organisation, but looks like i am totally confused...
Robert
By
robert, at February 27, 2010 10:27 AM
@robert
I understand that it may be confusing if you don't have experience of *both* approaches.
There are two things I'd advise you to do.
1. Read a good project management book (here's a good one)
2. Read a good Agile Project Management book (here's a good one)
Once you decide on which approach you prefer try it out and decide if that is for you.
I could not recommend anything else than an Agile Project Management approach (like Scrum or Crystal). I have done both and would not go back to a PMI/IPMA based approach to project management. However, there are many good things to learn from that "old-school" approach as well.
By
Unknown, at March 02, 2010 4:25 PM
PMBOK v4 is quite supportive of agile development and discusses it as one of several possible ways of managing a project. Agile and PMI are not incompatible or even directly competitive as many people think. Go read PMBOK 4 and you will see sections on iterative development, progressive elaboration of requirements, small cross functional teams, prototyping, consultative management styles.
By
Murray Robinson, at March 02, 2010 11:14 PM
@Murray
That is your interpretation.
However, assuming that you are correct it would be a positive change in PMBOK since iterative SW development and progressive elaboration of requirements has been documented since the 70's.
By
Unknown, at March 03, 2010 9:52 AM
Whos said PMI is Waterfall administration?
Pmbok mention some elements than the PM would pay attention but never said you how to execute your project.
I think, we can manage a project with PMI and use Scrum to execute a software development by example.
Finally the software development is only a process into the main project
By
Harold B, at August 03, 2010 12:28 AM
Vasco seems to be really confused between Project Management and Software Development. I would say Software Development is a big, yet a component of an IT project. There is more than just software development in a project.
Having said that, there are good aspects in Agile that PMI misses. Project Management could use these aspects to manage a project better. Similarly Agile development could manage each sprint/task in a modified / condensed PMI prescribed methodology for effective management.
Best of both could be the best!
By
Anonymous, at October 10, 2010 9:33 PM
@Anonymous
The confusion or appearance thereof may come from the fact that in this blog we mostly discuss Software product/service/etc. development.
And in this space, the project is about delivering a product/service/etc. that is fully (or mostly) dependent on the software being delivered.
I know that PMI talks about Project Management in "general", that's not our case in this blog, and therefore we *must* point out how PMI ideas apply (or not) software-focused project management.
Thanks for your comment! ;)
By
Unknown, at October 11, 2010 11:09 AM
Post a Comment
<< Home