50% off until April 19 — use code SPRING2026.
Are you just looking for the latest articles and want to skip all the preamble and summary? Click here.
All of this content used to be spread over three different blogs at three different domains and it's now been merged into one. Why was it ever three? Because at the time it seemed reasonable that each of them was for a different audiences, and yet over time I've found that the lines between topic areas got blurrier and tended to overlap. So now they're all together in one place.
If you encounter things that seem broken, let me know and I'll get them fixed.
Browse by topic area:
| Category | Formerly found at |
|---|---|
| Psychology & Behaviour | UnconsciousAgile.com |
| Flow, Kanban, Scrum | ImprovingFlow.com |
| Metrics and Forecasting | ImprovingFlow.com & MikesHardMetrics.com |
| Technical Practices | AgileTechnicalExcellence.com |
There's a lot here and if you're not sure where to start, here are some popular starting points. From these, you'll find crosslinks to even more topics. Enjoy!
-
Neuroscience / Psychology
- Psychological Safety: An overview. For the science, see the SAFETY model. For Google's research into why it's important for high performing teams, see Project Aristotle. What happens when we don't have that safety?
- Anxiety and Stress: For the science, see Polyvagal Theory or a description of some neuroscience, illustrated with a bear encounter. To let go of that anxiety, see the Anti-Anxiety toolkit.
- Generally more about the brain: Cognitive bias, motivation, default mode network, systems 1 & 2 and neurotransmitters (chemicals) that drive behaviour.
- Language patterns: Why language is so important, and Clean Language, a specific language pattern that has excellent application for coaching.
-
How to improve...
- Meetings: The common problems with meetings. Improving the standup / daily coordination meeting. Retrospectives are covered in my popular video course Retrospective Magic. Then what if your people won't participate?
- Improving learning: with neuroscience and LEGO.
- Improvement: Continuous improvement in general. Understanding the metaphor of "lowering the water level".
-
Flow of value
- Metrics: Flow metrics, probabilistic forecasting.
- Waste: Overview of waste. Understanding the cost of interruptions, and the kinds of waste that gets in the way of flow.
- Work in progress (WIP): Setting initial WIP limits. What to do when we're overwhelmed with WIP
- Metrics and Forecasting: All of these have their own category now.
- Technical practices: Continuous integration, TDD as design, and ensemble programming.
- Ensuring we're building the right thing: Slicing stories and epics. Understanding the context of what we're building. Knowing how to prioritize that work.
- Something fun: The millennial whoop, and inattentional blindness.
- Recommended reading: I'm often asked for book recommendationsbook recommendations.
Jira API: Knowing if an issue is visible on the board
When we see an item aging unnecessarily in the data, one of the first questions I ask is “is the issue even visible on the board?” If it isn’t then I think we immediately understand why we’re ignoring it. “Out of sight, out of mind” is a very real thing.
Poor code and the RAS
My last post on refactoring generated a lot of conversation so lets look at a different aspect of that.
Deliberate practice
I frequently give the advice to developers that we should always be leaving the code cleaner than when we arrived. That we should be refactoring aggressively to ensure the the code is in good shape. This usually brings people out who violently disagree with this and argue that we should never refactor without permission or that we should only touch the smallest amount of code to satisfy the new feature, no matter how ugly the system is.
Cumulative flow diagrams (CFD)
For years, I’ve been watching teams show off cumulative flow diagrams as an indication of their progress. Everyone nods their heads and pretends that they understand what they’re looking at, thinking that it must be obvious to everyone else. Except it isn’t.
Debunking Monte Carlo myths
This started as a question on reddit about “if you don’t use Monte Carlo for forecasting, why don’t you”, and it uncovered all kinds of incorrect assumptions about what it is and why you’d use it. We unpack some of these here.
Quick tips for demos
I’ve seen a lot of bad team demos over the years. Here are two fast tips to improve those.
Imprints in the ground
After a forest fire has passed, some trees will be left standing but scorched from the fire. Others, however, will have disappeared entirely. Sometimes the trunk and then the roots will continue to smolder until there is nothing left but ash, and then with some rain, even the ash will disappear.
When “make it visible” is the wrong approach
My general approach to fixing almost any organizational problem starts with “make it visible”. Make the problem visible enough and sometimes other people will step in and fix it without any effort on my part.
Delivery pressure
I once engaged with a team that had just finished the development of a new service and were blocked, waiting for legal approval, before they could turn it on. They effectively had nothing to do and so management thought this was a good time to bring some coaches in.
Why people don’t use Monte Carlo
A few weeks ago there was a question on Reddit, asking people who don’t use Monte Carlo forecasts, why they don’t.