Verifying Real Agility.
What this blog is for. And who is writing it.
The Mission
In computer science, a checksum is a small value calculated from a dataset and used to detect errors. You run it against the original. If the numbers match, the data is intact. If they do not, something went wrong in transmission – and you need to know before you build anything on top of it.
That is what this blog does with Agile. It runs the checksum. It takes what organisations say they are doing – self-organising teams, empirical development, servant leadership, continuous improvement – and compares it against what they are actually doing. Most of the time, the values do not match. The data has been corrupted somewhere between the Agile Manifesto and the sprint board.
"Individuals and interactions over processes and tools. Run that checksum against your organisation. If what you find is processes governing individuals and tools substituting for interactions – you have found the problem."
This blog exists because the Agile space has too much optimism and not enough honesty. Too many case studies about transformations that succeeded and too little analysis of why they failed.
Experience over theory
Every position taken here is grounded in real cases from real organisations. Abstract framework analysis without field experience is philosophy, not practice.
Honest over comfortable
The problems this blog describes are real and consequential. They deserve precise diagnosis, not optimistic reframing. Naming dysfunction is not negativity – it is the first step toward fixing it.
Pragmatic over dogmatic
Frameworks are tools, not religions. The goal is delivering value to customers and building effective teams. Whatever serves that goal in a given context is the right approach.
The Author
I spent sixteen years as a backend developer before I became a Scrum Master. The shift to Scrum Mastering was not a career change so much as a change in where I thought I could be most useful. After twenty years in enterprise IT – across banking, pharmaceuticals, automotive, logistics – I had accumulated a fairly clear picture of what makes software development in large organisations dysfunctional. Most of it has nothing to do with technology.
I have seen Agile work. I have seen it work at Deutsche Bank, at BASF, at Boehringer Ingelheim – not perfectly, not everywhere, but genuinely and measurably in the teams and contexts where the conditions were right. I have also seen it fail. More often than it succeeds, if I am being honest.
The failure pattern is almost always the same: the practices are adopted without the values, the ceremonies are running without the trust, the frameworks are implemented without the organisational change that would make them effective.
Work with me
I work with organisations on a freelance basis – coaching, transformation support, and the kind of honest assessment that external engagements make possible.