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 2-1).
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.”
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 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.