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.
A decade with LEGO Serious Play
I just realized that it’s been ten years since I first took LEGO® Serious Play® training with Robert Rasmussen. I have this listed on my business cards and it’s amazing how many great conversations this starts. LEGO seems so out of place in a business context, that people immediately want to know more.
When we don’t have safety
While we often talk about psychological safety, we often don’t prioritize fixing the environment to make it better.
The facilitators role
If you’re facilitating the daily coordination meeting (standup, daily scrum, whatever you want to call it), and you’re doing all the talking, then you’re doing it wrong.
Constraints enable creativity
With retrospectives, we generally have specific formats that we follow, rather than just pulling people together and expecting them to talk. This feels very counter-intuitive for many; surely we don’t need rules or formats to get people to come up with creative ideas. Yet doing that will dramatically improve the results we get.
The extreme in eXtreme Programming (XP)
My first exposure to anything Agile was with eXtreme Programming (XP) back in 1999. While it had many process steps similar to what Scrum and Kanban offer today, the thing that really differentiated XP was it’s focus on technical practices. It’s those technical practices that we are usually referring to when we talk about XP today.
A tale of two teams
I was asked about two teams recently. They worked on the same product, did very similar work, and had similar team composition (team size, skills, etc), yet one of them was noticeably outperforming the other. The company wanted to understand why this was happening and how they could make it better.
What work to select for an ensemble
When I facilitate an ensemble session (also called Mob Programming) with a team, I’m often asked what work we should pick to work on. The answer is really whatever we would have done this week anyway.
Thinking we want more documentation
It’s quite common when we reflect on problems that someone will say “we just need better documentation”, and everyone will nod their heads. Yet we rarely ask the question “if we wrote better documentation, would anyone actually read it?”
Hero culture revisited
Hero culture is a situation where one person, or a small number of people, take on the majority of the work, and others start to step back. If you hear things like “these people don’t pull their weight and I have to do everything for them”, you may not have lazy people at all. You may have the effects of hero culture destroying the teamwork that you should have.
Optimizing for our own effectiveness
One of the mistakes we make is assuming that people will make logical and rational decisions to optimize for the perfect overall outcome. People do make decisions that seem logical to them, however they do so within their own context. They do what’s right for them, not what’s optimal for the overall situation.