Process Agility

From Business Agility Library
Revision as of 19:24, 12 September 2018 by Root (talk | contribs)
Jump to: navigation, search
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)[1], the related Plan-Do-Check-Act (PDCA), Six-Sigma’s Define-Measure-Analyse-Improve-Control (DMAIC)[2], Test Driven Development’s Red-Green-Refactor (RGR), and the military Observe-Orient-Decide-Act (OODA)[3] 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).



  1. The New Economics for Industry, Government, Education, Deming (1993).
  2. JURAN Institute’s Six Sigma Breakthrough and Beyond – Quality Performance Breakthrough Methods, De Feo and Barnard (2005).
  3. The Essence of Winning and Losing, Boyd, n.d.

Join the Business Agility Community

If you'd like to continue the conversation with like minded individuals around Business Agility Ways of Working, join the Business Agility slack community. Specifically the #future-of-work channel.

Business Agility Slack Community

Library Steward

This section is currently un-stewarded. If you have a passion for this space and would like to take ownership for the guidance and insights within, please contact Evan Leybourn. The stewards of the Business Agility Library are leaders in their field and we quite literally couldn't create such amazing content without their support. These people & organisations are leaders in the community and, through their actions and insights, continue to expand the horizon of business agility for us all.

This could be you!