- Metrics: Links to all my content on metrics and probabilistic forecasting have been collected under Mike's Hard Metrics.
- 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.
- Improvement: Continuous improvement in general. Understanding the metaphor of "lowering the water level".
- Flow: Understanding the cost of interruptions, and the kinds of waste that gets in the way of flow.
- Meetings: The common problems with meetings. Improving the standup / daily coordination meeting and your retrospectives.
- Work in progress (WIP): Setting initial WIP limits. What to do when we're overwhelmed with WIP
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.
Risk Management
Yesterday I went on a guided hike to teach people how to safely hike through bear country. Specifically grizzy bear country. Unfortunately, we didn’t see any bears, but we did learn an amazing amount about them, and saw some spectacular glaciers and alpine terrain.
Gaming metrics
When I suggest that people will game whatever metrics we put in place, I’m often met with shocked indignation. We would never game the numbers! And yet we do.
OKR’s for Quality
The topic of OKR’s for quality have come up in multiple different contexts, across multiple clients, recently so perhaps it’s worth exploring.
Jira Metrics 2.12
I’ve released JiraMetrics 2.12, with a number of bug fixes, and a new chart that I’ll describe below.
Prioritization
There two different times that we need to prioritize work and we should be using completely different approaches to that prioritization, for each stage.
Wait states
The metrics covered in our Flow Metrics Basics class show how to measure different aspects of flow, but those metrics don’t in themselves, show how to improve the flow. We’ll look at one way to improve now.
Playing the long game
If I was planning to disband my team this week and I only cared about what they could deliver in a couple of days then I’d be focused on making sure that everyone was doing that piece of work that they were most skilled at.
Building the right thing
When I’m working with a development team, I’ll often start by having them walk me through what business need they’re solving for. I’m less interested in the code or the architecture until I’ve first understood what problem we’re trying to solve.
No single right answer
All too often we focus on a single problem and make statements as if solving this one thing will solve everything. While that one thing might certainly make things better, it’s never the only answer. Everything we do is within the context of a complex adaptive system and changing any one thing will have ripple effects everywhere else in the system.