AGILE – Definable Work verses 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 agile techniques.
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.
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:
We are uncovering better ways of developing systems by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions – over processes and tools
Working software – over comprehensive documentation
Customer collaboration – over contract negotiation
Responding to change – over following a plan
That is, while there is value in the items on the right, we value more the items on the left
The 12 Agile Principles
Twelve clarifying Principles flow from these values as shown below:
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 below:
This model demonstrates 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 in context
Agile approaches and agile methods are umbrella terms that cover a variety of frameworks and methods.
The diagram below 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.
This model 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. I would use the term “approach” unless one of the other terms is obviously more correct.
The formal agile approach
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.
Fitting agile to a project context
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.
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.
Kanban – “start-where-you-are”
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.