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.

---

Ensemble work feels slower, but that’s deceptive

It’s interesting that when a team tries ensemble work (also called mob programming), it feels really slow. Slower than it actually is.

Only one ticket per work item

We should only have one ticket on the board for any given piece of work. This should be obvious and yet I see this problem on a regular basis.

Basic Flow Metrics

Flow metrics tell us about the activity in the system; how well is the work flowing. These are often the first metrics that I consider when trying to improve a system. I start here partially because these metrics are easier to collect than many others, and because I can still make many effective decisions based on just this.

Survivor Bias

“Survivor bias is the logical error of concentrating on entities that passed a selection process while overlooking those that did not. This can lead to incorrect conclusions because of incomplete data.”
— Wikipedia”

Cognitive Bias

It would be easy to think that all cognitive bias is a bad thing. When we hear people talking about it, it’s often in the context of the collection of biases that make up racism or sexism or other generally negative things. Yet, the truth is that cognitive bias is the way that our brain manages energy use and is overwhelmingly a positive thing for us.

Continuous improvement

Back in the days when faxing between companies was a popular thing, I recall a client that had a workflow like this:

1. Fax arrives and is printed by the fax machine
2. Paper is picked up by a person and carried to the scanner where is it digitized.
3. Paper is immediately shredded because there was confidential information on it.

Focus on Value

Whatever we focus on, we’ll get more of. If we focus on the flow of value then we’ll get more value. If we focus on being busy then we’ll get more of that.

Visualizing Flow Efficiency

I’m playing around with visualizing flow efficiency in my JiraMetrics tool. Flow efficiency is the percentage of time that we’re actually adding value to the work item divided by the total time. So if a ticket is open for 10 hours but in that time we only spend 2 hours actually working on it then the flow efficiency would be 2 / 10 or 20%.

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.