This post has been superseded by a new version. The new version can be found here:
I’ve been working on developing a graduate-level training course on Agile Project Management based on the two books I’ve published in this area for a major university. In developing a course like this, there are two aspects of the work to be done:
- Synthesizing or developing the body of knowledge that you need to communicate, and
- Designing the course materials to teach that body of knowledge
If the body of knowledge associated with Agile Project Management were available in some well-documented form like PMBOK, the task of developing a course to teach that body of knowledge would be much easier, but I’m not sure if the body of knowledge associated with Agile Project Management will ever exist in that form.
There’s a fundamental problem with PMBOK that it attempts to boil down everything you could ever possibly want to know about project management and put it in the form of some checklists that you can use for managing almost any aspect of a project. I don’t think that approach works very well with Agile Project Management at all…Agile Project Management requires a much more adaptive approach to fit the methodology to the project and to the business environment and checklists just aren’t generally very useful for doing that. To do that effectively, requires a deeper understanding of the principles behind why you would do things in a given situation and not just an understanding of the mechanics of how to do things as a checklist might provide. It’s also difficult to boil down Agile Project Management principles and practices into a concise form like that.
This is a fundamental problem that I think PMI is a long way from solving and I’m not even sure what the solution is:
- Is the solution to make PMBOK more “agile” or to create another version of PMBOK that embodies everything you might want to know about Agile Project Management? PMBOK version 5 sprinkles a few words about Agile here and there but doesn’t scratch the surface of what needs to be done in my opinion.
- The PMI-ACP exam and materials are a step in the right direction but don’t go far enough in my opinion. The PMI-ACP exam as it exists today is mostly a test of terminology and doesn’t really test that you know how to blend Agile and traditional project management principles and practices in the right proportions to fit a given situation – that’s the real challenge facing many project managers today.
This problem is made even more difficult because the principles and practices associated with Agile Project Management are still rapidly evolving and are even somewhat controversial:
- It’s rapidly evolving because much of the knowledge behind Agile principles and practices are based around the notion of a single Agile team and typically there really is no defined role for a Project Manager at that level. The role of a project manager, if any, would typically come into play for larger and more complex enterprise-level solutions and much of the knowledge associated with how to scale an Agile approach to enterprise levels is not well-defined or understood at this point
- It’s somewhat controversial because many people see traditional project management and Agile principles and practices as separate areas that are in opposition to each other and don’t mix very well (like oil and vinegar). The idea that you can blend those principles and practices together as needed to fit a given situation is not widely-accepted yet by many people and there are even some people on both sides of the fence that regard it as “heresy” to even entertain the idea that you can blend these principles and practices together.
My opinion is that PMI has an enormous challenge to figure out a solution to this problem and it may even require a major rethinking of how PMI synthesizes and communicates knowledge like this because I just don’t think extending PMBOK or creating another version of PMBOK is likely to be an effective solution. PMI has a huge vested interest in PMBOK and any changes to PMBOK typically take a long time to build consensus on and produce which makes this an even more difficult problem to solve.
A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives and there is a limited amount of information on what needs to be done to scale small, single team projects to large, complex enterprise-level initiatives.
One of those areas that often needs to be done differently on large, complex, enterprise-level projects is Product Backlog organization. On small single-team Agile projects, the predominant thinking seems to be that you only need to plan the backlog a few sprints in advance, you just prioritize the stories in the backlog, and then pull them off as needed to start a sprint. That method starts to break down as you scale projects to large, complex enterprise levels. There are a number of problems I’ve seen with that approach:
- Without planning the backlog further in advance, it’s difficult to assess the overall scope of the project and determine the resources required for the project. For example, I’ve seen a project that just started development with a small, single Agile development team and after two years of development still had no end-in-sight of when the project would be completed. It was a major surprise when we stepped back and re-planned the entire backlog at a high level to find that the project was going to take almost another two years to complete with the current level of resources.
- When you have a large product backlog with hundreds or perhaps even over 1,000 stories, understanding the inter-relationship of the stories becomes important. When you make priority changes among stories in the Product Backlog, it often doesn’t make sense to do it the level of individual stories…if you move one story up in the Product Backlog, what about the other stories that are inter-related with it? Wouldn’t you want to move all of those stories together as a group? Organizing the Product Backlog into Epics and perhaps even themes provides a way to make priority decisions at a higher level that is more appropriate for enterprise-level projects. At that level, priority decisions are often more based on a higher-level of epics and themes rather than at the level of individual stories within an epic or theme.
- Another major problem area is architecture. If you take a piecemeal approach to doing individual stories without planning and considering the entire solution, it can lead to poor architectural decisions and possibly significant rework later on.
- Finally, when a project grows to the point that multiple teams are involved, it becomes even more essential to organize the work to be done in a way that it can be segmented among multiple teams without requiring excessive amounts of coordination overhead among the teams.
In another article I recently wrote on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies that need to be integrated such as Program Management and Product/Project Portfolio Management. In a large company, organizing the Product Backlog into a hierarchical structure can be essential to support effective decision-making at those higher levels of management above the level of a single Agile team and that is often critical to ensure that all of the projects in an organization are well-aligned with the company’s overall business strategy.
I was recently asked to help a consulting firm who is working with a client having trouble with a very large enterprise-level Agile implementation. It seems that the company had gone head-over-heels into Agile across the whole company and the senior executives were unhappy with the way it was going. Many projects were going off track and senior management didn’t feel like they had much visibility and predictability to see if all the development efforts were really well-aligned with the company’s business strategy. I think this is a typical problem that many companies face for large-scale, enterprise-level Agile implementations.
The problem is that large companies typically have some kind of management infrastructure such as a PMO for managing projects as well as some kind of project portfolio management approach to align projects with the company’s business strategy and that existing management infrastructure probably isn’t totally compatible with an Agile development approach. The choices are:
- Dismantle the existing management infrastructure and simply implement Agile at a development team level with no guiding management infrastructure. That typically results in problems such as projects going out of control and not being well-aligned with the company’s business strategy.
- Implement a new top-to-bottom Agile management approach such as the Scaled Agile Framework. This is a good solution but requires a major redefinition of the company’s management infrastructure and some companies are just not ready to make that kind of gut-wrenching change.
- Implement a “bridge” between the existing management infrastructure and the Agile development approach using a hybrid management approach overlaid on top of the Agile development process.
The most important point is that you can’t ignore the need for these higher levels of management and implement Agile as a development process without defining some way that it integrates with the company’s overall business strategy. The choices look something like this:
This can be a difficult thing to do because standard Agile methodologies such as Scrum do not provide much guidance above the development team level and there are a number of choices at each of these levels. At each level, there is a choice of implementing a more Agile or a more traditional, plan-driven management approach. It is somewhat like a chess game as shown in the diagram below:
Here’s how I would position some of the frameworks for filling this need:
The three frameworks shown above are:
- My own Managed Agile Development model
- Scott Ambler’s Disciplined Agile Delivery model
- Dean Leffingwell’s Scaled Agile Framework (SAFe)