← All Book Reviews
Book Review
Redefining Agility - A Strategic Review of Sooner Safer Happier
Jonathan Smart
Jonathan Smart
Here is a question most transformation programmes never seriously answer: how do you know it's working?
Not "are the teams doing the ceremonies?" Not "have we trained enough people in SAFe?" Not "does our CTO mention agility in their all-hands?" The real question: are you delivering better outcomes, faster, more safely, with people who are happier doing it?
Jonathan Smart spent years leading the agile transformation at Barclays - one of the largest, most complex financial institutions on the planet - and Sooner Safer Happier is what he learned. Not what the framework vendors told him. Not what the consultants promised. What actually happened, what worked, and more importantly, what didn't.
The result is one of the most honest, grounded, and practically useful books written on the subject of organisational transformation. It will make you question everything your programme has been measuring.
Most organisations are doing agility wrong. Not accidentally - systematically wrong. They have adopted the language, the rituals, the roles, and the ceremonies - without changing the underlying power structures, funding models, governance mechanisms, or culture that make transformation impossible.
Smart calls this "doing agile" versus "being agile." The distinction sounds semantic. It isn't. Organisations that are doing agile have daily standups that are status reports to management. Organisations that are agile have teams that inspect their own work, adapt their own process, and are trusted to make decisions in their domain.
The difference between those two states is not a methodology choice. It is a leadership choice. And this book is primarily written for leaders who are willing to make it.
Smart's central framework is BVSSH - Better Value Sooner Safer Happier - and the brilliance of it is what it doesn't say. It doesn't specify a process. It doesn't prescribe a cadence. It doesn't mandate a tool. It names the outcomes you're trying to achieve and gives you the freedom to find the path that works in your context.
The insight is that these outcomes reinforce each other. Organisations obsessed with sooner at the cost of safer create fragile systems. Organisations that optimise for safer at the cost of sooner create irrelevance. The goal is the whole picture.
One of the most valuable aspects of the book is Smart's catalogue of anti-patterns - the failure modes that organisations repeatedly fall into despite (often because of) their transformation efforts.
The most common and most damaging: the illusion of transformation. Teams are reorganised into squads. Jira boards replace Gantt charts. Someone becomes an Agile Coach. And yet: funding still flows through projects with fixed scope and date commitments. Architecture decisions still require committee approval. Deployment still requires a change management board that meets fortnightly. The rituals have changed. The system hasn't.
Smart's gift is naming these traps so clearly that you can't unsee them. Once you've read his description of "cargo cult agile," you will spot it everywhere - including, uncomfortably, in your own organisation.
Most transformation programmes measure outputs: velocity, story points, number of teams trained, percentage of employees certified in a framework. Smart makes a devastating case that these measures are not only useless - they actively harm transformation by giving leaders the illusion of progress while the underlying system stays exactly the same.
What you should measure instead: cycle time, customer satisfaction, employee engagement, the rate at which hypotheses are tested and validated. These are lagging and hard to fake. They tell you whether the system is actually improving.
The harder challenge: if you can't answer "what does success look like in six months, measured in outcomes, not activities?" - your transformation doesn't have a clear enough goal.
The instinct of most large organisations facing agility challenges is to scale. To buy a scaling framework, train thousands of people, implement the ceremonies at every level, and declare the transformation underway.
Smart's counter-intuitive argument is that most organisations need to descale before they scale. To reduce the size of work items. To break initiatives into thinner slices. To reduce the number of dependencies between teams. To simplify the governance model before trying to make it faster.
Scaling dysfunction doesn't produce scaled performance. It produces expensive, widespread dysfunction. Fix the fundamentals first.
The hardest truth in the book: you cannot transform an organisation from the middle. Cultural change, genuine empowerment, outcome-oriented governance, psychological safety - none of these can be installed by a programme team or mandated by a framework. They require leaders to behave differently. To stop asking for weekly status reports that force teams to spin certainty out of uncertainty. To stop funding by project and start funding by team and outcome. To create the space for failure and learning that they say they want but consistently punish in practice.
Smart's framework for leadership in transformation is simple and demanding: be the change, measure outcomes, and trust your people.
Your transformation programme has a success metric. Is it an outcome, or an output? If you're measuring "percentage of teams using agile ceremonies," you are measuring the wrong thing.
What is the longest path from an idea to working software in production in your organisation? How many approvals, committees, and handoffs does it cross? Each one is a design decision someone made. Are they still the right decisions?
If your most trusted engineer told you that your transformation was creating bureaucracy without reducing it, would they feel safe doing so? If not, you have a psychological safety problem that no framework can fix.
Smart's BVSSH model asks you to optimise all five outcomes simultaneously. Which one are you currently sacrificing? Is that a conscious trade-off or an accidental one?
"Being agile" rather than "doing agile" - what would it look like in your organisation if teams were genuinely trusted to decide how they deliver, not just what? What would you have to stop doing to make that possible?
Name the anti-patterns operating in your organisation right now. Be honest. Use Smart's catalogue as a diagnostic. The ones that sting most are the most important.
Pick one BVSSH outcome and build a measurement strategy around it. Not a proxy - an actual outcome measure. Define baseline, target, and timescale. Make it visible to leadership.
Find the longest feedback loop in your delivery system - from idea to production - and map every handoff. Present the map to your leadership team. Ask: which of these exist for good reasons? Which just exist?
Have a conversation with your most senior sponsor about what transformation success looks like in outcomes. If you can't agree on the answer, you don't yet have the alignment needed to make progress.
Read the anti-patterns chapter with your team. Ask which ones you recognise in your context. That conversation alone will be more valuable than most retrospectives you've run this year.
"It's not about being agile. It's about being better, faster, safer, and happier - for customers, colleagues, and society."
- Jonathan Smart