Process Agility

01 Introduction

Business Agility requires operations to adapt and continuously evolve as needed in service of creating value for customers.

This is the form of agility that most people think of when they hear the term. These are agile frameworks and methods to encompass multi-step, and potentially multi-team, value streams. These could include traditionally agile processes like software delivery or project management to business processes such as marketing campaigns, annual budgets or home loan processing. Frameworks and methods such as Scrum, Kanban, SAFe, LeSS, Disciplined Agile, or Lean Six Sigma are all, in large part, operating at this level (although it’s true to say that many of the more complex methods operate in the Enterprise Agility domain as well).

One key element of Process Agility is the focus on outcomes and products over outputs and projects. The governance of all decisions, processes, and work is directed towards ensuring the continuous delivery of value and business outcomes. This relationship could be described as: work must be justified based on the value it could deliver to a customer in the context of a business outcome. This enables decisions relating to the work to be entirely owned by the team.

All but the smallest of companies need common processes to ensure consistent outcomes in-line with the expectations of the organisation, board and customers. These are used to ensure that all parts of the organisation make appropriate business and financial decisions, manage outputs, and control quality processes. Organisational problems occur when these processes conflict or lose sight of the customer (our purpose). There are many causes of this including; differing priorities, fear of failure, complex or overloaded governance controls, different management values and principles, or just the historical layers of processes built upon one another from the complexities of running a complex organisation.

Processes within the context of business agility are designed to adapt over time which allows them to overcome many of these problems. What makes this work is the focus placed on tightly coupled feedback loops within every agile process. Some of these include;

• Built-in, and automatic, alignment and re-alignment of work against the customer demand and business outcomes
• Regular engagement of customers and users in the continuous design processes (e.g. Design Thinking)
• A bias to audit-based governance rather than approval-based governance.
• Regular inspection and adaptation of the process itself (e.g. the retrospective)

The final element of Process Agility is the focus on outcomes and products over outputs and projects. The governance of all decisions, processes and work, is directed towards ensuring the continuous delivery of value and business outcomes. This relationship could be described thus: work needs to be justified based on the value it could deliver to the organisation in the context of a business outcome. In many cases, this enables the accountability for all decisions relating to the work to be entirely owned by the team.

02 Moving from Theory to Practice

Your goal is to create adaptable processes that align to customer value.

Map the Value Streams
Understanding your existing processes and the impact they have on productivity is the first step towards process agility. Value Stream Mapping (VSM) is a practice that is commonly overlooked when designing new processes. VSM is the practice of defining the functional steps in common business processes, which can be anything from IT to marketing while identifying bottlenecks and wasted effort.

Adopt Agile Methods
For technology organizations and software teams, it is likely that this step has already been achieved. Agile methods, such as Scrum, have been around for more than thirty years. The challenge here is to adopt agile methods outside of software teams. Any work process that has a high level of ambiguity and low cost of change, such as a marketing campaign, is a great candidate for adopting Agile.

Move to Audit Governance
In most organizations, it is easy to create process but generally impossible to remove it. This leads to a highly complex and bureaucratic mess of processes which are disproportionate to the work risk. Appropriate low-risk work practices should move from approval-based process governance to audit-based process governance.

Approval based governance is a gate or a checkpoint. It says, “stop here, while we’ll check to make sure you can proceed”. This form of governance is appropriate in high-risk or high-cost environments, especially in situations where you cannot afford to fail (where there is a risk of death, injury, or significant financial cost).

Regular and automatic audit-based governance validates that you are doing both the right work and the work is being done right. It says, “keep going, and we’ll check in with you every couple of weeks”. This form of governance is appropriate in lower-risk or time-critical situations.

Understand Process Control Loops
Process control loops, such as Deming’s Plan-Do-Study-Act (PDSA), the related Plan-Do-Check-Act (PDCA), Six-Sigma’s Define-Measure-Analyse-Improve-Control (DMAIC), Test Driven Development’s Red-Green-Refactor (RGR), and the military Observe-Orient-Decide-Act (OODA) methods are cyclical processes to improve major decision making, through the rigorous testing of outcomes. Taking PDSA as an example, there are four key steps in the control loop; Plan, Do, Study and Act.

1. P: Plan and set the objective upfront
2. D: Do, or implement, the plan
3. S: Study the results, and compare against the expected results
4. A: Act on the results to improve the process

Business agility iterates through a PDSA cycle for any piece of work, and applies rigour to the upfront planning and quality processes. In a business agility context, it is important for organisations and teams to repeat these cycles regularly and iteratively.

Another example is Test-Driven Development’s Red, Green, Refactor control loop, where Quality Control Tests are defined upfront, prior to your teams commencing any work. Once a a piece of work is done, the original tests run against the outcomes, to verify the overall completeness and accuracy. In this context;

1. Red: Create the Quality Control Tests (which, if run, would obviously fail at this stage)
2. Green: Do the minimum work to pass the Quality Control Tests (until the tests turn green)
3. Refactor: Improve the quality of the work, to ease future enhancements and maintenance

You can also define the Red-Green-Refactor cycle as a PDCA control loop:

1. P: Create the Quality Control Tests
2. D: Do the work
3. C: Validate the outcomes against the original tests
4. A: Rework, or refactor, based on the results

Existing process control loops can also complement the continuous improvement processes (e.g. Kaizen).