Agile
Agile is a flexible, iterative approach to change originating in software development, emphasizing customer interaction, minimum viable products, and adaptation based on feedback. However, it is not suitable for all contexts, especially where prototyping is costly or compliance requires extensive documentation.
THE IDEA
Agile
Agile is a way of working that allows for a more flexible, iterative approach to change. It emerged out of adaptive IT software development and involves ensuring applications are developed in line with the following principles:8
- Interact with customers regularly and hear what they have to say;
- Create a minimum‐viable product quickly and get feedback; 9
- Be prepared to iterate what you have done, with a mindset that is happy to adapt and change focus based on a prioritised ‘backlog’.
Accountability and coordination can be made explicit through practices such as those used in Scrum:
- Defined responsibilities through roles such as the Scrum Master, Product Owner and Development Team;10
- The design of critical checkpoints – called ceremonies, such as sprint plans, daily standup meetings, sprint reviews and sprint retrospectives.
Where organisations have effectively deployed agile ways of working in IT you can sometimes see them applying this approach in other areas. This is often because of the way agile challenges the tendency to set over‐ambitious goals or to design things detached from their use. It also utilises other ways to minimise the chances of something going off track, for example:
- being clear about which tasks are a priority and keeping issue logs up to date,
- identifying key risks and difficulties on a timely basis, and
- focusing on action within a short timescale to resolve concerns.11
However, despite these strengths, agile ways of working don't work in all situations. For a machine, aircraft or production facility, a plan that depends entirely on rapid prototyping can run into costly physical constraints. That plan may assume (i) that a minimum‐viable prototype can be achieved quickly and (ii) that it won't be too costly, or time‐consuming, to make changes to your prototype.
I have seen several organisations ‘stung’ by using agile inappropriately. For example, an approach that treats pragmatism as a reason to minimize documentation or defer operational requirements can clash with (i) requirements to maintain high levels of security, (ii) the need to maintain evidence of control or compliance that a regulator might want to see, or (iii) readiness requirements that must be met before ‘going live’ (i.e. a ‘let's not worry about that now, we'll sort that out in due course’, approach). In each case, the inappropriate use of agile was identified as a causal factor in problems because it was an ‘inappropriate design’ for the task in hand, in part, because of the human tendency to ‘latch on’ to something popular and ‘on message’.12
When to use it
Developing software with uncertain requirements where rapid feedback is possible.
Managing a project that requires high regulatory compliance (e.g., healthcare, finance) — Agile may need adaptation to ensure documentation and controls are maintained.
Building a physical product (e.g., aircraft, machine) where changes are costly and sequential planning is essential.
Prioritizing tasks in a dynamic environment, such as a startup, where backlog refinement and frequent re-evaluation of priorities are critical.
FROM THEORY TO EVERYDAY LIFE
In practice
Software development with user feedback
A team building a mobile app releases a minimal feature set to early users, gathers feedback, and iterates on design and functionality in short sprints. This allows rapid adaptation to user needs and reduces the risk of building unwanted features.
Inappropriate use in construction
An organization attempts to apply pure Agile methods to build a factory. Physical construction requires detailed blueprints, sequential tasks, and costly rework—making the minimum-viable prototype approach impractical and leading to budget overruns and delays.
A MOMENT TO REFLECT
Put it to work.
Can you identify a project in your own work where Agile would be beneficial? Where might it be risky?
What factors determine whether an Agile approach is appropriate for a given domain?
How can the Agile mindset of pragmatism and minimal documentation be balanced with the need for compliance or security?
CONTINUE THE CONVERSATION
Source texts
- Beyond the Five Whys Root Cause Analysis and Systems Thinking (James C. Paterson)