Are you just looking for the latest articles and want to skip all the preamble and summary? Click here.
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, let me know and I'll get them fixed.
Browse by topic area:
| Category | Formerly found at |
|---|---|
| Psychology & Behaviour | UnconsciousAgile.com |
| Flow, Kanban, Scrum | ImprovingFlow.com |
| Metrics and Forecasting | ImprovingFlow.com & MikesHardMetrics.com |
| Technical Practices | 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!
-
Neuroscience / Psychology
- 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.
- 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.
-
How to improve...
- Meetings: The common problems with meetings. Improving the standup / daily coordination meeting. Retrospectives are covered in my popular video course Retrospective Magic. Then what if your people won't participate?
- Improving learning: with neuroscience and LEGO.
- Improvement: Continuous improvement in general. Understanding the metaphor of "lowering the water level".
-
Flow of value
- Metrics: Flow metrics, probabilistic forecasting.
- Waste: Overview of waste. Understanding the cost of interruptions, and the kinds of waste that gets in the way of flow.
- Work in progress (WIP): Setting initial WIP limits. What to do when we're overwhelmed with WIP
- Metrics and Forecasting: All of these have their own category now.
- Technical practices: Continuous integration, TDD as design, and ensemble programming.
- Ensuring we're building the right thing: Slicing stories and epics. Understanding the context of what we're building. Knowing how to prioritize that work.
- Something fun: The millennial whoop, and inattentional blindness.
- Recommended reading: I'm often asked for book recommendationsbook recommendations.
The ugliest, nastiest, code
When teaching developers, I’ll often refer to “the ugliest, nastiest, part of your codebase that you’re all afraid to touch in case it breaks”. When I say that, everyone usually nods their heads. They know exactly what code I’m talking about because any long lived codebase has one. In fact they often even know who wrote that particular code, and its very common for that person to no longer be at the company.
Tracking metrics
Most companies I work with have a desire to track metrics for their development teams, and I support this. It’s hard to improve something we can’t see so metrics are a good first step as we seek to improve.
Why technical practices?
Most of the conversation about the agile technical practices tends to stay in the weeds. We talk about whether we should test before or after, whether we should be writing unit or acceptance tests, whether we should be mocking or not, whether PR’s are helpful or harmful. We have discussions back and forth about all of these topics and while they are good details, they sometimes obscure what’s really important.
When everything is a priority
I was asked what to do when the customer won’t prioritize the stories and insists that everything has to be done now. That brought back memories of the first time that had happened to me. This was a very long time ago and I can’t remember who had given me the idea to approach it this way.
Why we branch the code
Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.
Outcome bias (Resulting)
When I first read How to Decide: Simple Tools for Making Better Choices by Annie Duke, one of my biggest aha moments was from what she calls Resulting and is more formally known as Outcome Bias.
Flow Efficiency
Flow efficiency (sometimes called Cycle Efficiency) is a metric that gives us a sense of how much time work is waiting. A flow efficiency of 100% would indicate that we are adding value to the work item for the entire time it’s in progress. 50% would imply that half the time we’re working on it and half the time the work is just waiting.
Rapid feedback
One of the key things we’re trying to get with Agile is faster and more effective feedback so that we can make better decisions. This extends into to the technical practices just as much as it does in our meetings and processes.
Self-sufficient teams
A number of years ago, a client of mine had a new feature request come to one part of the company. It was a significant change that would touch quite a few teams to get done and when they asked those teams how long it would take, the answer was somewhere between 10 and 12 weeks.
“Assume positive intent”
When dealing with troublesome or difficult situations, someone will often chime in with the advice “assume positive intent”. Sometimes teams will even bake this into their working agreements as something they should always do. While I really do like the sentiment, if taken literally as a hard rule, this can be dangerous advice.