Read an Excerpt
CHAPTER 1
INTRODUCTION
Welcome to the Agile Practice Guide! This guide was developed as a collaborative effort by the Project Management Institute (PMI) and Agile Alliance®. The members of the core writing team who developed this practice guide included volunteers from both organizations, drawing on subject matter expertise from a broad range of current practitioners and leaders from a diverse range of backgrounds, beliefs, and cultures.
This practice guide provides practical guidance geared toward project leaders and team members adapting to an agile approach in planning and executing projects. While our core writing team recognizes there is staunch support to use predictive approaches and conversely, passion around shifting to an agile mindset, values, and principles, this practice guide covers a practical approach to project agility. This practice guide represents a bridge to understanding the pathway from a predictive approach to an agile approach. In fact, there are similar activities between the two, such as planning, that are handled differently but occur in both environments.
Our core writing team used an agile mindset to collaborate and manage the development of this first edition of the practice guide. As technology and culture changes, future updates and refinements to the practice guide will reflect current approaches.
Our core team adopted a more informal, relaxed writing style for this practice guide than is typical for PMI standards. The guide incorporates new elements, such as tips, sidebars, and case studies to better illustrate key points and concepts. Our team intends for these changes to make this practice guide more readable and user-friendly.
This practice guide goes beyond addressing the use of agile in the computer software development industry, because agile has expanded into non-software development environments. Manufacturing, education, healthcare and other industries are becoming agile to varying degrees and this use beyond software is within the scope of this practice guide.
So why an Agile Practice Guide and why now? Project teams have used agile techniques and approaches in various forms for at least several decades. The Agile Manifesto [1] expressed definitive values and principles of agile as the use of agile gained substantial momentum (seeSection 2.1). Today, project leaders and teams find themselves in an environment disrupted by exponential advances in technology and demands from customers for more immediate delivery of value. Agile techniques and approaches effectively manage disruptive technologies. In addition, the first principle of agile places customer satisfaction as the highest priority and is key in delivering products and services that delight customers (see Section 2.1). Rapid and transparent customer feedback loops are readily available with the widespread use of social media. Therefore, in order to stay competitive and relevant, organizations can no longer be internally focused but rather need to focus outwardly to the customer experience.
Disruptive technologies are rapidly changing the playing field by decreasing the barriers to entry. More mature organizations are increasingly prone to being highly complex and potentially slow to innovate, and lag behind in delivering new solutions to their customers. These organizations find themselves competing with smaller organizations and startups that are able to rapidly produce products that fit customer needs. This speed of change will continue to drive large organizations to adopt an agile mindset in order to stay competitive and keep their existing market share.
The Agile Practice Guide is project-focused and addresses project life cycle selection, implementing agile, and organizational considerations for agile projects. Organizational change management (OCM) is essential for implementing or transforming practices but, since OCM is a discipline within itself, it is outside the scope of this practice guide. Those seeking guidance in OCM may refer to Managing Change in Organizations — A Practice Guide [2].
Additional items that are in scope and out of scope for this practice guide are listed in Table 1-1.
This practice guide is for project teams who find themselves in the messy middle-ground between predictive and agile approaches, who are trying to address rapid innovation and complexity, and who are dedicated to the team's improvement. This practice guide provides useful guidance for successful projects that deliver business value to meet customer expectations and needs.
This practice guide is organized as follows:
Section 2 An Introduction to Agile — This section includes the Agile Manifesto mindset, values, and principles. It also covers the concepts of definable and high-uncertainty work, and the correlation between lean, the Kanban Method, and agile approaches.
Section 3 Life Cycle Selection — This section introduces the various life cycles discussed in this practice guide. This section also addresses suitability filters, tailoring guidelines, and common combinations of approaches.
Section 4 Implementing Agile: Creating an Agile Environment — This section discusses critical factors to consider when creating an agile environment such as servant leadership and team composition.
Section 5 Implementing Agile: Delivering in an Agile Environment — This section includes information on how to organize teams and common practices teams can use for delivering value on a regular basis. It provides examples of empirical measurements for teams and for reporting status.
Section 6 Organizational Considerations for Project Agility — This section explores organizational factors that impact the use of agile approaches, such as culture, readiness, business practices, and the role of a PMO.
Section 7 A Call to Action — The call to action requests input for continuous improvement of this practice guide.
The annexes, appendixes, references, bibliography, and glossary provide additional useful information and definitions:
* Annexes. Contain mandatory information that is too lengthy for inclusion in the main body of the practice guide.
* Appendixes. Contain nonmandatory information that supplements the main body of this practice guide.
* References. Identify where to locate standards and other publications that are cited in this practice guide.
* Bibliography. Lists additional publications by section that provide detailed information on topics covered in this practice guide.
* Glossary. Presents a list of terms and their definitions that are used in this practice guide.
CHAPTER 2
AN INTRODUCTION TO AGILE
2.1 DEFINABLE WORK VS. HIGH-UNCERTAINTY WORK
Project work ranges from definable work to high-uncertainty work. Definable work projects are characterized by clear procedures that have proved successful on similar projects in the past. The production of a car, electrical appliance, or home after the design is complete are examples of definable work. The production domain and processes involved are usually well understood and there are typically low levels of execution uncertainty and risk.
New design, problem solving, and not-done-before work is exploratory. It requires subject matter experts to collaborate and solve problems to create a solution. Examples of people encountering high-uncertainty work include software systems engineers, product designers, doctors, teachers, lawyers, and many problem-solving engineers. As more definable work is automated, project teams are undertaking more high-uncertainty work projects that require the techniques described in this practice guide.
High-uncertainty projects have high rates of change, complexity, and risk. These characteristics can present problems for traditional predictive approaches that aim to determine the bulk of the requirements upfront and control changes through a change request process. Instead, agile approaches were created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback.
2.2 THE AGILE MANIFESTO AND MINDSET
Thought leaders in the software industry formalized the agile movement in 2001 with the publication of the Manifesto for Agile Software Development (see Figure 21).
Twelve clarifying principles flowed from these values as shown in Figure 2-2.
Although originating in the software industry, these principles have since spread to many other industries.
This embodiment of mindset, values, and principles defines what constitutes an agile approach. The various agile approaches in use today share common roots with the agile mindset, value, and principles. This relationship is shown in Figure 2-3.
As shown in Figure 2-3, the model, inspired by Ahmed Sidky, articulates agile as a mindset defined by the Agile Manifesto values, guided by the Agile Manifesto principles, and enabled by various practices. It is worth noting that while the term "agile" became popularized after the Manifesto, the approaches and techniques being used by project teams today existed before the Agile Manifesto by many years and, in some cases, decades.
Agile approaches and agile methods are umbrella terms that cover a variety of frameworks and methods. Figure 2-4 places agile in context and visualizes it as a blanket term, referring to any kind of approach, technique, framework, method, or practice that fulfills the values and principles of the Agile Manifesto. Figure 2-4 also shows agile and the Kanban Method as subsets of lean. This is because they are named instances of lean thinking that share lean concepts such as: "focus on value," "small batch sizes," and "elimination of waste."
Is agile an approach, a method, a practice, a technique, or a framework? Any or all of these terms could apply depending on the situation. This practice guide, uses the term "approach" unless one of the other terms is obviously more correct.
In general, there are two strategies to fulfill agile values and principles. The first is to adopt a formal agile approach, intentionally designed and proven to achieve desired results. Then take time to learn and understand the agile approaches before changing or tailoring them. Premature and haphazard tailoring can minimize the effects of the approach and thus limit benefits. (See Appendix X2 for Tailoring Considerations).
The second strategy is to implement changes to project practices in a manner that fits the project context to achieve progress on a core value or principle. Use timeboxes to create features, or specific techniques to iteratively refine features. Consider dividing up one large project into several releases, if that works for the specific project context. Implement changes that will help the project succeed — the changes do not need to be part of the organization's formal practices. The end goal is not to be agile for its own sake, but rather to deliver a continuous flow of value to customers and achieve better business outcomes.
2.3 LEAN AND THE KANBAN METHOD
One way to think about the relationship between lean, agile, and the Kanban Method is to consider agile and the Kanban Method as descendants of lean thinking. In other words, lean thinking is a superset, sharing attributes with agile and Kanban.
This shared heritage is very similar and focuses on delivering value, respect for people, minimizing waste, being transparent, adapting to change, and continuously improving. Project teams sometimes find it useful to blend various methods — whatever works for the organization or team is what should be done regardless of its origin. The objective is the best outcome regardless of the approach used.
The Kanban Method is inspired by the original lean-manufacturing system and used specifically for knowledge work. It emerged in the mid-2000s as an alternative to the agile methods that were prevalent at the time.
The Kanban Method is less prescriptive than some agile approaches and less disruptive, as it is the original "start-where-you-are" approach. Project teams can begin applying the Kanban Method with relative ease and progress toward other agile approaches if that is what they deem necessary or appropriate. For more details on the Kanban Method, see Annex A3 on Overview of Agile and Lean Frameworks.
CASE
There is and probably always will be a lot of discussion around the Kanban Method and whether it belongs to the lean or agile movement. It was conceived in and around lean manufacturing, but is widely used in agile settings.
2.4 UNCERTAINTY, RISK, AND LIFE CYCLE SELECTION
Some projects have considerable uncertainty around project requirements and how to fulfill those requirements using current knowledge and technology. These uncertainties can contribute to high rates of change and project complexity. These characteristics are illustrated in Figure 2-5.
As project uncertainty increases, so too does the risk of rework and the need to use a different approach. To mitigate the impact of these risks, teams select life cycles that allow them to tackle projects with high amounts of uncertainty via small increments of work.
Teams can verify their work when they use small increments and can change what they do next. When teams deliver small increments, they are better able to understand the true customer requirements faster and more accurately than with a static written specification.
Teams can plan and manage projects with clear and stable requirements and clear technical challenges with little difficulty. However, as the uncertainty in the project increases, the likelihood of changes, wasted work, and rework also increases, which is costly and time consuming.
Some teams have evolved project life cycles to use iterative and incremental approaches. Many teams discover that when they explore the requirements iteratively and deliver more often incrementally, the teams adapt to changes more easily. These iterative and incremental approaches reduce waste and rework because the teams gain feedback. These approaches use:
* Very short feedback loops,
* Frequent adaptation of process,
* Reprioritization,
* Regularly updated plans, and
* Frequent delivery.
TIP
What do simple, complicated, and complex projects mean? Consider large projects, such as the Boston Big Dig construction project. On the surface, the project seemed fairly straightforward: move the elevated highway underground. There was high agreement on the requirements (see the Y axis in Figure 2-5). There was low uncertainty on how the project would proceed until the project started. And, as is the case for many large projects, the project encountered surprises along the way.
When a team works on a project where there is little opportunity for interim deliverables or little opportunity for prototyping, the team most likely will use a predictive life cycle to manage it. The team can adapt to what it discovers, but will not be able to use agile approaches to manage the iterative discovery of requirements or incremental deliverables for feedback.
The Big Dig project was not simple by any means. However, many projects that start out in the lower left part of the Stacey Complexity Model have no real means of moving to other approaches. Assess the project, both in the requirements and the means of delivery, to determine the best approach for the life cycle of the project.
These iterative, incremental, and agile approaches work well for projects that involve new or novel tools, techniques, materials, or application domains. (Refer involve new or novel tools, techniques, materials, or application domains. (Refer to Section 3 on Life Cycle Selection). They also work well for projects that:
* Require research and development;
* Have high rates of change;
* Have unclear or unknown requirements, uncertainty, or risk; or
* Have a final goal that is hard to describe.
By building a small increment and then testing and reviewing it, the team can explore uncertainty at a low cost in a short time, reduce risk, and maximize business value delivery. This uncertainty may be centered on suitability and requirements (is the right product being built?); technical feasibility and performance (can this product be built this way?); or process and people (is this an effective way for the team to work?). All three of these characteristics — product specification, production capability, and process suitability — typically have elements of high uncertainty.
However, iterative and incremental approaches have their limits of applicability. When both technology uncertainty and requirements uncertainty are very high (the top right of Figure 2-5), the project moves beyond complex to chaotic. In order for the project to become reliably possible, it needs one of the variables (uncertainty or disagreement) to be contained.
(Continues…)
Excerpted from "Agile Practice Guide"
by .
Copyright © 2017 Project Management Institute, Inc..
Excerpted by permission of Project Management Institute, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
