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.

---

Looking for improvement

I was asked recently what things I’d look at to determine if a team or group is improving and there are three main areas. In all three cases, none of these prove that improvement is happening. What they do provide is a place to me to start asking questions so that I can discover more.

High WIP invalidates prioritization

The more items we have in progress at once (WIP), the less important our initial prioritization is. When we work on one item at a time then items get done in the order we started them so we are completing them in the order of most importance.

YAGNI (You Aren’t Going to Need It)

YAGNI (You Aren’t Going to Need It) is a principle that keeps us from over-engineering the system. Build today only those things that you need today. Things that we need tomorrow, we can build tomorrow.

Hot-fixes

It used to be common that we would have two different ways to deploy something to a production environment.

Perceptual positions & Halloween

I had a client once that went all out for Halloween. Just about everyone showed up in costumes and there were prizes for individual or team costumes. At the time I was there, it was commonplace for work to be outsourced to India so my group decided to do a team costume of “IT outsourced to Mars”.

Hybrid teams

For decades before covid, were were already using a hybrid model. We’d outsource part of our development teams to other countries, like India. We’d then have part of our teams collocated in our offices and some people calling in from that other country.

Mocking frameworks

I’ve recently noticed a number of posts criticizing mocking frameworks, where half the responses are defending the idea of mocking rather than talking about the frameworks that had been called out¹. Let’s be clear that those are two completely different things.

1. This is an example of a psychological phenonomenon called Attribute Substitution where we are faced with a computationally difficult decision, we will often substitute a more easily calculated decision in it’s place and answer that instead, without even realizing that we did this. ↩

Audit

We commonly hear things along the lines of “that’s required for audit purposes” and it’s therefore not to be questioned. If it really is needed for audit then we should certainly do it. Yet, every time I’ve had the opportunity to talk to an auditor, I discover that they don’t want most of the things that we give them.

Fractional people

I worked with two teams that shared a database specialist, for a fairly proprietary system. Because she was on two teams, they had her attend all meetings for both teams. Two standups, two planning meetings, two retrospectives. She ended up doing crazy amounts of overtime because she couldn’t get her regular work done during the day. Her days were filled with meetings, and it was only after everyone else left that she got anything done.

Optimizing for time overlap

If we want people to actively collaborate then they have to be working at the same time. It’s irrelevant whether they’re in the same physical room if they don’t work the same hours. If one person comes in early and another comes in late then there is no benefit in forcing them into the same place.