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.
Larger retrospectives
In my Retrospective Magic course, I’m mostly focused on team based retrospectives, and I was asked this week what needs to change when we’re doing a larger one?
Appeal to authority and GenAI
“Appeal to authority” is both a commonly used persuasion technique, and also a logical fallacy described in the excellent book Logically Fallacious: The Ultimate Collection of Over 300 Logical Fallacies. It’s when we insist that a claim is true simply because a recognized authority said it was true, and without any actual supporting evidence.
Bad documentation
I grew up in a large city, and when I first moved out to a small town, one of the first differences I noticed was how everyone gives directions based on how things used to be.
Everyone should be able to update the board
Back in the 1990’s, version control wasn’t very common and I recall working with one of the first teams I’d been on, that was using it. The company had chosen to only buy a single license for one person on the team, which meant that any time we wanted to check something into version control, we would email our changes to this one guy and he would do the merge and then email back a copy of the latest code.
Why don’t we collaborate more?
In an office environment, it’s always been obvious when there’s a major production problem. You’ll see everyone standing around a single desk; everyone working together on the same problem at the same time. If there’s a blocker to what they’re doing, one or more people in the group will immediately do something to remove that obstacle, to ensure that the main work continues uninterrupted.
Priorities
Out of the box, Jira offers up five different priorities for any given ticket, which implies five different classes of service. Since the option is there, many teams will use all of them at different times.
Secondary Gain and Work in Progress (WIP)
I think by now we all understand that having too many things in progress at once is a negative on almost all counts. We get less accomplished, our quality drops, and we generally feel more overwhelmed. Yet, we continue to start more work than we can finish, over and over again. Why might this be?
Speeding up the daily coordination meeting (AKA standup, daily scrum)
When I first engage with a team, I’m focused on ensuring that we have an effective daily meeting, and I’m less concerned about how long it takes. Are we talking about all the things that we should be talking about? Are are actively collaborating on the work?
Meeting punctuality
A 2018 study on meeting lateness shows that meeting lateness is negatively related to both meeting satisfaction and effectiveness.
Supporting the new hires
I’m seeing more posts saying that new hires need to be in the office because they ramp up faster, than if they’re remote. There’s a fundamental presupposition in these statements that once we’ve hired these people, we’re immediately going to throw them to the wolves and have them work all by themselves.