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 from one ad-hoc request to the next, or simply the pressure of a competitor that supposedly already is.

The right response depends on which of these problems you actually have. 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 one 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); so that discussion comes first, and the choice of tools later.

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

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

Opens straight away, no account

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 intensive course ends where application starts: whether a method holds up only becomes clear under deadline pressure on a real 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.

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).

Applied to agile transformations:

1. Methods instead of a way of working. Daily stand-ups, boards and sprint reviews are in place — decision paths, budgeting and performance targets 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. Ignoring 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 well-established way of thinking this through.

An honest sequence

If you combine the three formats rather than play them off against each other, a realistic order emerges:

1. Diagnose before you act. 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.

None of these stages is optional. What differs is how much it costs to skip each one.

---

Agile Forge supports organisations across all three formats: with in-house training, workshops and team coaching, on-site or remote, and with agile transformation consulting. 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.