Too Much Work In Progress
I’m working on a side project to help with a common problem: doing too much at once. I strongly believe that a productive team tries to focus on one thing at a time, and that juggling several pieces of work is the sign of an overloaded, badly-managed or underperforming team.
To figure out useful proxy metrics for too much “work in progress”, I surveyed people on Twitter and the Software Craftsmanship Slack to find out how they measure it. Here’s my distilled results.
- Too many branches, including local, non-pushed branches.
- Too many open pull requests.
- No movement on work in review (which may be pull requests).
- Too many tasks in progress (perhaps measured as a multiple of the number of people).
- Too many tasks in the backlog.
- One face on too many tasks.
- Too many unresolved issues/bugs.
- Failing builds.
- Failing deployments.
- Too many builds in progress.
- Too many commits since the last release to staging/production.
- Informal comment-based protocols for merging pull requests—a voting protocol could help.
- Increased one-on-one chatter over instant messaging.
- A rushed atmosphere during breaks.
- Size of commits—number of branches, number of lines changed, etc.
- Time between commits.
- No visible progress each day.
- Large amounts of context switching.
- The number of hours worked increases.
- Many people off-sick.
For now, I’m just looking at the top two or three, but I hope I can factor most, if not all of these into the project and help teams whittle down their work in progress.
If you enjoyed this post, you can subscribe to this blog using RSS. I personally use Feedly; you can subscribe here.
Maybe you have something to say. You can comment below, email me, or toot at me. I love feedback. I also love gigantic compliments, so please send those too.