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, please let me know and I'll get them fixed.

Browse by topic area:

• Psychology & Behaviour (Formerly UnconsciousAgile.com)
• Flow, Kanban, Scrum (Formerly ImprovingFlow.com)
• Technical Practices (Formerly 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!

• 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.
• Recommended reading: I'm often asked for book recommendations.
• 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.
• Improving your meetings: Specifically retrospectives (my video course), and standups. What if your people won't participate?
• Improving learning: with neuroscience and LEGO.
• Flow & Kanban: Flow metrics, probabilistic forecasting, and understanding waste.
• Technical practices: Continuous integration, TDD as design, and ensemble programming.
• Something fun: The millennial whoop, and inattentional blindness.

---

Not motivated to do anything

I occassionally hear from managers that their people just aren’t motivated to do anything. This is rarely the complete story as these people are clearly motivated to do many things, just perhaps not those things that the manager wants them to do.

Prime factors in Elixir

In the last article, we showed how pattern matching could solve FizzBuzz. It’s a deliberately simple example so let’s look at something a little bit more complex.

Exploring Elixir

I’ve long advised people to learn multiple programming languages, as each new language you learn will make you better at all the ones you already know. Not just languages with different syntax, but languages that challenge how you look at problems.

NLP Meta Model

Each of us has an inner map of the world with rich connections between all the pieces. When we attempt to communicate with others, we’re limited by the words we use, which can’t possibly capture the richness of our internal map. As a result, we lose significant information as we try to communicate.

How We Think: Systems 1 and 2

In his seminal book Thinking Fast and Slow¹, Nobel prize winning psychologist Daniel Kahneman talks about two very different kinds of thinking that we do. He refers to them as System 1 (fast, but often wrong) and System 2 (slower, more accurate).

1. Thinking Fast and Slow by Daniel Kahneman ↩

Code comments

Research shows that code comments rarely stay in sync with the code they’re describing. Other psychology research shows that incorrect comments are worse than no comments at all. Should we get rid of code comments entirely or are some worth keeping around?

Perils of Why

In a coaching context, asking “why” questions can be problematic. They can often give results that we did not intend and should be used carefully and sparingly.

Learning from the past

Many years ago, I came in one morning to a client, to discover the website down and the email server completely unresponsive. Naturally, we assumed that we we’d been hacked. What else could take down two unrelated systems at the same time?

Per-story estimates

Per-story estimates were an interesting experiment that failed and it’s time to move on. Today, we have better ways so it’s time to stop putting individual estimates on stories. This is equally true for Scrum and Kanban teams.

What is a Service Level Expectation?

A service level expectation is a probabilistic forecast of how long it will take a single item to pass through the system. For example: “85% chance of completing in four days or less”.