Library Spotlight: Process Agility
The form of agility that encompases an individual value stream – the combination of discrete activities that are undertaken by teams and projects.
This is the form of agility that most people think of when they hear the term. Agile frameworks and methods to encompass multi-step, and potentially multi-team, value streams; from traditionally agile processes like software delivery or project management to business processes such as marketing campaigns, annual budgets or home loan processing. Methods such as Scrum, Kanban Method, 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).
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 tighly 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 adapation 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.
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.
- P: Plan and set the objective upfront
- D: Do, or implement, the plan
- S: Study the results, and compare against the expected results
- 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;
- Red: Create the Quality Control Tests (which, if run, would obviously fail at this stage)
- Green: Do the minimum work to pass the Quality Control Tests (until the tests turn green)
- 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:
- P: Create the Quality Control Tests
- D: Do the work
- C: Validate the outcomes against the original tests
- A: Rework, or refactor, based on the results
Existing process control loops can also complement the continuous improvement processes (e.g. Kaizen).