Watch: Applying Agile in complex environments - lessons from leading real-world transformations
Agile has been declared dead dozens of times, but the organisations that understand it are still outperforming those that do not. The problem is not agile. It is how it gets implemented. Most transformations focus on the mechanics, the boards, the sprints, the ceremonies, and skip entirely the harder work of strategy clarity, leadership behaviour and organisational design. That is why most of them fail.
In this session, Sebastian, a transformation leader and professional coach with over 30 years of experience in enterprise agile, telco and digital entrepreneurship, shares 20 lessons drawn from working across both traditional and progressive organisations in multiple countries. He structures them into five dimensions: strategy, people, structure, process and technology.
Watch the full recording here:
What you'll take away from the session:
-
The four strategy elements most commonly missing from transformation programmes: a clear why, a documented operating model, a defined scope and visible executive sponsorship
-
Why the people dimension is the hardest to get right and the one most frameworks ignore entirely, including psychological safety, coaching leadership, and incentive alignment
-
What aligned autonomy means in practice, and why giving teams more freedom is actually a more reliable path to control than traditional oversight structures
-
Why flattening an organisation and productizing around end-to-end user journeys produces speed that layered hierarchies structurally cannot
-
Why no scaling framework can be lifted off the shelf and applied directly to your organisation, and what to do instead
-
Why OKRs set quarterly are fundamentally more compatible with agile delivery than annual planning cycles, and how Google used them to scale
-
What scrum masters and agile practitioners need to invest in to remain relevant as AI takes over the mechanical parts of the role
This session is practical, direct and grounded in real engagements across automotive, financial services, pharma and technology. If you are leading or advising on any kind of transformation, this is 50 minutes well spent.
Hit play and take the 20 lessons back to your next engagement.
Why do agile transformations fail even when organisations invest heavily in frameworks?
The most common reason is that frameworks are applied to the surface of an organisation while the underlying system stays intact. You can introduce Scrum ceremonies and still have five layers of management between a team and a customer. You can run two-week sprints and still measure people on individual annual KPIs that have nothing to do with team performance. Frameworks describe process mechanics. They say almost nothing about leadership behaviour, incentive structures, psychological safety or organisational design, which are the four things that actually determine whether a transformation produces results. The result is what Sebastian describes as teams of good people trapped in bad systems, going through the motions of agile delivery without any of the cultural or structural conditions that make it work.
How do you build psychological safety in an organisation that has historically punished failure?
Slowly and by demonstration, not by declaration. The research Sebastian references, Google's Project Aristotle, identified psychological safety as the number one driver of team performance. In organisations where failure has been punished, the most effective path is to start in a defined pilot with a willing team, protect that team explicitly, allow them to make mistakes without consequence and make the performance results visible. When the surrounding organisation sees the output of a team operating under genuine psychological safety compared to teams operating under fear of failure, the argument shifts from philosophical to empirical. The other lever is leadership coaching, specifically helping managers learn how to respond to failure in ways that build trust rather than eroding it.
What does executive sponsorship actually mean in an agile transformation?
It means a senior leader putting their authority behind the change, visibly and consistently, over a sustained period. Not commissioning it and stepping back but participating in it: making their own backlog visible, modelling the transparency they expect from teams, and providing protection when teams make mistakes as part of the learning process. Sebastian is direct that a transformation driven purely from the bottom up will eventually run out of air cover. Teams will experiment, stumble and then quietly revert when there is no one at the top willing to absorb the political cost. The sponsor role is not ceremonial. It is the single most reliable predictor of whether a transformation survives contact with organisational resistance.
Is it possible to run agile projects inside a non-agile organisation?
Yes, but with constraints that matter. A participant in the session put this precisely: when you are contracted to deliver a project in an agile way inside an organisation whose systems, approvals, dependencies and culture are still traditional, you are only as fast as your least agile dependency. Sebastian's answer is to accept that constraint rather than fight it, identify what you can and cannot change within the scope of your engagement, and be honest with stakeholders about what is a process problem versus a structure problem. The practical advice for independent professionals in this situation is to manage upwards clearly, document the constraints that are limiting delivery and make explicit recommendations about what the organisation would need to change to close that gap.