February 2026 8 min read Retrospective
A blog about Agile that does not run its own retrospectives is not a blog worth reading. So: seven months in, nineteen articles published, and a significant amount learned about what this audience actually needs versus what I thought they needed when I started. This is the honest version of that retrospective.
The Hook: Practising What We Preach
The premise of agile-checksum.com is simple: run a checksum against what passes for Agile in the real world and report what you find. Seven months in, it is time to run that same checksum against the blog itself. What was the original intent? What has actually happened? What needs to change?
This is not a vanity retrospective dressed as insight. It is an honest assessment of what has worked, what has not, and what the content and approach will look like going forward – informed by reader responses, search data, and the kind of direct feedback that this format tends to generate.
What Worked: The Three Surprises
1. The “Real Problems” Resonated Most
The articles that generated the most response were not the framework analyses or the certification reviews. They were the case studies from practice – the Scrum Master who asked “is that my job?” when I suggested she should be challenging the deployment approval process. The Product Owner with 623 items in her backlog. The retrospective that produced forty-seven action items in twelve months, six of which were completed.
The pattern is consistent with what I have seen in twenty years of this work: people do not need more theoretical frameworks. They need someone to name the thing they are experiencing and tell them they are not alone in experiencing it. The value of this blog, if it has any, is in the recognition – the moment of reading a case study and thinking “that is exactly my situation.”
This is the lesson I already knew and half-forgot in the planning phase: the most useful content comes from the most specific experience, not from the most comprehensive framework coverage.
2. The Critical Voice Found Its Audience
The decision to write with an opinionated, sometimes uncomfortable voice was deliberate and, I admit, a little anxious. The Agile community is tribal in some of its corners. Criticising SAFe, questioning certification culture, and pointing out that most Scrum Masters are not doing the job as designed – these are not positions that generate universal approval.
What the response has shown is that there is a significant audience for honest critique in a space that is often dominated by consultant-friendly optimism. Practitioners who are quietly frustrated with the gap between Agile as described and Agile as practiced are not well-served by content that treats every implementation as a success story in progress. They are better served by someone willing to name the dysfunction and explore its causes without attributing it to individual failure.
The voice will stay. The anxiety about it will diminish.
3. The Glossary Works Harder Than Expected
The Glossary was planned as an SEO instrument with secondary value as a reference tool. It has become something more than that. The reader behaviour data shows that glossary terms linked from articles are clicked at a high rate – readers are using the cross-references as they read, building their understanding of how concepts connect rather than consuming articles in isolation.
The Glossary will grow. Not just in term count but in depth – each term will be expanded to include the “checksum” perspective: what the term means in theory versus what it looks like in practice. This is where the real value is.
What Did Not Work: The Three Honest Failures
1. The German Parallel Was Not Parallel
The plan was to publish each article in English and German simultaneously. The reality was that German translations consistently lagged the English publication by weeks, sometimes months. The parallel publication model was optimistic about the time required to translate without losing the voice and the precision of the original.
The solution going forward: English first, German when it is ready and not before. A good German translation published three weeks after the English original is more valuable than a rushed one published simultaneously. The German-language audience will be better served by quality than by synchronisation.
2. The Posting Frequency Was a Constraint, Not a Commitment
The editorial calendar was designed as a commitment: specific articles on specific dates, building toward a defined content arc. In practice, it functioned as a constraint that occasionally produced articles that were not yet ready to be written – where I had the structure but not yet the insight that makes a case study genuinely useful rather than merely illustrative.
A publication schedule is a useful tool. It should not override judgment about whether the content is ready. Several articles in phases four and five would have benefited from more time. The next season’s editorial calendar will be a framework rather than a contract.
3. The Interaction Loop Was Too Slow
A blog in 2026 that does not create conversation is a monologue dressed as content. The comment moderation model I started with – manual review before publication – was too slow and too passive. By the time a reader’s thoughtful response was approved and replied to, the moment of engagement had passed.
This is being addressed: faster comment moderation, a LinkedIn presence that extends the conversation beyond the blog, and a newsletter that creates a direct communication channel with readers who want ongoing engagement rather than one-off article consumption.
“A retrospective that only identifies what went wrong is half a retrospective. The other half is the honest assessment of what you will do differently – and the commitment to actually do it.” Markus – agile-checksum.com
The Checksum on Year One: By the Numbers
| What Was Planned | What Happened | Assessment |
|---|---|---|
| 19 articles over 7 months | 19 articles over 7 months | Delivered |
| EN + DE parallel publication | EN published, DE lagging | Needs adjustment |
| Glossary: ~30 core terms | 30 terms launched, growing | Delivered, expanding |
| LinkedIn presence from launch | Launched in month three | Late, building |
| Newsletter from month two | Not yet launched | Priority for season two |
| Opinionated, experience-based voice | Maintained throughout | Working as intended |
What Season Two Looks Like
The content arc for the next seven months shifts from foundation-building to deeper engagement with specific practitioner challenges. Three themes will drive season two.
Theme 1: The Coaching Conversations
The content that has resonated most is the content closest to real practice. Season two will include more direct coaching content – specific conversation frameworks for the difficult situations Scrum Masters and Agile coaches encounter regularly. Not scripts, but structured approaches to conversations that most practitioners find genuinely difficult: telling a manager their behaviour is undermining the team, challenging a Product Owner who is managing the backlog politically rather than strategically, having an honest conversation with a team about why their retrospectives are not producing change.
Theme 2: The Sector Deep Dives
The regulated environments article generated significant response from practitioners in pharma, banking, and energy who recognised their context in the content. Season two will include dedicated deep dives into each of these sectors – more specific, more actionable, and drawing on conversations with practitioners in those sectors rather than just my own experience.
Theme 3: The Interview Series
This was planned for the original launch and repeatedly deferred. Season two will include a structured interview series with practitioners whose experience and perspective extend or challenge the positions taken in this blog. Not cheerleaders. People who will push back, offer different interpretations, and add perspectives that twenty years in enterprise IT cannot fully provide.
What Has Not Changed
The blog’s founding premise – that most of what passes for Agile in organisations is a pale imitation of what the Agile Manifesto’s authors intended, and that naming this honestly serves practitioners better than optimistic reframing – has been confirmed by seven months of reader response. It will not change.
The voice will remain direct and opinionated. The case studies will remain specific and drawn from real experience. The glossary will remain honest about the gap between theoretical definitions and practical reality. The checksum questions at the end of each article will remain genuinely uncomfortable.
If you have read this blog and found it useful – thank you. The feedback, direct and indirect, has shaped what comes next. If you have found it challenging or provocative – good. That was the intent. The problems it describes are real. The organisations experiencing them deserve content that names them honestly rather than framing them as opportunities in disguise.
The Final Checksum on Year One
Every article in this blog ends with three checksum questions. This one is no different.
- If you have been reading since the beginning – what is one thing you have done differently in your Scrum Master or Agile practice as a result? If the answer is nothing, the blog has entertained you but not served you. That is useful feedback.
- What is the topic or question this blog has not addressed that you most need it to address? The answer to that question shapes season two more than any editorial calendar.
- Who in your network is experiencing the problems described in this blog and would benefit from reading it? The most useful thing you can do with content that helps you is share it with someone who needs it.
Year one is done. The checksum ran. The results are honest. Season two starts next week.
“Verifying real agility requires running the checksum continuously – including on yourself and your own work. The organisations that only inspect others never improve. Neither do blogs.” Markus – agile-checksum.com
Glossary Terms Used in This Article
- Retrospective – A Scrum ceremony for inspecting how the sprint went and identifying the most important improvements.
- Agile Manifesto – The 2001 document defining the values and principles of Agile software development.
- Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team and organisation.
- Product Owner – The Scrum accountability responsible for maximising product value.
- Backlog – An ordered list of work items representing everything a team might work on.
No Fluff. Just Real Agile.
Straight to your inbox. No buzz, no spam.
Related Articles
"Scrum Anti Patterns That Kill Delivery"
Most Scrum problems are not caused by the framework. They come from the small compromises teams normalise until delivery turns into theatre. This article looks at the Scrum anti patterns that quietly wreck flow, ownership and trust.
Read Article →"What Deutsche Bank Taught Me About Agile"
Two years of Agile transformation at one of Europe's largest financial institutions. What the theory predicted and what actually happened.
Read Article →"Retrospectives That Change Nothing"
47 action items in 12 months, 6 completed. Retrospectives that produce no change aren't an improvement system – they're theatre.
Read Article →