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.