- 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. Retrospectives are covered in my popular video course Retrospective Magic.
- Work in progress (WIP): Setting initial WIP limits. What to do when we're overwhelmed with WIP
Fractional people
I worked with two teams that shared a database specialist, for a fairly proprietary system. Because she was on two teams, they had her attend all meetings for both teams. Two standups, two planning meetings, two retrospectives. She ended up doing crazy amounts of overtime because she couldn’t get her regular work done during the day. Her days were filled with meetings, and it was only after everyone else left that she got anything done.
Optimizing for time overlap
If we want people to actively collaborate then they have to be working at the same time. It’s irrelevant whether they’re in the same physical room if they don’t work the same hours. If one person comes in early and another comes in late then there is no benefit in forcing them into the same place.
Learning to say no
A team I was coaching was coming up on an important deadline. Specific functionality had been promised for a certain date that was now eight weeks away, and they wanted to know if they were going to make it.
Intent of standups / scrum meetings
The intent of a team standup/scrum meeting is to resynchonize on the work in progress and decide how we, as a team, are going to complete it. If your standup is horrible, then focus on the intent, not the format you’ve been doing. What would you have to change to make the meeting useful?
Understanding the users
My very first professional programming job was at a large bank that had invested in a full UX lab. One-way glass, cameras, and a full setup where we could watch real branch staff using the software we had been working on.
No blockers
When I was a kid, we liked to play with two way radios. I’d say something and end it with “over”. Then my friend would say something and again “over”. The word “over” had no actual meaning to us, except to indicate that we’d finished speaking.
Excessive sub-tasks
I worked with a team once that had gotten into the habit of creating sub-tasks for every little thing they could think of. This list included such obvious items as “write the code” and “test the code” and a typical story would have about twenty of these sub-tasks attached.
Ambiguity in wording
If I say that a thing costs five dollars but I don’t specify if that’s Canadian Dollars, US Dollars, or Australian Dollars then we might all think we understand the price but we don’t, because I used language that sounded precise and yet was actually ambiguous. What I think I said and what others think I said were substantially different.
Definitions of Ready and Done
I keep seeing heated discussions about Definition of Ready (DoR) and Definition of Done (DoD) in a Scrum team. People argue whether they’re part of Scrum and whether they’re necessary.
Monkey Grassing
A common anti-pattern that I’ve seen is managers taking a highly effective team and scattering them across a larger number of teams in the hopes that they’ll take everything they know and make those new teams great. Then instead of having one great team, they’ll have many great teams.