Power of words

The words we use are far more important than most people realize. They have the ability to make deep changes in unconscious behaviour in ourselves, and the people around us.

Pair Programming

Probably the most polarizing of all the Agile technical practices is pair programming. People either love it or hate it and often strongly hold one of those two positions even if they’ve never tried it for themselves.

Classes of service

Many Kanban teams use classes of service to help model their workflow. We’re going to talk about how they work, where they are valuable and why you should avoid them wherever you can.

Neuroscience of psychological safety

I find that many of the conversations we have about psychological safety tend to devolve into platitudes: “It’s good and we should have more of it” or “managers should create safer spaces”. This doesn’t give anyone any context into why it’s actually important or how we can go about improving it.

Book recommendations for Agile Coaches

I talk a lot about neuroscience, psychology, hypnosis, body language, and other topics as they relate to Agile methods and I’m frequently asked: “What books do you recommend as an introduction?” There is no single best book to start with so I’m giving you a bunch of categories to pick from.

“We tried Kanban and it didn’t work”

I sometimes run across teams that say “we tried kanban and it didn’t work”. When I hear this, I’m always genuinely curious and ask for more details about what they’d done and what specifically didn’t work for them.

The millennial whoop and our brain as a prediction engine

Our brains are highly advanced prediction engines1. They are constantly trying to predict what will happen next so that we can be prepared for what’s coming. When our brain makes a successful prediction then we get rewarded with a tiny shot of dopamine that makes us feel good.

  1. Professor Lisa Feldman Barrett explains how our brains evolved as a prediction engine in her excellent book Seven and a Half Lessons About the Brain ↩

Google’s Project Aristotle

You may have already heard of Google’s Project Aristotle. Back in 2012, Google set out to identify what made their most effective teams so much better than others. They wanted to reproduce that magic that some teams had across the company and so they interviewed 180 teams and collected all kinds of data.

Code coverage is a perverse incentive

While code coverage can be a useful measurement for teams to improve their own results, the moment it’s tracked by people external to the team, particularly management, it becomes a perverse incentive.