2.2 Being Agile vs Doing Agile, and the Benefits of Both
Key Takeaways
- 'Being agile' is about adopting a mindset of flexibility, values and behaviours; 'doing agile' is about following specific agile processes, practices and techniques.
- Version 2 of PRINCE2 Agile makes the being/doing distinction a headline concept — the Foundation module is described as covering what you need to BE agile and DO agile.
- Doing agile without being agile produces agile theatre: the ceremonies run but the outcomes do not change.
- Being agile without doing agile produces good intentions with no delivery discipline, cadence or transparency.
- A named benefit of combining being and doing agile is organizational resilience and alignment.
2.2 Being Agile vs Doing Agile, and the Benefits of Both
Quick summary: 'Being agile' is about adopting a mindset of flexibility; 'doing agile' focuses on following specific agile processes and techniques. Version 2 of PRINCE2 Agile elevates this distinction to a headline theme — the official Foundation description says the module covers everything needed to BE agile, and DO agile. Both are required; either alone fails.
The two halves
This is one of the highest-yield definitions on the paper, and the exam tests it by inverting it. Learn the direction of the sentence, not just the words.
| Being agile | Doing agile | |
|---|---|---|
| What it is | A mindset of flexibility, and the values and behaviours that follow from it | Following specific agile processes, practices and techniques |
| Where it lives | Inside people: how they think, decide and treat each other | In the working system: events, artifacts, boards, cadences |
| Examples | Trust, empowerment, transparency, willingness to be wrong, psychological safety | Stand-ups, iterations, backlog refinement, burn charts, Definition of Done, WIP limits |
| How you observe it | How the team behaves when something goes wrong | Whether the ceremonies happen and the artifacts exist |
| How it is acquired | Coaching, leadership modelling, culture change — slow | Training and process adoption — comparatively fast |
If an exam option says "'Being agile' focuses on following specific agile processes, while 'doing agile' is about adopting a mindset of flexibility", it is the correct statement reversed. Being = mindset. Doing = processes.
Why doing agile alone fails
An organization that only does agile installs the visible machinery and keeps the old behaviour:
- The stand-up becomes a status report delivered to a manager, rather than the team coordinating with itself.
- The retrospective produces a list of actions that nobody is empowered to implement, so the same problems reappear every fortnight.
- The backlog is a requirements specification with a new name, fixed at the start and defended against change.
- Velocity becomes a productivity target imposed from above, so teams inflate estimates and stop telling the truth.
- Self-management is announced but every decision still escalates.
The mechanics are all present and the outcomes are unchanged. This is the practical content of the misconception that a framework alone delivers benefits.
Why being agile alone fails
The opposite failure is less discussed but just as real. A team with an excellent mindset and no discipline has:
- No cadence, so there is no rhythm of inspection and adaptation.
- No transparency artifacts, so the project board cannot see progress and reverts to demanding reports.
- No Definition of Done, so "finished" work returns weeks later as defects.
- No prioritized backlog, so the team works on whatever is loudest.
Good intentions without practices produce enthusiasm and unpredictability. Governance cannot function on that, which is precisely why PRINCE2 Agile insists on both halves.
The benefits of being and doing agile
PRINCE2 Agile identifies benefits that accrue when the mindset and the practices are present together. The one to memorise, because it is the sort of phrase that appears verbatim as a correct option, is organizational resilience and alignment.
Others that follow from the combination:
- Earlier and more frequent value. Incremental release means benefits start accruing before the project ends.
- Reduced risk of large-scale failure. Short feedback loops surface wrong assumptions while they are still cheap to correct.
- Higher engagement and retention. Empowered teams that own their commitments stay.
- Better quality. Testing continuously and holding a Definition of Done prevents the quality collapse that comes from a compressed test phase.
- Alignment between strategy and delivery. Frequent, visible increments let leaders steer with evidence rather than forecasts.
Note what is not on the list. "Tightly defined controls among specialist teams" is the opposite of agile organization — agile favours cross-functional teams over specialist silos. "Quality checks at later development stages" describes the sequential model agile is designed to replace. "Focus on time and cost" is far too narrow; agile focuses on value and outcomes, of which time and cost are two constraints among the seven performance targets.
Getting the balance right
In practice, organizations start by doing agile because it is tangible, and then discover that the returns stall until the mindset shifts. The sequencing is not wrong — practices can be a scaffold for behaviour, and a well-run retrospective is one of the most effective ways to build the mindset. What is wrong is stopping at the practices and declaring the transformation complete.
The diagnostic question is simple: what happens when the team encounters bad news? In an organization that is only doing agile, bad news is hidden until the stage boundary. In one that is being agile, it surfaces at the next stand-up, because surfacing it is safe.
Which of the following correctly describes the difference between 'being agile' and 'doing agile'?
What is a benefit of both 'being' and 'doing' agile?
A team holds daily stand-ups and fortnightly retrospectives, but every decision escalates to a manager and retrospective actions are never implemented. What does this describe?