In September 2017, the PMI produced the sixth edition of its Project Management Body of Knowledge, the PMBOK Guide. And, at the same time, it published the new Agile Practice Guide, in collaboration with
What made this remarkable was not just the timing, but the bundling together of the two guides into one package. Whilst you can buy each separately, the linking of the two seemed to signal a big shift in PMI thinking. Is the Agile Practice Guide now a part of core Project Management knowledge in the eyes of the PMI?
Two things are for certain, however:
Whether you think PMI is getting it right or not, this is a document you should be familiar with. And if you don’t have an opinion, then perhaps you should examine some of the issues.
This is still an interesting document that can provide valuable knowledge and open up interesting areas of debate.
In this article, we’ll examine:
But, before we start, we’d better answer the question, what is Agile Project Management?
Despite the revisions in the Sixth Edition, the PMI’s Project Management Body of Knowledge (PMBoK) remains resolutely anchored to traditional predictive project management.
Each of its 10 Knowledge Areas does contain a section on ‘Considerations for Agile/Adaptive Environments’. But these tend to be no more than two or three paragraphs. It’s very much an awareness-raising approach.
And PMI does, indeed, have its own Agile Project Management qualification: PMI-ACP – the PMI Agile Certified Practioner. Not only that, but PMI-ACP is PMI’s fastest growing qualification.
The PMI-ACP Exam tests for in-depth knowledge of agile practices, tools, and techniques. But it is supported by 12 reference works, none of which the PMI publishes.
So, it would seem that PMI needs something to bridge the gap. And that is what the Agile Practice Guide starts to do.
The Agile Practice Guide is the PMI’s first attempt at melding together the two contrasting views of Project Management.
Firstly, the Agile Practice Guide is not a ‘How to…’ guide to Agile Project Management.
Rather, the Agile Practice Guide gives guidance on agile practices, for project managers who want to adopt an agile approach to planning and delivering projects. It was developed in a collaboration between the PMI and the Agile Alliance to draw the links between traditional predictive (‘waterfall’) and agile approaches.
Here is how the PMI and Agile Alliance each describe the Agile Practice Guide
…the Agile Practice Guide provides tools, situational guidelines and an understanding of the various agile approaches available to enable better results. It is especially useful for those project managers accustomed to a more traditional environment to adapt to a more agile approach.https://www.pmi.org/pmbok-guide-standards/practice-guides/agile retrieved 11 March, 2019
…the intention to build a greater understanding of agile practices, with emphasis on how Agile relates to the project management community.https://www.agilealliance.org/introducing-the-agile-practice-guide/ retrieved 11 March, 2019
The Agile Practice Guide has five substantive chapters, plus an introduction and call to action.
We’ll summarise chapters 2-6 below. But I’d also note that there is also a lot of value in the three Annexes and three Appendices:
I like this chapter. It is a terse but well-written introduction to what Agile is and when it is useful. It introduces the Agile Manifesto, without burdening you with lots of history.
And it sets out most of the popular agile methodologies, which the guide outline in Annex 3. It does not set out to be comprehensive, nor to endorse or recommend any particular approach.
The final section of this chapter develops the argument that Agile is an ideal response to complexity, which arises from uncertainty in requirements or technical capability. I’m not sure I buy the argument that this is what complexity means. I see it as more about massive inter-connectedness.
However, there is no doubt that these uncertainties contribute to complexity.
I’d suggest that this is the most important chapter. It’s also the most contentious and, I fear, the least clear. I’d like to see a lot of work on this for any future edition. But the challenge will be reconciling the two opposing responses to its proposals. More about this in the section below with our considered response to some aspects of the Guide.
Crucially, the chapter starts by setting out Agile as a combination of iterative and incremental approaches. This is all correct, but I suspect a new reader would find it hard to be clear on the distinction between iterative versus incremental from the Guide’s description.
So, at the risk of confusing you further, here is my way of understanding the difference…
Repeating a process to refine the outcome at each cycle (or ‘iteration’). So, the first time we produce a minimal result (a ‘minimum viable product’ or MVP) and then we refine it to a version 2, and then a version 3, and so on.
Therefore, in an iterative
Building part of a
So, we build one feature at a time and when it is done, we can be confident we have created something of value. It’s like painting one room of your house completely, before starting the next one.
This chapter focuses on the twin roles of the leader and the Agile Team.
The leadership model at the core of the Agile approach is ‘Servant Leadership’. This is a topic I wrote about in an article for ProjectManager.com: ‘How to Manage with Servant Leadership’.
The chapter relates this to the role of the Project Manager in one of the most contentious parts of the whole Agile Practice Guide. Contentious, partly because it says virtually nothing, leaving the implication that it’s not much different from the role in predictive project management. So. I’ll return to this below.
But what I do like a lot is this quote:
The value of project managers is not in their position, but in their ability to make everyone else better.
This is a wonderful tip that applies to any leader, in any context.
The chapter is stronger on project teams, albeit, failing to describe their self-managing nature in many Agile contexts. of particular value, if you are new to the idea, is the distinction between deep specialist team members, and ‘generalizing specialists’ with depth, but also some broader skills. These are ‘I-shaped and T-shaped’ people.
The Guide makes the case that, while a deep specialist may be able to achieve greater individual efficiency, the breadth of skills in a generalizing specialist means that hand-offs between team members flow better when the team has them.
Interestingly, although the Agile Practice Guide claims to show no
This exacerbates the concerns about the role of the Project Manager.
Chapter 4 serves as a primer for the basics of how an Agile project operates. Introduces a range of Agile practices and techniques, that include:
This short chapter is the nearest you’ll get in the guide to a ‘How to…’ I’ll mention here the view that many practitioners hold that PMI has misstepped in including Earned Value Management (EVM) as one of the measurement techniques in Agile projects.
They feel this is not a suitable Agile method and that PMI has carried it across from its strong place in the management of predictive projects. My experience of Agile is insufficient for me to hold a well-informed view on whether EVM works well in Agile projects.
What I do like is Table 5.1. It will serve a beginner well in knowing what options you have in the event of problems with your Agile Project.
Finally, your project will be influenced by the context of the organization it sits in. The Guide explores a range of organizational factors that will have an impact on how you use Agile. These are:
It ends with a short section on evolving the organization in an Agile direction.
There are a fair number of areas of this document that have caused disagreements among the community. And it is not surprising that this is so. First, because this is the first attempt by PMI (or any comparable organization) to draw the two traditions together. And second, because the two traditions have divergent perspectives on many things. Finally, this is exacerbated by the strength of the views (that borders on fanaticism, on occasion) that exist.
I have assembled those issues that I feel:
And I offer my own perspective.
The two perspectives on this are well characterized in articles by Chuck Cobb and Anthony Mersino. Chuck argues that the section in Chapter 3 on hybrid approaches is ‘too high level and not specific enough to help a PM understand how to really implement a hybrid approach.’
Anthony shares my view that the description of hybrid approaches is weak (he uses the word ‘confusing’). But he goes on to say that he does not think ‘hybrid approaches are effective and I wish people would stop using them’.
One of the principal reasons we chose to promote Chuck Cobb’s program of Agile Project Management courses is because I share his attitude that it is the job of a skilled project manager to devise the right hybrid approach for the project and context at hand. I too find the Agile Practice Guide goes nowhere near a useful assessment of how to go about this.
This is sad because, as I said at the start of this article, the role of this guide is to bridge the gap. Poor work on hybrids risks leaving the gap poorly bridged.
I am one of those project managers who would like to think we can continue to manage projects taking a similar role in the future to that of the past. But if the success of Agile methods like Scrum
And that inevitably means self-organizing teams and light-touch leadership. Indeed, in principle, this accords well with my preference for ‘leaderless leadership’. There is no leader. Everyone takes a leadership role, as and when it suits them and the team. The old word for no leader is anarchy – literally, ‘without rule’.
This is a hard message to give to PMBOK project managers. The shift is a subtle and sophisticated one. So, I’m not surprised that the first edition of the Agile Practice Guide somewhat dodges the issue. I would agree with Chuck’s characterization of this as ‘the elephant in the room’.
I do think there is a lost opportunity that cannot be ascribed to sensitivity,
The latter is, perhaps understandable. It runs you hard up against the issue of hybridization. But, should serious project managers (with a PMP qualification) not be thinking about how they can contribute to debates about transforming the enterprise to become more Agile? I’d say they should.
Some commentators take issue with the characterization of Agile as a subset of Lean methods. Chuck Cobb, who is an expert we recommend, makes the point clearly in his article: ‘What is the Purpose of the New PMI Agile Practice Guide?’ On this, Anthony Mersino agrees.
I’d agree. Lean is principally about cutting out or simplifying process steps. That is not the purpose of agile. Arguably, agile introduces iterations and thereby increases process cycle times and effort.
You may be wondering, what is Lean Project Management?
Of the seven PMI qualifications, this
So, let’s see how it affects each.
The introduction of Agile Considerations into the 6th edition of the PMBOK Guide made some basic understanding of Agile fair game for the PMP exam. But the impact to date has been small.
The exam requires no detailed knowledge of Agile nor any of its methods. And the Agile Practice Guide is not part of the syllabus.
The extent of Agile topics in the exam may change over time, but for now, a read through of the Agile Practice Guide and some general knowledge will be plenty of preparation. But I recommend you keep an eye on the current responses on the PMI’s PMBOK FAQ page, in case things change.
And if you are starting your preparation for the PMP exam you must read the current PMP Examination Content Outline. PMI has indicated that the outline will change in late 2019 or early 2020.
If you are planning to take your PMP exam, we recommend:
This is even clearer. Your syllabus is the PMBOK Guide and the PMBOK Guide alone.
If you are planning to take your CAPM exam, we recommend the unbored PMP & CAPM Exam Preparation course.
In March 2018, PMI updated the terminology in the PMI-ACP exam to match the terminology in the Agile Practice Guide. It now also includes questions on the content from the Practice Guide. Previously questions came from 12 sourcebooks.
If you want to prepare for the PMI-ACP exam, we recommend Chuck Cobb’s course: How to Prepare for PMI-ACP Certification.
Do you have a point of view on the Agile Practice Guide? If you do, we’d love to hear it and I’ll respond to any comments you leave below.
If you want to learn more about Agile, we recommend Chuck Cobb’s Agile Project Management Academy, and we can offer you great prices.
Or maybe you want to prepare for Agile qualifications. If so, we can offer courses for:
Free Academy of Project Management course about Agile Project Management.
Articles on this Website include:
And, if you like Pinterest, check out our Agile Project Management board with over 350 pins.
You can get your Agile Practice guide directly from the PMI, or from your favorite bookseller, like:
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Project Management Knowledge Areas: How Many Are There? [Not 10]26 Mar, 2020
What to Put in Your Risk Register (Risk Log) | Video17 Feb, 2020
Agile Principles: The 12 Keys to Adaptive Project Management21 Oct, 2019
Agile vs Waterfall: Which one is Right for Your Project?
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.