Default Do or Default Don't?

When a chunk of work is dropped into your team’s workstream–whether you call it a backlog, or a bucket, or what-have-you–is the default expectation that your team will do that work? Or is it that the team will consider that piece of work for inclusion?

The ends of the continuum in the software world: “waterfall”, in which everything is pre-planned before starting, is purely default-do. Shape Up is default-don’t: work pitches go to the betting table for evaluation, and only a few get picked up, with no systemic retention for the next time around. Big-A Agile and friends fall somewhere in-between, depending on how you’ve adapted them to your team.

The trouble with “default-do” is that every “yes” embeds an implicit collection of “no"s, so you’re making prioritization decisions implicitly. There may be a discussion around work sequencing that puts the more important (or, more likely, the more urgent) work ahead in the queue, but the default decision is still to do all the things. It also reduces the quality bar for work definition, shape and scope before being assigned to folks on delivery; the impetus is on the recipient to prove why something isn’t ready, rather than on the submitter to prove that something is ready.

“Default don’t” engenders conversation around whether each thing should be done at all right now, including whether the work is sufficiently shaped and defined–and if the answer is “no”, the impetus is on individual people (and not an automated system) to improve the work definition and re-raise it if they feel it’s appropriate in the future.

Where are your systems defaulting to an unexamined commitment to work by default?