The Richmond SPIN group recently hosted a workshop entitled "Oil and Water" that invited Agile Richmond to discuss how Agile methodology does or does not align with the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK). As someone working on an Agile project, studying for my PMP certification, and having a waterfall development background, I was intrigued to participate in an open forum for Agile and PMBOK practitioners to discuss if/how both are used together in the real world.
At first glance, it may seem that there is no need to compare Agile to the PMBOK. One is an approach to software development (see the Agile Manifesto) while the other is a set of project management best practices. Theoretically, all of the PMBOK practices could be implemented on an Agile project. However, in my opinion the PMBOK lends itself more to a waterfall software development approach with its step-by-step processes and emphasis on documentation. Or, to put it another way, it's not obvious where all the PMBOK suggested documentation would fit into an Agile project, or if it would add value by being forced into an Agile project.
So how do the two methodologies integrate? Do they fit? How does Agile stack up to traditional, documentation-heavy approaches? Up against a hip name like "Agile", do the contenders stand a chance? Read on for my thoughts on the matter after hearing from a diverse group of practitioners at the workshop.
No silver bullet
If you are working with a client who struggles with writing detailed requirements, adopting Agile methods will not solve this problem. Writing less-detailed user stories may be easier initially, and could certainly be a better way to start documenting requirements, but eventually the customer will have to explain the story to the point where it can be tested ("acceptance criteria" in Agile terminology). So Agile doesn't obviate the need to gather SMART requirements, it just shifts the time when they need to be gathered.
Similarly, learning the PMBOK guide and getting a PMP certification does not guarantee success as a project manager. On smaller projects, implementing every recommended PMBOK process could swamp the project with documentation. A good project manager must know which processes are needed, how they add value and how to implement them in a way that makes sense (and this is aptly pointed out throughout the PMBOK).
Benefits and tradeoffs
If you are managing an Agile project, know the tradeoffs involved in the light-PM/documentation style of Agile. Know the risks associated with these tradeoffs, and make plans to compensate for them. Being well-versed in PMI's project management methodology can really help here, and the Agile Richmond presenters made a point to call this benefit out in their workshop.
The same principle can be applied on waterfall projects – be aware of the danger of focusing on documentation and change prevention at the expense of delivering something meaningful to the client. Think about how you can bring in some of Agile's benefits in managing projects that are more sequential and structured.
Expanding the toolbox
As I am learning more about Agile methods, I am seeing a lot of great ideas that could apply just as well to a sequential, waterfall project. Similarly, the PMBOK contains a wealth of great ideas and processes to help project managers deliver complex IT projects successfully. What separates good Agile practitioners from great ones is the same as what separates wet-behind-the-ears PMP's from sought-after project managers: the ability to distill a diverse set of tools, methodologies and best practices into a plan that will make your client's project successful. Below are a couple of tools I have picked up from both Agile and the PMBOK.
- The Scrum concept of a daily standup (short daily meetings where each team member says what they did yesterday, what they plan to do today, and any roadblocks they may be facing) fosters accountability, teamwork, and rapid identification of risks and issues. This is especially powerful when combined with the idea of "core hours," a predefined time each day where all Scrum team members agree to work and be available to help each other. These principles could certainly help project teams working on waterfall projects.
- If a project has cost, schedule and scope baselines defined upfront, the earned value management (EVM) concepts explained and recommended in the PMBOK are a great way to track the health of your project. EVM provides an integrated view of where a project is compared to the scope, schedule and cost baselines, which gives the project manager and client greater insight into overall project performance than simply tracking progress against dates and milestones.
All standards and methodologies have their strengths and weaknesses, and as consultants looking out for the best interests of our clients, we must identify what will work best given our understanding of the project, the client, company culture, and host of other factors.