Can Agile Learn Anything from the PMBOK?
One of the Yahoo groups I belong to, pmiagile yahoo group, is exploring whether there is any synergy between Agile and the PMBOK. Its is an interesting yet somewhat frustrating discussion. I think we should try to avoid platitudes and clichés. I understand that there are many project managers that have interacted with development teams in ways that were destructive. I understand there have been agile teams that were not responsible in their approach to development. This discussion should not about how individuals or organizations have behaved badly. It is about looking at an established body of knowledge, the PMBOK, to see if there is anything worth learning from there that could help us in uncovering better ways of developing software by doing it and helping others do it. Todd Little recently posted:
“It would be more productive to look at what problems exist that current agile implementations do not support well. Dennis is suggesting that there are gaps that agile does not answer. I’ll buy that there may be some gaps. What are those gaps? What are the user problems that need to be solved? What are the user stories and acceptance tests for those problems? Maybe then we can look at the PMBOK as a potential source of solutions to users that have those problems.”
I believe it is pretty important that the participants in this discussion have a pretty clear understanding of both Agile and the PMBOK if they are going to offer up opinions on one or the other. I have been involved in software development since 1985 (RPG2/3/400, C++, Perl, Java, C#). By the mid 1990’s I was leading development teams following an Incremental and Iterative development process. I purchased my version of Eliyahu Goldratt’s the Goal in 1994 and Critical Chain when it came out in 1997. I was busy reading and applying Larry Constantine’s Peopleware, James Highsmith’s Adaptive Software Development, Kent Beck’s eXtreme Programming, and Alistair Cockburn’s Crystal methodology before I knew what the Agile movement was. I was explicitly applying value stream concepts, visualization, and limited WIP before 2000. I have always mixed and matched based on what made sense on my current project. I have actively been coaching and applying these ideas for over 15 years. I claim Agile chops.
I earned my PMP from PMI in 1998. I have produced hundreds of project artifacts including project plans, charters, and risk plans. I was the Deputy Project Manager on the development of PMI’s Organizational Project Management Maturity Model (OPM3®). I have actually read through my PMBOK 4th Edition in detail. I am qualified to speak about the PMBOK.
The PMBOK
Let’s talk about the PMBOK for a few minutes. First off, the PMBOK describes good practices in project management that work for most companies most of the time. The PMBOK Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. The PMBOK points out that the standard is neither complete nor all-inclusive. Additionally, the standard is a guide rather than a methodology. One can use different methodologies and tools to implement this project management framework. The PMBOK is not specific to software development – this language and this guide support all types of projects.
How The PMBOK is consistent with Agile
PMBOK supports self organizing. It is up to the organization and the team to determine what is appropriate for any given project.
PMBOK supports sprints and/or real-time planning. PMBOK doesn’t require big up front planning and then rigorous adherence to plan. PMBOK talks about iterations and progressive elaboration. Progressive elaboration is continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and therefore producing more more accurate and complete plans that result from the successive iterations of planning.
PMBOK supports continuous improvement. This is an iterative means of improving the quality of all processes, reduces waste, eliminates activities that do not add value, allows processes to operate at increasing levels of efficiency and effectiveness.
PMBOK supports overall adaptation of the product and the organizational processes. The Risk Management Section of the PMBOK calls for a continuous approach to identifying, monitoring and responding to risk. Technical Risks (including Requirements Risk and Quality Risk, External Risks (including Market and Customer Risk), Organizational Risks, and Project Management Risks.
How the PMBOK complements Agile
In many cases, software development takes place in a bigger context then just the software development team. This bigger complex can be messy, with lots of activities that have to be coordinated to deliver value to the customer. Here is a peak into that messy context.
In front of development this includes activities like market research, strategic planning, sales forecasts, budget forecasts, and making investment decisions.
During development activities need to be coordinated with development including procurement, vendor contracts, compliance research and documentation, legal evaluations, intellectual property protection, developing and implementing security, privacy and data protection controls, and designing changes to business process.
For each release of software, activities outside of development include, establishing sales and marketing readiness, updating customer service policies and procedures, updating business resilience procedures, updating impacted training and implementation procedures, updating customer service levels, re-aligning reward and recognition programs, and updating internal IT service level agreements. Then there are often launch activities around customer communication and product promotions and ICT coordination including licensing and production operations.
The importance of these activities will vary between contexts – but these are all real activities that I have had to handle on software development projects. In Agile, these are hidden behind the Production Owner or Onsite Customer abstractions. But in the process of delivering value to an organization or new product to a customer, these may exist, need to be coordinated, and aren’t particularly interesting to the software development team. This type of coordination needs to be done in a way that enables the Agile teams – to achieve the goal of delivery of value to the customer.
Barriers to Synergy
From the Agile perspective, barriers to synergy arise from the sense that PM’s will meddle in the performance of the team. This is based on historical experience and potentially a lack of understanding of real organizational constraints that result in obstacles for the team. The PM becomes the representative for these unreasonable constraints in a “shoot the messenger” fashion. The other big barrier to synergy is the prevalence of language in the PMBOK that is contrary to Agile values and principles. Make no mistake, from the definition of the project manager, through the use of words like directs, controls, and manages the language is an obstacle.
From the Project Management perspective, barriers to synergy arise from the primacy of developers and the development team in Agile talk. Project Managers also perceive the agile teams have a limited view of what “the product” is and what it takes to provide value to the customer. The project manager lives in that messy place behind the overly simplistic abstraction of the Product Owner.
How Do We Address These Barriers
Acknowledge that Agile and the PMBOK come from a different mindsets
Not regarding iterative and incremental development but from values and principles. We need to recognize this gap and start the discussion from the perspective that we are building on Agile values and principles.
Recognize that delivering value to the customer is often beyond the scope of the development team
The product is bigger than development. There is work to be done that isn’t best done by the development team. This becomes a bigger and more important deal when you are working in companies of any scale.
Acknowledge the Limitations of the Product Owner Abstraction Layer
Look back at How the PMBOK Complements Agile. That messy list of activities point out how big the set of issues are that the Product Owner is responsible for.
Distinguish between Project Management Practices and the Project Manager Role
The PMBOK is the Guide to the Project Management Body of Knowledge. It isn’t about project managers. In a small organization, with a limited number of products, with intimate access to customers, lots of automation, and a limited requirements for supporting infrastructure, the project management activities can likely be handled by a couple of people with very little coordination effort required. But in organizations of scale, the coordination effort will benefit from someone focusing on coordination. In both cases, the project management practices should be addressed – sometimes with a role and sometimes without.
Can Agile learn anything from the PMBoK?
Yes, by addressing the barriers. Start with Agile principles and values, look at the larger value stream from the customers perspective, understand the limitations of the product owner abstraction, and creating clarity about roles and authority regarding project management practices. Use the PMBoK as a placeholder for conversation about the Knowledge Areas and the purposes behind the tasks. As the PBMoK points out. the organization and/or team should decide what is appropriate for them for each project.
Here’s a starting point for the Ball in Court discussions
The conversation is about decisions rights and levels of authority. I have listed the PMBOK knowledge areas and some potential separation of authority as a starting point. I want to be clear about my perspective on this conversation. In a doubles tennis, everyone on the same side of the net is on the same team. Sometimes, the ball is in one person’s court and sometimes it is in the others person’s court. But when playing tennis the partners play the game to help set each other up for success and may back each other up if possible. I view these authority discussions as ball in court discussions.
Additionally, this starting point is going to be wrong for your organization. But making perspectives explicit helps start the conversation. This initial view is based on a discussion on the pmiagile board that I had with Ron Jeffries. I am not claiming that Ron has endorsed this approach or these distinctions. What is important is that Ron Jeffries and Todd Little are willing to explore this line of thinking.
PMBOK Knowledge Area [potential authority]
Project Integration [development team inside development, project manager outside development]
Project Scope [product owner, project manager facilitation]
Project Time [development team]
Project Cost [product owner, project manager]
Project Quality [the development team, project manager facilitation]
Project Human Resource [project manager]
Project Communications [development team inside the team, project manager outside development]
Project Risk [product owner, development team, project manager]
Project Procurement Management [project manager]
Tags: Agile, Project Management
Dennis,
I’ve been reading, talking, presenting, discussing this topic (combination/contradiction of Agile vs. PMI/PRINCE2/V-Model…) for years, and I haven’t yet come across such a concise and wise piece of thought as you have presented here. Most publications are biased and superficial, and you obviously speak from experience.
Thank you!
Olaf
What I’ve always found problematic and perhaps highlights the different mindsets is the clash in the type of language used. The short-cut naming in each group tends to make it difficult to learn from each other which leads me to conclude that it’s important to instead focus on using plain language descriptions instead.
Olaf,
Thank you for the comment. As a manager and coach helping teams deliver software I have gained value from the PMBOK. I believe there is value in sharing our experiences and hope, as a community, we can get get to the point where we are looking at other bodies of knowledge to see how they can add to our world view – rather than fearing they may threaten our world view and looking for ways to dispute them.
Dennis Stevens
Jason,
This is an excellent point. I agree that the “clash in the type of language” puts up barriers. But shortcut naming isn’t just to create divides – it conveys a tremendous amount of context and subtle meaning.
Agile and PMBOK practitioners come from very different backgrounds. They have historically been solving different problems. The challenge is that, as we move Agile into larger teams and the problems become messier, we have to draw from both of their backgrounds.
In his conversation theory, Gordon Pask says the way we hold the other participants in the conversation, and therefore the private conversations we have about them as they as participating in the conversation, has a tremendous influence on how we understand them.
We have to start by accepting the mindsets as different and recognizing the resulting language as a potential barrier. Then we have to learn to translate and/or look beyond (maybe underneath) the clashing meaning and evolve a more robust understanding.
Dennis Stevens
Dennis, Good post, but….
There is no context…how can we have this discussion outside a particular context? You have an assumed context of “product”, but don’t mention the type of product. Would this be different in the context of a non-critical IT system built by a small, co-located team vs. the context of multi-year, 10k person, weapons defense system?
– Hank
Hank,
You are correct, context is very important. That is why I said to assume my starting point solution was wrong – regardless of your context.
I am certainly discussing software development. I am not prescribing how to do a project or “how much” Agile vs. PMBOK should be used by the team. It should be decided by the organization and the project/product team on a situation specific basis.
Personally, I believe that a multi-year, 10k person, weapons defense system would depend much more on a formal application of the knowledge areas in the PMBOK with more planning then a 5 person website would.
However, even on the 10k person project, we could draw from the Agile principles and on the 5 person website we could draw from the PMBOK when deciding the most responsible way to run the project.
My post is based on the out-of-hand rejection of the PMBOK that I have experienced in discussions with some members of the Agile community (of which I are one).
Dennis Stevens