Agility and PMI

The Project Management Institute has recently made announcements about its program to incorporate agility into its project management program.  I of course welcome this and look forward to PMI shifting from its previous approach to an agile approach. The test of this will be, of course, the success of the projects that adhere to its principles. In the past, the success (or yield) of their predictive approach has been less than 50% of projects (on time, on date, with the desired functionality.) Most agile methods have a much higher success rate, including the success in cancelling low return on investment projects early. We will watch and see if those that employ PMI’s agile approach enjoy such success, or at least an improvement on the 50% mark1,2,3.

PMI in the past has embraced the predictive, mechanistic approach to project management. This was first espoused by Frederick Taylor in “Principles of Scientific Management,” which was the basis of the Ford Model T assembly line. It is an approach for predictable, high volume, low cost manufacturing. Its benefits accrue from squeezing all of the unpredictability from the problem space through standardization and repetition. Perfect planning, training, and repeatability are the hallmarks. Plan and then do over and over again. The measurement of success is the yield rate, which is often very near 100%. Productivity is optimized through perfect processes, invariant workflow, and optimized use of resources (people or machines).

Agile processes, by way of contrast, work for development of complex products, where there is some repeatability but there is more new development than old. Products have to be devised anew each time as the requirements, the technologies, and the capabilities and creativity of the people change. In these situations, we’ve found that just-in-time planning, with frequent inspection and adaptation is required. Risks are managed and predictability created by limiting the time span between these planning events, and by ensuring the transparency of all artifacts. We have also found productivity, quality, and creativity is greatly enhanced if the people doing the work also plan their own work. They are not managed as resources, but as people that can do their best when they figure out how to do the work themselves. Self-organization and cross-functionality are vital to the success of these teams.

We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.

In Scrum, we have removed the project manager. The Product Owner, or customer, provides just-in-time planning by telling the development team what is needed, as often as every month. The development team manages itself, turning as much of what the product owner wants into usable product as possible. The result is high productivity, creativity, and engaged customers.

We have replaced the project manager with the Scrum Master, who manages the process and helps the project and organization transition to agile practices.

How PMI bridges the profound difference in philosophy, thinking, leadership and management between its traditional predictive approach and the new agile empirical approach will be fascinating to watch. How it refashions the role of project manager will be an exercise in agility itself. I for one wish the people at PMI the best. They certainly need a better success rate than 50% to regain the trust of their customers.

———————————————————————-

1. Derived from “The Rise and Fall of the Chaos Report Figures”, January/February 2010 IEEE Software, J. Laurenz Eveleens and Chris Verhoef, Vrije Universiteit Amsterdam.

2. 2009/2010 Standish Chaos Report, Standish Group, indicating:

  • 32%   Successful (On Time, On Budget, Fully Functional)
  • 44%   Challenged (Late, Over Budget, And/Or Less than Promised Functionality)
  • 24%   Failed (Canceled or never used)

3. In addition to a low yield rate (rate of successful delivery), statistics also point out that over 60% of the functionality delivered is rarely or never used, a tremendous waste of development and support funding. Resulting from not prioritizing requirements. http://en.wikipedia.org/wiki/Software_bloat, “Software Bloat.”

33 thoughts on “Agility and PMI

  1. Great article, Ken. I think where the PMI has a real advantage over the Agile community is in mind-share, and in the entrenched command-and-control culture prevalent in large organizations. I would expect there to be an initial early flood of PMP’s who want to understand what Agile software development is all about.

    Only once they begin to comprehend the profound differences (which you’ve hinted at) will we really understand whether the PMI is capably of the deep and disruptive changes. It’s certainly going to be interesting to see where this leads.

  2. There are some who consider PMI “evil”, others strongly believe in PMI. Now comes PMI’s new Agile certification. As much as skepticism about PMI’s past philosophy of linear, traditional project management is justified, the new certification is a huge milestone for PMI, for the Agile community and for project management in general. Given its global reach PMI will help spread the word and practice of agile project management. This cannot be a bad thing. Just the opposite is true.
    Whether or not a certification proves that he or she is truly capable of managing or working on an agile project, is another question. It does show that the person has successfully passed an exam. Where the PMI certification is more promising than others is the prerequisites to register and take the exam in the first place. The candidate has to prove his/her actual experience in the agile world prior to taking the exam. Personally, I think this is a much better approach than letting people take an “exam” after a 2 day seminar and then call themselves “master”.
    In short, a certification is a label; and, it can be much more than that it is paired with actual experience and the right attitude to agile. I am somewhat optimistic that PMI’s new certification will help serve the latter purpose.

  3. I don’t think it matters very much if the PMI succeed or fail with their Agile effort. The PMI, and other such monolithic organizations are akin to dinosaurs in this burgeoning age of self-organization and the quest for meaning and purpose at work. Extinction is just a matter of time.

    Nice article though, I especially liked this:

    “We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.”

    So true!

    • In response to TobiasMayer:
      Well, I think you exaggerate when you are writing that “project manager’s thinking contrains the creativity and intelligence of everyone else on the project to that of the plan …”

      First of all, there can be Agile project management.

      Second, an experienced project manager knows that a plan first of all serves as an orientation and is subject to change. He/she embraces this change.

      Third, there are still quite a few projects where pure agile is definitely not THE best approach. You take the approach which works best in the given environment.
      Thinking that AGILE is the only way is one-dimensional and myopic as well as dogmatic.
      Fourth, creativity requires structure. The question is how you build this structure and whether or not this structure is limiting creativity or not. Two examples of structures I can offer are the alphabet and how you form words, another example would be the 3 core colors.

      Fourth, PMI is a big organization indeed. And there are and always will be those who remain skeptical about Agile and maybe even oppose it. Face it, this is life. The question is if you are willing to collaborate with them, show them the power and the limitations of Agile (in other words, exercising an Agile attitude) or blocking open interaction. It is up to you.

  4. Hi Ken -

    Regardless of the context, the collaborative roles required by all Agile methodologies expect different types of beliefs and behaviors than traditional command and control approaches. My guess is that the PMI certification will initially entice people who are practicing Agile successfully and want a standard by which to prove their value; followed by those who are curious about Agile.

    In the end, it all comes back to the culture a leader/manager can create to support the Agile team; without it – we have a series of practices and a certification exam that proves very little.

    Thanks for starting this conversation,

    David

  5. Ken,

    Some very good points. I completely agree that how PMI implements there Agile certification is going to very much affect its credibility and viability. My personal hope is there are enough Agile minded folks working on it, that it becomes a useful benchmark. Like any certification, it doesn’t confer perfection, only that the person passed the tests and has an understanding of the concepts. It’s not the Holy Grail, but can be a good information radiator on a project manager’s understanding.

    Like Tobias I found this paragraph notable:
    “We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.”

    It sounds like you are talking about traditional “Big Development Up Front”, “Change is a bad thing” projects, is that the case? As a broad statement characterizing what all project managers do, it seems to be a very constrained view. I know I’ve never been accused of stifling creativity or the inteligence of the teams I’ve been a project manager for. I would say a much larger percentage of project managers espouse my own views on project management which is to help a team get from point A to point B with the team (and usually company)agreed upon final value. Nothing says that value (or date, or cost) is the same as the plan when it started.

    In my mind that is not all that different from the responsibilities invested in the role of scrum master. Good Project Management isn’t about slavish adhearence to the plan.

    Best,
    Joel Bancroft-Connors

  6. @thomasjuli

    > Well, I think you exaggerate when you are writing that “project manager’s thinking contrains the creativity and intelligence of everyone else on the project
    I din’t say that. Ken Schwaber did.

    > Thinking that AGILE is the only way is one-dimensional and myopic as well as dogmatic.
    I didn’t say that either. And I am not fixated on Agile. Nothing I wrote above implies that.

    > In response to TobiasMayer:
    I am not sure what you are “responding” to, but it doesn’t seem to be to anything I actually wrote.

  7. @Joel Bancroft-Connors

    In your paragraph that starts “It sounds like you are talking about…” You mix up the roles of Product Owner and ScrumMaster. The ScrumMaster is agnostic to the products being built, having a focus on developing the team, facilitating the process and socializing Scrum to the wider organization. The ScrumMaster does not get involved in prioritization, release plans, dates or assessments of value. Those are all in the PO and Team domain. The way you describe your PM role, crossing over into both process and product domains, is actually the antithesis of Scrum.

    A ScrumMaster is /not/ a project manger. She does not manage projects, but facilitates teams. This is an entirely different focus. To attempt to map the project manager role onto a Scrum role is to entirely misunderstand Scrum. This is not “Agile Project Management” (whatever that is) but a new paradigm altogether.

    • Tobias,

      My apologies, didn’t mean to create confusion.

      The point I was trying to make is that a good project manager doesn’t manage the project. A good project manager is a team facilitator. In that, they are very similar to a scrum master. I found it very easy to step into my CSM shoes as I’d been practicing very similar concepts as a project manager for years.

      Best,
      Joel

  8. @Tobias:
    yes, you are right that in (pure) Scrum there is no role of project manager. As Ken states it “We have replaced the project manager with the Scrum Master, who manages the process and helps the project and organization transition to agile practices.”

    Note, however, Scrum is NOT the absence of project management.

    Also, neither Scrum nor Agile are entirely new paradigms.
    Agile has been around for a very long time. Years ago, well before the Agile Manifesto, I managed projects which in today’s terminology you would call “Agile”. Back then we had a project plan (it was a fixed time, fixed price project), alas with lots of agile elements. We did what worked best for the client, thus ensuring ongoing project results, creating business value and customer happiness. This is was successful projects are about.

    • > I managed projects which in today’s terminology you would call “Agile”.
      No, I wouldn’t. I’d call what you describe here “working around an elephant in the room”. That isn’t being Agile. Agile would confront the elephant.

      > Note, however, Scrum is NOT the absence of project management.
      I think it may be. Scrum focuses on products and teams, not on projects. And it focuses on self-organization and adaptation, not on management.

      > Also, neither Scrum nor Agile are entirely new paradigms.
      Because you don’t see it, does not make it not so.

      • ooops. how can you cast judgement on a project you don’t even know?! If you are interested in learning more about this and other projects I managed, have a look at http://amzn.to/h5Vt9D.

        Since you seem to question that Scrum does NOT mean the absence of project management, maybe you can clarify your understanding of project management. Please also read Ken’s and Mike’s statements above which support this hypothesis.

        And, last but not least, why and to which extent do you think Agile are entirely new paradigms?

  9. Couple of fun facts about PMI…

    PMI did not create this certification in a vacuum. Everyone on the core team, and subsequent content committees, were people you’d know and love from the mainstream Agile community. We had Alistair Cockburn, Mike Griffiths, Michele Sliger, Dennis Stevens, Ahmed Sitky, Dan Rawsthorne, Stacia Viscardi just to name a few.

    Did you know that Scrum is the predominant methodology used in the PMI to deliver their own IT projects? Did you know that PMI is perfectly willing to introduce something into the market and then inspect and adapt as they get more feedback from their community?

    There was no monolithic plan. There was no command and control project management. This intiative was run in a more agile and collaborative way than anything I have been involved with in the agile community to date. PMI is a broad and diverse community… and painting this organization with a broad brush doesn’t acknowledge the diversity of perspective and opinion contained within the organization.

    As I followed this thread… I was struck by the us/them language. There is no us and them… there is only ‘we’… and ‘we’ are better off with Project Managers that know, understand, and embrace agility than we are with Project Managers that are afraid. I challenge everyone here to go to the PMI website and learn about what is really being offered here… I think you’ll will find we are moving this community in the right direction.

    PMI is truly a community of people trying to do project management better. And by the way… even though Scrum did away with project managers… it did not do away with project management. We need all the people on our team to do project management better… this certification will help with that.

    • I couldn’t agree more. PMI has come a long way and is definitely going into the right direction. It pays off to take part in this journey.

    • I wanted to respond to this, but rather than hijack Ken’s blog with my opinions (i.e. any further!) I decided to write my own blog post instead: Scrum is not Project Management: http://j.mp/e9ov3F

      • I agree. (I think!) (my post on it: http://thestuffihave.com/blog/?p=193) Scrum is delivery, not management. Management is business, not development. PMI is ALL types of projects, not just software, not just business systems.

        Would you build a battleship using Scrum?

        Good that PMI is doing this, to quell the critics and to respond to the need. But all they really needed to do was explain better what project management is(n’t).

  10. This quote highlights the semantic gap in the reasoning in this post.

    “The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.”

    The name is not the thing. What if the Scrum Master’s thinking constrains creativity or the Product Owner’s thinking constrains the intelligence of the group? Just changing the name doesn’t make this go away. Talented and experienced Project Managers don’t think this way – they understand the source of value. It isn’t a PMI position that project managers should use a Tayloristic approach – this is dated thinking generally underlying management science that most people now intuitively follow. Product Owners, Scrum Masters, Line Managers, CFO’s etc are all as prone to this type of thinking as Project Managers.

    This post also points out why PMI’s embrace of Agile thinking is so important. They recognize the problem and are actively trying to address it. There is still a need for project management – and there is still a need for project manager’s in many instances. The PMI community is working to promote the philosophy, thinking, leadership and management needed to responsibly deliver development and knowledge based projects.

    • > The name is not the thing.
      Absolutely. Which is why Scrum creates entirely new roles with entirely new responsibilities. Projects are not managed by single people, instead products are created by teams.

      > There is still a need for project management
      No, there isn’t. Not in software development. Maybe in building or other disciplines. Maybe.

  11. Pingback: The Project Management Institute is turning Agile | Matthew Sorvaag

  12. Pingback: Being Agile(Scrum) in a PMI world! « Thanks for coming in today.

  13. Interesting debate.

    Project Management is not just about managing the development phase, the PM has to manage the overall cost (budget), timescale and quality of the the deployment and implementation to the business, IT Support and IT Operations of the resulting software too. Just because the software development is agile doesn’t mean everything else is.

  14. Pingback: Being Agile(Scrum) in a PMI world! « Christopher Daily's Blog

  15. Pingback: Agility and PMI (via Ken Schwaber's Blog: Telling It Like It Is) « JOON PARK's blog

  16. Pingback: Being Agile(Scrum) in a PMI world! - Thanks for coming in today!

  17. Pingback: PMI et l’Agilité, avis de Ken Schwaber « DantotsuPM.com

  18. I’m sorry but there are just so many missed statements in this article, that I don’t know where to start.

    0. Saying that Agile processes are better the PMI’s methodology is like saying that using a calculator is better than studying maths. But more on that metaphor later.

    1. Success of projects shouldn’t be measured by time, budget or functionality but by the GOALS the projects was supposed to achieve. Functionality of o product can be great by itself but if the most important question is, what was the goal? If the only goal is to build a perfect product, that might be ok, but that’s more suitable for a science contest. In business it’s rarely the case. Time and budget are sometimes stated as goals but they’re really constraints.

    2. I might have missed something but I find the whole paragraph about Ford T and manufacturing process irrelevant because it describes something the PMBOK calls “ongoing work” which is the OPPOSITE of a project. PMI’s describes projects as building something new that has never been done before.

    3. I would disagree that Agile methods work better in complex products. Imagine a project with 300 people, teams in different countries whit strong dependencies between deliverables, a big-bang migration, etc. Do you think Agile would work better than waterfall in that situation?

    4. The generalization about project manager constraining anyone’s intelligence has already been criticized in other comments so I just leave it at that. It’s an unfair generalization.

    Now a couple of loosely related points

    5. Remember my metaphor from point 0. It’s a general remark to all Agile enthusiasts that are blindly criticizing waterfall and thing the former is some kind of silver bullet. Bare in mind that Project Management goes way beyond software development or even IT. Try to build a huge bridge or a 100 ft tall building using Agile practices. What I’m saying is, PMI’s methodology is general and can be (successfully) applied in different industries and different type of projects.

    6. PBMOK’s methodology is often associated with waterfall approach to building products. I must admit that I used to do it myself but now I think it’s not that obvious. I’d risk a hypothesis that PMI doesn’t say how you should build a product. It says you should plan EVERYTHING before doing it but that does not necessarily mean waterfall. It depends how you define that EVERYTHING. Although it would be an overkill, I can imagine treating each iteration as a sub-project and managing it according to PMBOK rules.

    Having said all that, I’m not saying that PMI’s approach is superior to Agile. I’d rather say that both approaches can work better in different situations.

    • Very well said by Michal Subel. I think the bottom line about selecting the development model based on the situation. No model can solve everybody’s problem in this world and we need to take a lot of tradeoffs while delivering the project. The major benefit I see in agile early surprises better control and hence customer satisfaction. Also it better suits to software development than other domains and it of course it does not mean agile models does not fit for non-software domains.

  19. Pingback: Project change control in 4 easy steps « IT Millennial

  20. Pingback: Scrum Master vs Project Manager | Agile Management

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s