Agile transformation: workshop, training or consulting — what fits when?

"We need to become more agile" is one of the most common sentences in organisations — and one of the least precise. It can hide entirely different problems: decisions that take too long, projects with no visible progress, teams working by ad-hoc requests, or simply the pressure of a competitor that supposedly already is.

Depending on which problem actually exists, the right measure differs. In practice the order is often reversed: first a format gets booked — an agile transformation workshop, a Scrum training course, a consulting mandate. Then people work out which problem it is supposed to solve.

Three formats, three very different effects

The agile transformation workshop: creating alignment

A workshop (typically two to three days) delivers one thing above all: it brings people who otherwise never sit at the same table to a shared understanding. What does agile mean for us? Which problems do we want to solve with it — and which explicitly not? The Agile Manifesto puts values above tools (Beck et al., 2001); that discussion belongs at the start, not the tool selection.

What a workshop does not deliver: behavioural change. After three days everyone returns to unchanged structures, meetings and target agreements. Expecting a transformation from a workshop alone confuses alignment with implementation.

Fits when: the leadership circle or team is at the beginning and needs a shared picture — or a concrete decision (say: choosing a pilot area, settling on an approach).

Training: building competence for the agile transformation

A training course builds skills: applying Scrum properly, running a Kanban board so it actually exposes bottlenecks, slicing requirements, working with AI tools in day-to-day project work. Competence is the precondition of any transformation — teams that don't master the methods can't adapt them either.

The limit: training works on people, not on structures. Sending trained staff back into unchanged processes produces frustrated experts, not agile teams.

That limit has consequences for the format. A one-off block course ends where application starts: whether a method holds up only shows under schedule pressure in the project — that is, after the course is over. Spreading the training out, roughly one day a month, pulls that moment back into the course, because teams keep working on their own project between sessions and bring whatever snags they hit to the next one. None of that changes a process. It only makes visible sooner which processes are in the way.

This assumes the course is built around the organisation: content, examples and pace are set by the teams and the work in front of them, not by a fixed curriculum. Which framework it runs under — Scrum, Kanban, AgilePM, PRINCE2, ITIL 4 or DevOps — follows from that work. Location and group size come second: whether the sessions run on site or online, and whether one team attends or several, matters less than whether anything is actually practised between them.

Fits when: it is clear which way of working should be established, and the gap is in ability — not in permission.

Agile transformation consulting: anchoring it in daily work

Consulting and team coaching start where workshop and training stop: in the day-to-day. Real sprints, real retrospectives, real conflicts with stakeholders. Consulting works on the structures that produce behaviour: decision paths, interfaces, prioritisation, leadership habits.

It is the most far-reaching format — and the most expensive. It pays off when the organisation is serious about the change and leadership is willing to question its own routines.

Fits when: the foundations are in place and the task is now to defend the new way of working against everyday pressure.

What actually makes transformations fail

Observations about change processes have been remarkably stable for decades. As early as 1996, John Kotter described the typical failure points from his consulting practice: lack of urgency, no guiding coalition, wins that are never made visible, and changes that never get anchored in the culture (Kotter, Leading Change, 1996).

Translated to agile transformations:

1. Methods instead of a way of working. Daily, board and sprint review are in place — decision paths, budgeting and target agreements stay untouched. The result is agility as a façade.
2. Delegating downwards. Leadership commissions the transformation but exempts itself. Teams are supposed to change; the steering model is not.
3. One format for everything. A single workshop is expected to deliver what only the combination of alignment, competence building and ongoing support can.
4. No look at the context. Not every area needs the same dose of agility. Which approach fits which situation can be examined systematically — the Cynefin framework is a proven thinking tool for exactly that.

An honest sequence

Combining the three formats instead of playing them off against each other yields a realistic order:

1. Diagnosis before measures. First clarify which problem is to be solved. A short self-assessment like the Project Health Check provides an initial baseline.
2. Workshop for shared alignment and the choice of a pilot area.
3. Training for the teams that are actually supposed to work differently — hands-on, on their own projects.
4. Support through the first months, until the new way of working survives everyday pressure.

Soberly assessed, none of these stages is optional. Only skipping them costs a different amount at each stage.

---

Agile Forge supports organisations across all three formats: in-house training, workshops and team coaching — on-site or remote. For teams that prefer to learn on their own, there are the online courses in agile project management and AI.

Sources

• Kotter, J. P. (1996): Leading Change. Harvard Business School Press.
• Beck, K. et al. (2001): Manifesto for Agile Software Development. agilemanifesto.org.
• Snowden, D. J. / Boone, M. E. (2007): A Leader's Framework for Decision Making. Harvard Business Review.