PMI and Agile Alliance have joined forces to create an Agile Practice Guide, with the intention to to create a greater understanding of agile practices, with emphasis on how agile relates to the project management community. Although that is a very clear charter, it’s also very broad, likely leaving many people wondering, “What will they actually cover in this guide?” This blog post intends to offer a preview of what readers can expect to find in the Agile Practice Guide.
We describe the Agile Mindset
To set the right context, we begin by introducing the Agile Manifesto mindset, values, and principles. The opening also covers the concepts of definable and high-uncertainty work, and the correlation between lean, Kanban method and agile approaches.
We perform a deep analysis of Life Cycle Selection
For Project Managers, the most visible aspect of Agile approaches is arguably the delivery life cycle. Various lifecycles are discussed in the guide, along with suitability filters, tailoring guidelines and common combinations of approaches. This topic is intended to show what is and is not Agile delivery, and how to be more thoughtful for when it’s well suited.
We give a few suggestions for Creating an Agile Environment
There are several critical factors to consider when creating an Agile Environment such as servant leadership and team composition. We explore those factors in depth.
We also offer recommendations for Delivering in an Agile Environment
It is our goal to help you learn how to organize your team, and equip them with common for delivering value on a regular basis. We provide examples of empirical measurements for the team and for reporting status.
We then explore Organizational Considerations for Project Agility
Every project is influenced strongly by the context of the organization. This guide explores organizational factors that impact the use of agile practices, such as culture, readiness, business practices, and the role of a PMO.
We close by issuing A Call to Action
The content listed here describes the substance of what our team pulled into the Guide. With such a broad field to cover, we did our best to find the most important concepts and techniques to help project practitioners shift to an agile way of working. That being said, we knew from the beginning this guide would not be perfect. In that spirit, we close the main body of the guide with a call to action requesting your input for the continuous improvement of the practice guide.
The guide has a bit more to cover. Essential information that is too bulky and would disrupt the flow of the story is located in three annexes following the main text.
We outline a PMBOK® Guide Mapping
To help those formally trained in project management transition to an agile mindset, we constructed a mapping of agile concepts to the Project Management Process Groups and Knowledge Areas defined in the PMBOK® Guide, Sixth Edition. The mapping describes how hybrid and agile approaches address the attributes described in the PMBOK® Guide Knowledge Areas. It covers what stays the same and what may be different along with some guidelines to consider for increasing the likelihood of success.
We also provide an Agile Manifesto Mapping
Conversely, it made sense to Indicate where the four value statements of the Agile Manifesto and the twelve underlying principles are covered in the Agile Practice Guide.
We list an Overview of Agile and Lean Frameworks
In order to illustrate the many ways to be agile, the guide Describes some of the most commonly used agile approaches, such as Scrum, eXtreme Programming (XP), Kanban, Scrumban, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Agile Unified Process (AUP), Scrum of Scrums, Scaled Agile Framework, Large Scale Scrum, Enterprise Scrum and Disciplined Agile.
Further useful information that supplements the main body of the practice guide is captured in three appendices.
Appendix X1 - Contributors and Reviewers
This lists the people that have created and improved the practice guide.
Appendix X2 - Attributes that Influence Tailoring
This appendix provides high-level guidance on when and how to tailor agile approaches. It can be used to determine circumstances that might warrant changing or introducing new techniques, and then offers some recommendations to consider.
Appendix X3 - Agile Suitability Filter Tools
Proposes a model for assessing the suitability of agile, hybrid and predictive approaches. It is intended to help people find the sweet-spot for their current initiative.
Concluding the document are references, bibliography and a glossary. The references section lists the standards and other formal foundational publications cited.
The bibliography is categorised by practice guide section, indicating additional knowledge assets that provide detailed information on topics covered in this practice guide. Here you’ll find pointers to books, blogs, videos, graphics and other useful guidance that you may wish to consider for further study.
The glossary is a list of terms and their definitions as used in this practice guide that are specific to the agile mindset. Refer to the glossary whenever you’re unsure of how a term may be used.
What do you think?
We look forward to your views and insights. Please share them in the comments, and we’ll make sure they are considered in the list of improvements for future versions of the practice guide.
Agile Alliance and Project Management Institute (PMI) are about to initiate a major launch later this year – the Agile Practice Guide. Our joint development team has spent seven of the anticipated nine months writing so far. These are exciting times with a little bit of anxiety creeping in from time to time.
Doing something as bold as bridging a divide between two communities carries elements of risk. What if neither community likes what we have produced? What if we do not meet expectations of what people envision an Agile Practice Guide should be or contain? What if this “Big Thing” we have done falls completely flat?
There are many “what if” scenarios like this that we could play out in our minds. It is sometimes very challenging for us to stay focused on our mission because these “what ifs” interrupt our thinking as we try to complete our work.
But eventually our “what if” questions have given way to “how cool” thinking. How cool will it be when the Agile Practice Guide helps a team spread its agile mindset across an organization? How cool will it be when organizations use content in the Agile Practice Guide to accelerate value delivery to customers? How cool will it be when folks from the Agile Alliance, PMI and other communities start sharing their learning and experiences with each other because they were inspired by our collaboration on this project?
So as we prepare for the launch of the Agile Practice Guide later this year, how cool will it be when you come talk with our team about our experiences in developing the guide and what you thought about it?
Over the coming months, our team members are planning to be at the following events where you can connect with us:
We hope that you will come chat with team members about the project and the journey that you, your team and your organization are on. Let’s use these opportunities as a launching pad to demonstrate the power of individual passion and engagement; the acceleration of value delivery through teamwork; and a vision and mindset that can take people and their organizations to completely new heights.
This post discusses the development of the new Agile Practice Guide and it’s fit, alignment and potential conflicts with other PMI standards documents including the upcoming PMBOK® Guide – Sixth Edition.
Why Care About Alignment?
Alignment between PMI practice guides and standards is important. People look to these documents not only for guidance on how to undertake work, but also as definitions of terms and often the basis for their own corporate standards. So, it is not a good situation when one PMI document defines a term, like “a Sprint”, as one thing and then a later guide defines it slightly differently. Likewise, recommended approaches should be aligned too. We don’t want one guide recommending the goal of setting a vision to be “X” and another guide saying it is “Y”. To help avoid these situations, the PMI maintains three sets of standards and a unifying lexicon document.
How PMI Standards Fit Together
First there are “Foundational Standards”, like the well know PMBOK® Guide, but also including standards for program and portfolio management. Since the PMI is an ANSI accredited standards developer, the development process for these documents is very rigorous, for a description of the steps involved see this description for the PMI website.
One step down in terms of development rigor are “Practice Standards”. These describe the use of a tool, technique or process identified in the PMBOK® Guide or other foundational standards. Examples include the “Practice Standard for Scheduling” and the “Practice Standard for Project Estimating”. When developing recommendations and guidance for agile approaches we need to explain where they deviate from these established Practice Standards.
Lastly, there are “Practice Guides” that provide supporting information and instruction. Practice guides may become potential standards and if so, would undergo the process for development of full consensus standards. Terms used in all three levels of documents are defined in a single, unifying “Lexicon of Terms”. Definitions in the Lexicon were developed by volunteer experts, and PMI standards committees are chartered to use the Lexicon terms without modification.
Where the Agile Practice Guide Fits In
The Agile Practice Guide currently under development fits into the third category of “practice guide”. It was generally agreed that any kind of “standard for agile” would simply not make sense. Any formal document on agile methods should be descriptive, not prescriptive. Nevertheless, it is still peer reviewed and must define and use terms in accordance with the PMI Lexicon.
A challenge in creating the guide was to describe the application of the agile mindset and values in a project setting that has terms and definitions sometimes different from those already defined in the existing PMI standards and lexicon. Often the principles and practices used in agile approaches differ from those recommended in a classical plan-driven approach. So, when the PMI wanted to create an Agile Practice Guide it was aware there was the potential for issues with its existing standards offerings.
A Benefit of Planning for a Living
The PMI knew their newly commissioned Agile Practice Guide would likely to clash terms and definitions with existing standards like the “Business Analysis Practice Guide” and the PMBOK® Guide., Therefore, to minimize that conflict, they engaged participants from the Agile Practice Guide team to first write introductions to each of the Knowledge Areas for the upcoming PMBOK® Guide – Sixth Edition. These introductions describe adaptation and tailoring considerations for agile, iterative, and adaptive environments. They help align PMBOK® Guide – Sixth Edition – due out in Q3 2017 with the Agile Practice Guide, also synchronized with the same release date.
In addition to new Knowledge Area introductions, the PMBOK® Guide – Sixth Edition has a new appendix for agile, iterative, adaptive and hybrid project environments. Written by the same subset of Agile Practice Guide authors, the appendix explores the nuances of how the project management process groups described in The Standard for Project Management are performed with respect to a variety of project environments and life cycles.
So, by first getting this subset of the Agile Practice Guide authors to write the agile related components of the next edition of the PMBOK® Guide they hopefully reduced the potential for conflict and misalignment. Using the same people to develop both documents reduces interpretation differences, but there are still some unavoidable industry conflicts.
Planning Helps but Reality Does Not Care
Agile approaches were developed as a deliberate response to the issues associated with using plan-driven approaches in highly volatile environments. As such plan-driven definition and terms were not generally consulted or adhered to. In some instances, agile protagonists wanted to purposely distance themselves from the established status quo.
For example, “earned value“ is in the eye of the beholder. In the PMI Lexicon it is defined as “The measure of work performed expressed in terms of the budget authorized for that work.” Yet, in the agile community it is more usually known as “the value of the benefits delivered” - quite separate from the budget authorized for that work.
Another challenge is explaining when and why the recommended approaches between plan-driven guidance and agile approaches seem to differ. Take defining scope and developing specifications for example. Plan driven approaches work from the perspective that the most efficient approach is defined as much as possible upfront, get agreement this is what is required and then start executing towards this agreement of scope.
Agile approaches work from the perspective that unsurfaced complexities and uncertainties will prevent a near complete specification of work being discovered near the start of the project. So, instead of attempting to prematurely define a specification that will then frequently change, it is more time and cost efficient to build some small increments of product and iterate to the final required design from there.
These are very different approaches to scoping and execution. Each makes sense in its own context and, as always, there is potential for combining elements of each into a hybrid, third alternative. The Agile Practice Guide needs to respect both approaches and offer actionable guidance to practitioners faced with these circumstances so they can make informed decisions.
Our work in developing the Agile Practice Guide so far has raised some great topics for discussion. Hopefully, this post has introduced some of the issues associated with alignment with existing PMI standards. Future blog posts will cover planning-and-process mindsets vs uncertainty-and-people based mindsets and other topics of alignment.
I've been a project manager/program manager and have taught project management and program management since 1992. I have the gray hair to prove it.
One of my secret tools was timeboxing. Oh, it wasn't such a secret, because I asked people to timebox their work. I timeboxed my work. I taught about timeboxing. I found that limiting the time that people worked on a task helped them focus.
I am not talking about hacking 20% off a schedule for people to feel "pressure." I've never found that to be useful. But using timeboxes? Wow, so useful for me.
Here's how I have used timeboxes:
You'll notice I haven't said anything about "agile" here. Agile uses timeboxes for many things, including my examples.
When a team doesn't know how to start, they do a spike. The entire team learns together, for anywhere from an hour to a day. The team decides on their timebox and understands what the rest of the deliverables are by the end of the timebox.
Many teams use two-week iterations as their team cadence. They have a rhythm for demonstrations and retrospectives. They do exactly what I do: reflect and use their current data for planning the next chunk of work.
I prefer that teams work on only one project during an iteration. For many teams, this is impossible. In that case, I ask the Product Owner to make sure the features are small, so the team can see the flow of work (that they make progress all the time) and that they manage the interruptions.
Timeboxes are not new to agile. They are an old project management "trick" or tip.
If you find yourself under pressure, consider your deliverables. What can you focus on now--and not interrupt yourself for a short time--to then deliver? You have found the secret: deliverables in short timeboxes.
Regardless of your project approach, consider timeboxes in some way. You don't have to be agile to use them. And, if you are agile, maybe explain how you use timeboxes. Maybe I can learn from you!
Now that the agile movement has expanded to larger organizations in more industries, we’re seeing a lot of variation. Granted, we’re used to a variety frameworks, techniques, and methods in use, from XP to Scrum to Kanban to Continuous Delivery. However, lately we’re hearing more and more about the use of “Hybrid” approaches.
Maybe you’ve heard an executive say “we’re not agile yet, but we’re using a hybrid approach”. Or maybe you’ve heard some consultant proudly declare “unless you do lots of prototyping, you’re only hybrid agile”. And then at the meetup you hear another person say “Oh, we’re not hybrid, we use a blended approach”.
With all this chatter, it can get pretty confusing as to what people actually mean. Those of us working on the upcoming Agile Practice Guide have heard this chatter too, and we’re adding a dedicated section to the guide focused on this topic. Here are some of the initial patterns we’re seeing...
“Iterative” vs. “Incremental” vs. “Agile"
Project lifecycles live on a continuum, ranging from Plan-Driven on one end to Agile on the other end. To help us understand this continuum, let’s say two of the key aspects of agility are “Deliver Early and Often” and “Adapt to Change”. If we were to plot that on a two-dimensional graph, we would get something like this…
On the continuum from Plan-Driven approaches (lower-left) to Agile approaches (upper-right) there are different degrees of delivery (incremental) and degrees of change (iterative). Those techniques that achieve BOTH high degrees of delivery AND high degrees of adaptability are called “Agile”.
“Blended” versus “Hybrid”
But that’s just too simplistic. In the real world, we don’t just use one approach; we almost always combine different techniques together. To help us understand the different combinations, we’ve settled on some working definitions.
Blended Agile is the combination of two or more established agile methods, techniques, or frameworks.
That is, adding some Kanban and wip limits to your Sprints would be a “Blended” approach. Or maybe you want to “blend” an information radiator with your continuous delivery status. For many of agile practitioners, that’s easy to understand. We combine known adaptive-aggressive techniques to be better at what we do:
Blended = agile + agile = better agile.
But what about the rest of us who are mere mortals? What if we’re not able to use these various techniques just yet? What if there are either constraints or demands that require some non-agile elements to happen? Well, in those cases, you should consider the “Hybrid”:
Hybrid Agile is the combination of agile methods with other non-agile techniques
For example, a detailed requirements effort, followed by sprints of incremental delivery would be a “Hybrid Approach”. Likewise, frequent iterative prototyping of a design, followed by a single plan-driven implementation would be a “Hybrid Approach”. Here, the idea is to take a non-Agile approach and inject some Agile techniques to address a specific issue or opportunity:
Hybrid = non-Agile + Agile = something in between that makes sense
When should we use Hybrid approaches?
Just like anything else in the world, there is a right reason and a wrong reason to do something. To be clear, the wrong reason for mixing techniques together is to keep up with the Joneses. “Doing agile techniques” is not the goal. The goal is to deliver the right business outcome using the right techniques.
Here are two scenarios.
Every project has different needs. For those finding themselves in a mostly plan-driven environment, a hybrid approach can be a transition to more adaptability and delivery. For those already delivering and adapting aggressively, blending in some new techniques can raise your bar even higher.
Don’t simply declare “we’re Agile”; the reality is you’re almost always using some combination of different techniques already. Instead, a better strategy would be to stop and think which approaches would be the best for where we are, and what we want to achieve.