Agile is in the PMBOK so it must be true

Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we’re talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it’s just the nature of the beast. But, it doesn’t have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM…me.  I’m not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I’ll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you’re talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is “Agile is actually in the PMBOK”. If your stakeholders are PMPs and they believe the dogma of the PMBOK, you’ll have their attention. It’s not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you’ll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

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

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It’s an excellent opportunity to deliver value.

32 comments

  • PMBOK is a description of process groups and knowledge areas. Scrum is a software development method. They are orthogonal.

    You can have Scrum based execution processes inside the EXECUTION process group no problem – just like you say.

    • Derek Huether

      Glen, thanks for your comment. I’ve seen a vendor come in with the best of intentions and proposed Scrum for a project. The customer was convinced, if a proposed solution inputs and outputs couldn’t be explicitly spelled out in the PMBOK, it was not acceptable. The vendor didn’t believe in the PMBOK and didn’t understand the needs of the customer. They failed to bridge the gap and they failed to gain the stakeholder buy-in.

      • Never trust vendors. Only hire people who have worked previous programs successfully.

        In our world this is called “Past Performance.” It must be verified and validated.

        • Derek Huether

          I’m with you there, brother! When I hire people, I do exactly that. When I advise clients, I tell them to do exactly that. If a client only has one vendor respond to their RFP, it certainly can get interesting. I would personally recommend they decompose the work into severable work packages, so more vendors could respond to the RFP. If the intent is to hire a specific vendor, well, all bets are off.

  • PMBOK is a description of process groups and knowledge areas. Scrum is a software development method. They are orthogonal.

    You can have Scrum based execution processes inside the EXECUTION process group no problem – just like you say.

    • Derek Huether

      Glen, thanks for your comment. I’ve seen a vendor come in with the best of intentions and proposed Scrum for a project. The customer was convinced, if a proposed solution inputs and outputs couldn’t be explicitly spelled out in the PMBOK, it was not acceptable. The vendor didn’t believe in the PMBOK and didn’t understand the needs of the customer. They failed to bridge the gap and they failed to gain the stakeholder buy-in.

      • Never trust vendors. Only hire people who have worked previous programs successfully.

        In our world this is called “Past Performance.” It must be verified and validated.

        • Derek Huether

          I’m with you there, brother! When I hire people, I do exactly that. When I advise clients, I tell them to do exactly that. If a client only has one vendor respond to their RFP, it certainly can get interesting. I would personally recommend they decompose the work into severable work packages, so more vendors could respond to the RFP. If the intent is to hire a specific vendor, well, all bets are off.

  • Nice Derek. We need to remember to point this out every time the Agile vs PMBOK discussion comes up. PMBOK does explicity call out Incremental and Iterative development (IID).

    And now, as Paul Harvey used to say, for the rest of the story.

    I have been talking about four points of Agile for a while. IID delivers on two of those –

    1. Progressive Elaboration In Support of Business Value
    2. Reduce Risk by Facilitating Change associated with Learning

    The PMBOK also expressly supports the third one:
    3. Drive Transparency into the Project Status, Viability of the Produce, and Delivery Capabilities to achieve Fit

    The final one is not clearly called out in the PMBOK, and it is the one that makes Agile more than IID:

    4. Compel Collaboration, Feedback and Learning about both the product and the delivery capabilities to improve quality

    I talk about this here.

    http://www.dennisstevens.com/2010/05/06/is-agile-more-than-iterative-and-incremental-development/

    This may seem like a small distinction, but at the end of the day, collaboration and learning are a really big deal – especially in knowledge based projects. And I believe that the lack of explicit focus on these is at the core of the “religious war”.

    Dennis

    • Derek Huether

      Dennis, thank you so much for insights. Its amazing how polarizing people can become when you put PMBOK and Agile in the same sentence. People get so passionate about this! I don’t see them like Coke and Pepsi. They are colas! Maybe it’s a poor analogy. But I hope people see where I’m coming from. Does it satisfy your thirst? If so, I’m a happy man. If not, try something else until your thirst IS satisfied.

  • Nice Derek. We need to remember to point this out every time the Agile vs PMBOK discussion comes up. PMBOK does explicity call out Incremental and Iterative development (IID).

    And now, as Paul Harvey used to say, for the rest of the story.

    I have been talking about four points of Agile for a while. IID delivers on two of those –

    1. Progressive Elaboration In Support of Business Value
    2. Reduce Risk by Facilitating Change associated with Learning

    The PMBOK also expressly supports the third one:
    3. Drive Transparency into the Project Status, Viability of the Produce, and Delivery Capabilities to achieve Fit

    The final one is not clearly called out in the PMBOK, and it is the one that makes Agile more than IID:

    4. Compel Collaboration, Feedback and Learning about both the product and the delivery capabilities to improve quality

    I talk about this here.

    http://www.dennisstevens.com/2010/05/06/is-agile-more-than-iterative-and-incremental-development/

    This may seem like a small distinction, but at the end of the day, collaboration and learning are a really big deal – especially in knowledge based projects. And I believe that the lack of explicit focus on these is at the core of the “religious war”.

    Dennis

    • Derek Huether

      Dennis, thank you so much for insights. Its amazing how polarizing people can become when you put PMBOK and Agile in the same sentence. People get so passionate about this! I don’t see them like Coke and Pepsi. They are colas! Maybe it’s a poor analogy. But I hope people see where I’m coming from. Does it satisfy your thirst? If so, I’m a happy man. If not, try something else until your thirst IS satisfied.

  • Paul Boos

    I’d argue that Scrum is a project management framework as well. I’ve used it and Kanban for a variety of different types of activities not just software development. Now, if you start adding specific software development practices (e.g. continuous integration), then it becomes more of a software development life-cycle methodology.

    At any rate, I think the fact the PMBOK has to discuss explicitly the phase-to-phase relationship (why can’t they adopt Agile terms of iterations) shows they are trying to show that the process groups don’t have to be done in a waterfall. The fault really goes ot how the PMBOK is discussed in most writings and taught in most courses.

    Nice post Derek!

    • Derek Huether

      Thank you, Paul!

      Some people are getting this post; some are not. I wanted to talk about the 800 pound gorilla in the room and I think I succeeded. It is my belief it would be a big no-no to try to assimilate Agile and Kanban into the PMBOK. But, give them some credit! What I want to see is an accepted Scrum Body of Knowledge or a Kanban Body of Knowledge. I don’t want anything as heavy as the PMBOK, just a light rule book. If the respective communities agreed to that, there could be a more accepted mapping to the PMBOK without jamming a square peg into a round hole.

  • Paul Boos

    I’d argue that Scrum is a project management framework as well. I’ve used it and Kanban for a variety of different types of activities not just software development. Now, if you start adding specific software development practices (e.g. continuous integration), then it becomes more of a software development life-cycle methodology.

    At any rate, I think the fact the PMBOK has to discuss explicitly the phase-to-phase relationship (why can’t they adopt Agile terms of iterations) shows they are trying to show that the process groups don’t have to be done in a waterfall. The fault really goes ot how the PMBOK is discussed in most writings and taught in most courses.

    Nice post Derek!

    • Derek Huether

      Thank you, Paul!

      Some people are getting this post; some are not. I wanted to talk about the 800 pound gorilla in the room and I think I succeeded. It is my belief it would be a big no-no to try to assimilate Agile and Kanban into the PMBOK. But, give them some credit! What I want to see is an accepted Scrum Body of Knowledge or a Kanban Body of Knowledge. I don’t want anything as heavy as the PMBOK, just a light rule book. If the respective communities agreed to that, there could be a more accepted mapping to the PMBOK without jamming a square peg into a round hole.

  • This will remain a hot topic for quite a while.

    There’s a lot to like in the PMBOK! Such as :

    * Project versus Product Life Cycle
    * The Rolling Wave
    * Progressive Elaboration: “Continuously improving and detailing a plan… ”
    * The 9 knowledge areas
    * Process assets (Lessons learned)
    * Including “Expert judgment” in most processes

    I blogged on this a little while back. Take a look :

    http://tinyurl.com/2cunm83

    Eric

    • Derek Huether

      Eric, thank you for sharing your experience from an Agile coach perspective. I enjoyed the blog post you included. It was a refreshing read. I’ve sat on both sides of the table in the last few years. A few years ago, I was SE Manager for a pre-IPO enterprise, where we leveraged Scrum during the Execution phased and were very process light. Now, I advise a Federal PMO, which is about as Waterfall and process heavy as you can get. Even when I was inspiring Scrum teams, I still had a copy of the PMBOK on my desk. To throw in an extra curve ball, I still have a Kanban board by my desk.

  • This will remain a hot topic for quite a while.

    There’s a lot to like in the PMBOK! Such as :

    * Project versus Product Life Cycle
    * The Rolling Wave
    * Progressive Elaboration: “Continuously improving and detailing a plan… ”
    * The 9 knowledge areas
    * Process assets (Lessons learned)
    * Including “Expert judgment” in most processes

    I blogged on this a little while back. Take a look :

    http://tinyurl.com/2cunm83

    Eric

    • Derek Huether

      Eric, thank you for sharing your experience from an Agile coach perspective. I enjoyed the blog post you included. It was a refreshing read. I’ve sat on both sides of the table in the last few years. A few years ago, I was SE Manager for a pre-IPO enterprise, where we leveraged Scrum during the Execution phased and were very process light. Now, I advise a Federal PMO, which is about as Waterfall and process heavy as you can get. Even when I was inspiring Scrum teams, I still had a copy of the PMBOK on my desk. To throw in an extra curve ball, I still have a Kanban board by my desk.

  • Derek,

    When you say…

    “Things can be so slow and expensive, we rarely get to see actual value delivered. Rather, successes are measured with earned value. Sometimes, I think it’s just the nature of the beast. But, it doesn’t have to be that way.”

    Are you speaking from direct DCMA ANSI/EIA 748B experience?

    Cause we produce weekly EV for physical percent complete on an ~$500M flight avionics software development program, where iteration produce working code for the spacecraft, rolling waves every 6 to 9 months to abosrb new and sometimes radically new requirements, and a full fidelity simulator where the astronauts can verify that the features they need work according to their needs.

    Or was that just a toss off phrase, echoed from something heard on the web?

    • Derek Huether

      Glen, I am speaking from actual experience. I review a Cost Performance Report, a Contract Funds Status Report, and other EV identifying contract deliverables on a monthly basis. When I say “It doesn’t have to be that way” I’m speaking to instances that you refer. EV certainly has it place on such large programs. How the vendor(s) deliver or how they report is not my area of responsibility. That’s up to the Program Director, the Contracting Officer, and CIO to deal with. My job, in this instance, is merely to bring attention to specific CLINs, if the SPI or CPI don’t seem to align with the work I see being performed and billed.

      • Derek, Do you have any bearing as to DCMA’s thoughts on certifying Agile as a recognized software development approach to DoD projects requiring EVMS and the 748-B?

        • Derek Huether

          Matthew, unfortunately, I do not know DCMA’s thoughts on the subject. I’ll admit, I do see Agile getting more press in STSC CrossTalk. It’s the Journal of Defense Software Engineering. I would recommend contacting Sanjiv Augustine of LitheSpeed. If anyone would know, he would.

          I hope I’m steering you in the right direction.
          – Derek

  • Derek,

    When you say…

    “Things can be so slow and expensive, we rarely get to see actual value delivered. Rather, successes are measured with earned value. Sometimes, I think it’s just the nature of the beast. But, it doesn’t have to be that way.”

    Are you speaking from direct DCMA ANSI/EIA 748B experience?

    Cause we produce weekly EV for physical percent complete on an ~$500M flight avionics software development program, where iteration produce working code for the spacecraft, rolling waves every 6 to 9 months to abosrb new and sometimes radically new requirements, and a full fidelity simulator where the astronauts can verify that the features they need work according to their needs.

    Or was that just a toss off phrase, echoed from something heard on the web?

    • Derek Huether

      Glen, I am speaking from actual experience. I review a Cost Performance Report, a Contract Funds Status Report, and other EV identifying contract deliverables on a monthly basis. When I say “It doesn’t have to be that way” I’m speaking to instances that you refer. EV certainly has it place on such large programs. How the vendor(s) deliver or how they report is not my area of responsibility. That’s up to the Program Director, the Contracting Officer, and CIO to deal with. My job, in this instance, is merely to bring attention to specific CLINs, if the SPI or CPI don’t seem to align with the work I see being performed and billed.

      • Derek, Do you have any bearing as to DCMA’s thoughts on certifying Agile as a recognized software development approach to DoD projects requiring EVMS and the 748-B?

        • Derek Huether

          Matthew, unfortunately, I do not know DCMA’s thoughts on the subject. I’ll admit, I do see Agile getting more press in STSC CrossTalk. It’s the Journal of Defense Software Engineering. I would recommend contacting Sanjiv Augustine of LitheSpeed. If anyone would know, he would.

          I hope I’m steering you in the right direction.
          – Derek

  • Derek,

    Good post. Religious war “Agile OR PMBOK” is artificial and useless. To me Agile IS in the PMBOK although not specifically emphasized as it is just one of approaches that can used in a project. I personally use a mix of “traditional” and agile practices depending on the specifics of the project.

    • Derek Huether

      Stan, I mirror your comment.

      Looking back, I think my post title was a little bit like link bait. Still, people can be PM zealots and really get hostile when you put Agile and PMBOK in the same sentence. I also use a mix. Before I do anything, I always ask myself what would make sense.

      Thank you for your comment!

  • Derek,

    Good post. Religious war “Agile OR PMBOK” is artificial and useless. To me Agile IS in the PMBOK although not specifically emphasized as it is just one of approaches that can used in a project. I personally use a mix of “traditional” and agile practices depending on the specifics of the project.

    • Derek Huether

      Stan, I mirror your comment.

      Looking back, I think my post title was a little bit like link bait. Still, people can be PM zealots and really get hostile when you put Agile and PMBOK in the same sentence. I also use a mix. Before I do anything, I always ask myself what would make sense.

      Thank you for your comment!

Leave a Reply

Your email address will not be published. Required fields are marked *