PMI Produced a Guide to the Agile Methodology?
Some of you may be surprised as I was to learn about PMI's recent collaboration with the Agile Alliance to produce an overview of Agile Methodologies. Groups of volunteers from both organization worked together to draft and review a document on Agile. The product of their work is the newly published, Agile Practice Guide. A PMI publication, this document is now generally available and is included with the free download of the 6th Edition of the PMBOK.
I wasn't completely surprised by the release since I was one of the collaborators on the document. I had the pleasure of contributing to the guide thanks to Sally Elatta of Agile Transformations who invited me to pair with her to review and provide comments on an early draft of the document. I've learned a lot from Sally over the years and was happy to be able to collaborate with her on this project.
First of all let me say that I am happy that the Agile Practice Guide is somewhat lightweight. At 167 pages for the printed version, the document wasn't a quick read, but it looked pretty skinny when compared to the 6th Edition of the PMBOK Guide. The PMBOK Guide now weighs in at a hefty 795 pages. (In this post, my colleague Jerome Rowley gently pointed out that the PMBOK is actually only 536 pages, not 795).
RANT - The PMBOK Guide is so bloated! I don't want to show my age but I remember as a newly minted PMP back in 1996 when the first PMBOK guide came out. Like this new Agile Practice Guide, the first edition of the PMBOK was just 176 pages. How did it get to be 800 pages?!? Has it become more than 4X as good in the last 21 years? This is just a GUIDE to the body of knowledge. Geez!
Anyway, getting back to the Agile Practice Guide, I was a little surprised by the collaboration between PMI and the Agile Alliance. Frequently people see traditional project management and Agile as conflicting, or a clash of mindsets. I've written extensively about the mindset and paradigm shifts that traditional PMs need to make to understand Agile. Some project managers make the shift and others don't. Maybe this document is an attempt to build a bridge, or a way for more traditional PMs to grow in Agile thinking and methods.
I think the main take away for me is that PMI recognizes the importance of Agile methods and is working to overcome the US vs. THEM thinking that has grown over the years, especially between PMI and the Scrum community.
Will the Agile Practice Guide Become the new Agile BOK?
I really had to wonder if PMI was attempting to use the Agile Practice Guide as the standard Agile methodology, as the PMBOK has become for traditional project management. Is the next step for PMI to create the Agile Body of Knowledge?
Like the PMBOK, the Practice Guide could become the basis for the PMI Agile Certified Practitioner exam. As you may know from reading my recent blog on the PMI-ACP, the current exam content is drawn from a set of 12 individual books. Will the Guide replace the current 12 source books? After all, that is the approach for the Project Management Body of Knowledge and the PMP certification. On the positive side, this would perhaps reduce the amount of spending that people need to do. On the negative side, I think that could either 1) limit the expansion of Agile knowledge and thinking or 2) produce an Agile Practice Guide that is 500 pages just like the PMBOK. Ouch.
PMI Only Sees Projects
One of my main criticisms of the document and one that I voiced in my early review, was that the focus is all about projects. The authors intentionally drew the line between implementing Agile at a project or team level, and implementing Agile at the organization. This troubles me.
It is not that I don't believe in the value of projects, it is just that the document (and I think most PMI members) view the world through the lens of projects. This ignores the PRODUCT focus that is prevalent in many organizations that leverage agile approaches and long standing teams. Agile organizations generally don't think projects; they don't think of they work that they do as temporary and unique. Rather, they think in terms of building and maintaining valuable solutions and products. Traditional project managers have a difficult time seeing beyond the project paradigm, as I outlined in this blog post.
This approach also sidesteps the need in most organizations to move from silos of functional organizations to cross functional teams. Pulling people from these functional teams to staff short term projects is not creating a shared ownership for the end to end delivery that agile teams benefit from.
I also cannot fathom how hybrid approaches and multi-mode works within an organization. If I am a developer and I move back and forth between traditional projects and Agile projects, do I have an Agile mindset? Do I have to switch my mindset each time? What if I am working on both of these projects at the same time? I just don't see how that can be compatible.
The Actual Practice Guide Document
The guide says it is targeted to those project teams that are in that "messy middle ground between predictive and agile approaches". A lot of people are in this situation. Most organizations have at least experimented with Agile and only a small percentage are actually fully agile. So that leaves a lot of people in that messy middle ground.
Here is a Quick Overview of this new Agile Practices document:
- Section 1: Introduction to the Document
- Section 2: An Introduction to Agile—This section includes the Agile Manifesto mindset, values, and principles. It also covers the concepts of deﬁnable and high-uncertainty work, and the correlation between lean, the Kanban Method, and agile approaches.
- Section 3: Life Cycle Selection—This section introduces the various life cycles discussed in this practice guide. This section also addresses suitability ﬁlters, tailoring guidelines, and common combinations of approaches.
- Section 4: Implementing Agile: Creating an Agile Environment—This section discusses critical factors to consider when creating an agile environment such as servant leadership and team composition.
- Section 5: Implementing Agile: Delivering in an Agile Environment—This section includes information on how to organize teams and common practices that teams can use tp deliver value on a regular basis.
- Section 6: Organizational Considerations for Project Agility—This section explores key organizational factors that impact the use of agile approaches, such as culture, readiness, business practices, and the role of a PMO.
- Section 7: A Call to Action—The call to action requests input for continuous improvement of this practice guide.
What Was Helpful in the Agile Practice Guide:
- Overall, it is good to see a document that begins to attempt to wrap it's arm around Agile. Kudos to the team that put this together.
- It is great that it covers not only Scrum, but XP, Kanban, Lean and other frameworks, even the lesser known ones like DSDM and scaling frameworks like LeSS and SAFe
- The Guide acknowledges that the role of the project manager is different in Agile
- The reference to the technical practices like ATDD and continuous integration; these practices are key enablers of the agile methodology and they are frequently ignored or overlooked
- There is a focus on the Agile Principles, in addition to the Values of the Agile Manifesto that are commonly mentioned
- The idea of the Agile Mindset
- Agile measures that are empirical and focused on value delivered
- Servant Leadership is a big and important topic in Agile circles
- In the appendix, Annex A3, the document includes an overview of Agile and Lean Frameworks which was helpful
- The Glossary of Terms is pretty comprehensive
What Was NOT Helpful in the Agile Practice Guide:
- Earned value in Agile projects - PMI seems to have some weird fascination with Earned Value and they've included it in this Agile Guide. I completely disagree, and I wish those EV proponents would just drop it. Value should be measured when the working solution or product is placed in the hands of the user and costs go down or revenue goes up. There is no value being "earned" in the middle of a project, only costs being incurred and WIP being created. Stop. Please.
- Incremental and Iterative Development - This is a very minor point but I don't think anyone treats these as separate development approaches anymore. I know they are different, but most people just do both together and don't talk implementing just one or the other.
- Hybrid approaches - The description of hybrid was confusing, as was the mixing and matching of hybrid approaches. And personally, I don't think hybrid approaches are effective and I wish people would stop using them (read more at Agile Hybrid Approaches - How to Get Just the Right Mix)
- Agile described as a subset of Lean - This is a minor point, but, there is a diagram in this book that shows Agile as being a subset of Lean, with Scrum as a subset of Agile - I always thought of Agile as as the child or offspring of Lean, not necessarily a subset. In the grand scheme of things, it probably doesn't really matter.
- Project-Centric Focus - I already ranted about this above. The idea that everything is a project may not always be helpful. Time to change the paradigm? Guess what - some Agile organizations run without any projects. (Gasp!)
- Number of pages - This document is pretty big for the amount of material it is covering. It only looks thin when compared to the PMBOK. I would encourage PMI to try to keep this document as lean as possible (perhaps removing Earned Value and some of the other things I mention above). The newly revised Scrum guide is a tight 19 pages and describes the Scrum framework in it's entirety! Let's not create another 500+ page PMBOK - that wouldn't be very Agile.
If you didn't get a download, or if you prefer a hardcopy document like I do, you can order the Agile Practice Guide from Amazon. I didn't find it on the PMI site when I looked a few weeks back but it may also be available there as well.