This blog is a conversation between the Agile Practice Guide Team and our PMI and Agile Alliance Communities to gain insight, support and collaboration around the creation of a usable and relevant body of work that supports transition to hybrid and agile in project work.
For the past year, we have shared with you that the Agile Practice Guide being jointly developed by volunteers from Agile Alliance® and Project Management Institute (PMI) was coming. Both organizations have officially announced that the Practice Guide is available for no-charge download for their members from their respective web sites. In fact, PMI has bundled the Agile Practice Guide with the release of the PMBOK® Guide – Sixth Edition. The bundled publications provide practitioners with good practices for managing projects across the full spectrum of project life cycles.
Some stakeholders have shared early feedback on the Practice Guide. One reviewer conceded the Practice Guide was a step in the right direction, and followed with specific critiques and suggestions to improve it. Another user shared that his organization used the Agile Suitability Filter Tool in the Practice Guide to have a frank conversation with a client about the best approach for managing the contracted project. As you know, customer feedback is critical for enhanced development and value delivery, so please don’t be shy – tell us what you think!
You can post your stories, reactions or questions here at this blog. If you do not want to share information publicly, please feel free to write to me at [email protected]. My colleague Karl Best and I are collecting feedback, stories and additional information to share with a future Practice Guide update team.
And don’t forget that Practice Guide team members will be at several upcoming events where you can network with them in person, including:
Agile practice Guide is a valuable addition to PMBOK. It does cover all leading Agile approaches being used. It also defines suitability factors for changeover from traditional to agile approach on projects and it describes agile beyond software development industry.
A valuable addition and a lot of hard work put in by those who were involved in its development.
I've reviewed both & I think the ideas reflect the needs of the project environment. I used a hybrid approach on one of my projects this summer & most of the concepts I used were included in the agile practice guide (AGP).
I've done significant research regarding agile methods over the last 4 years, and the APG reflects a good summary of that research.
I just finished my read. It is a very well Structured and comprehensive description.
I love the undogmatic view and the demonstrations of the poosibilities to combine classic and agile approaches to leverage the respective advantages for your specific Situation.
In a Compliance Project context I made good experience in the usage of a rough classic planning approach to ensure and control the delivery of the end product within the given deadline. To optimize the flow of work I put the initial set of tasks in a backlog, set a timebox, use Kanban and daily SCRUM. The team was mixed with internals and consultans. Hence it is a good possibility to enhance the collaboration with externals.
I am interested to contribute to the next increment.
I have a question regarding the Project Life Cycles (3.1 page 18), about the Iterative and Incremental Approach, where do these two approaches coming from? I always think agile is iterative and it delivers incremental? It's weird that Iterative and Incremental means two different approaches.
Also in Scrum Guide, it says: Scrum Teams deliver products iteratively and incrementally. I am not saying Scrum = Agile, but I am curious to know the reason why Iterative and Incremental are considered two different approaches?
Thanks for your question and comment. Your question is one that I frequently hear related to the distinctions between predictive, iterative, incremental and agile.
Let me start by emphasizing that the Agile Practice Guide team struggled with the same issue because words like agile, iterative and incremental can mean different things to different people. So the Practice Guide team tried to standardize use of terms in the Practice Guide to make important distinctions. For example, Figure 3.1 reflects characteristics of project life cycles, rather than management approaches. Life cycles reflect the series of phases a project passes through from its start to its completion (PMBOK® Guide – Sixth Edition glossary definition). Along the project life cycle continuum, there are four identified life cycles: waterfall/predictive, iterative, incremental and agile. In the context of the Agile Practice Guide, management approaches and frameworks, such as Scrum, Kanban or SAFe, represent specific methods for delivering results or tools for managing collaborative work. Some management approaches and frameworks may incorporate iterations or increments to produce results.
The concepts of life cycles and management approaches come together as the project team focuses on tailoring the management approach to the unique characteristics of the project and its life cycle. Some life cycles are more predictive in nature in that requirements and risks are largely known, and the organization has experience in successfully delivering similar types of projects. In such situations, project teams may choose to use a more waterfall management approach. Projects that are more dynamic introduce more unknowns and risks which affect their life cycles. For example, a product development life cycle may have some known elements, surface some manageable risks in some areas and appear similar to other successfully completed projects. But parts of the same project may be more dynamic because the technology is evolving, the customer needs to see versions of the product to ensure it meets specific needs, etc. In this instance, the project life cycle may be more iterative or incremental, and might be best managed with a combination of waterfall, iterative, incremental or agile approaches (e.g., iterative development cycles linked with review gates; increments developed individually and then integrated together in a more linear process during the final phase ). When the entire project is dynamic and the customer needs to receive value sooner, the project may have more of an agile life cycle. For example, an organization experiencing a social media crisis has to quickly shift and adapt its messaging based on how its audience responds to its messaging versus counter-messaging. Message development, decision cycles and message deployment have to react very quickly to rapidly changing audience reactions, so more agile approaches may be necessary within this life cycle context.
I hope that this information helps to clarify the distinction between life cycles and management approaches in the context of the Agile Practice Guide.
Thanks so much for such detail explanation, really appreciate your time and effort.
As I mentioned with my email to you, I am helping the PMI Taiwan Chapter to translate the English version into traditional Chinese version, there are several questions from the team and I want to make sure I understand the reason behind it so that we can do a good job on the translation.
Although it's not totally related, maybe we can incorporate Cynefin framework in the next version, as Jeff and Ken mentioned in the Scrum Guide that: Scrum is a process framework that has been used to manage work on complex products.
Waterfall seems to be in the "Simple" domain, Scrum is in the "Complex" domain. Use Kanban for "Complicated" domain, and I don't know if there is any framework is designed for "Chaotic" domain. (If anyone knows, please share, thanks.)
Happy to say that this practice guide is better than I expected. At first, I was surprised by it’s "condensed" size but after a first review I found: Enough rigor and coherence as one would expect from a PMI document and the flexibility and open-mind I would expect from something endorsed by the Agile Alliance. Kudos guys! #AgilePracticeGuide
Luis - Thanks for the feedback on the Agile Practice Guide. I am glad that you find the content useful and informative. If you think of ways in which we can enhance the content or add new content areas, please let us know.
I can think of several ways: 1. use the same or similar language as the PMBOK to make it sound more professional and consistent. 2. must have a scaling section. 3. more on assisting the organization in accepting, transitioning and maintaining Agile best practices. 4. more on hybrids (especially with waterfall as this is more prevalent than people think). 5. a section that steps away from the team and practitioner, and looks at how senior management and the customer (not product owner) has a role to play in Agile success or failure.
I only just read the guide just now from cover to cover for the first time, and these are my first impressions of what's needed in the next guide. I have applied for a PhD and plan to include Agile as part of the methodology in my dissertation topic. That would depend on how the practice guide evolves and in what direction it takes. PMI has an opportunity for the guide to be the best source on the planet, or diverge away from best practices. At the moment, the guide has a ways to go. The fact that I just passed my PMI-ACP two days ago without reading a word of the practice guide says a lot. Happy to assist where I can.
Great feedback, Sante. Thank you for sharing these inputs with us.
To your point about scaling, I would be interested to learn about the experiences you and others in the community are having with scaling frameworks. What works well? Where do you see gaps and how are you filling those gaps? To what extent do you customize the frameworks to your organizational environment? What are the business system changes required to effectively enable scaled agile?