Stop Playing Tetris (With Teams, Sprints, Projects, and Individuals)

  1. Pulling “small stories” into a sprint to hit some illusory “velocity” target (even when the stories have nothing to do with a meaningful goal).
  2. Encouraging high individual utilization rates. Optimizing for “looking busy” instead of optimizing for efficacy, outcomes, and flow.
  3. Big-batch quarterly/annual planning whereby some group of managers/planners attempt to “put the puzzle pieces together” and “get all of this done in the quarter” (even if priorities vary drastically).
  4. Asking functional disciplines like UX to “get ahead” of the work, in an effort to work more “efficiently”. This results in an impossible-to-navigate set of dependencies and handoffs (and a lack of information exchange).
  5. Making assumptions about the size/shape of planned work (and the flow of future work) that end up being false. For example, a team will be asked to “move on” from a promising initiative because of layers of dependent plans.
  6. Rapidly reshuffling/rotating teams to tackle an onslaught of projects.
  7. Parallelizing dependent work in the hope that a “horizontal slice” of multiple projects can be completed simultaneously (instead of treating the work as a single project).
  8. Never going back to fix things. The “holes” remain, eating into the collective psyche of the organization.
  9. Ever-increasing pressure on “the teams”. Pushing teams until they crack. Instead of fixing the gaps, management layers on more and more work until the system experiences a spectacular collapse. Teams, inevitably, have to clean up the mess (and are blamed for not “pushing back”).
  10. Banking on that “one piece” to fall into place and save the day. Until then, making no forward progress. When the silver-bullet piece fails to appear…you find the next silver bullet.
  • premature optimization
  • short-term thinking, overly reactive decision making
  • push(ing) vs. pull(ing)
  • chasing high utilization of individuals/teams
  • dividing up tasks/teams/projects
  • ever-increasing intensity (pushing until collapse)
  • seeing parts instead of the whole

So how do you battle the Tetris mindset?

  1. Try to deeply ingrain the idea of “pull” in your organization. It is a huge mindset shift. Pull means that starting something will ALWAYS mean finishing something else. You don’t load people/teams up. You don’t “push” work on teams. Rather, you wait for teams to reach out when they’re ready, and you respect that. You have to trust your teams to do their best without asking them to pre-commit to big batches of work and “stretch goals”.
  2. Stop fetishizing busyness and output. Place a premium on doing more with less. Make craft, thriftiness, and frugality a part of the culture. “Above and beyond” is fine, but it often inadvertently swamps the system. It also incentivizes local heroism over global flow. Focus less on output/busyness, and more on benefits and outcomes.
  3. Leverage work in progress/process constraints. WIP constraints serve as a forcing function for continuous improvement, a catalyst for pull, and a signal that the system is straining and needs some TLC. Think of every piece/level on a Tetris board as WIP. Unfortunately, WIP constraints are counterintuitive: we look to estimates/guesses to “size up” the work and “fill up” the system. This is a recipe for dangerously high utilization rates and long, long lead times.
  4. Visualize dependencies / visualize the whole. When we split things up, we tend to lose the thread. By visualizing things “as a whole”, we tend to make wiser decisions. Instead of six “projects”, we have a single mission.
  5. Do something about the “holes”. Cutting corners creates gaps. We rationalize cutting corners to learn earlier, deliver earlier, and make money earlier. The problem (as we learn in Tetris) is that the gaps add up and add psychic drag on teams and eventually cause collapse.
  6. Map your assumptions. We tend to act based on a web of assumptions (some conscious, some unconscious, some fragile, others robust). Building shared understanding around our assumptions can expose “tangled webs” early, and encourage us to simplify, solidify plans at the last responsible moment, and leave more slack in the system.




Multiple hat-wearer. Prod dev nut. I love wrangling complex problems and answering the why with qual/quant data. @johncutlefish on Twitter.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Development From Scratch VS Boxed Solutions: What is More Profitable?

Learning to google better with Rails

When a permanent fixture suddenly stops existing

Fantasy Service: The Great Cache Game — Part 1

How to Add Source Column Panes in RStudio

Design Patterns in modern .NET application

Using kerbrute tool on my home lab

Monthly traffic report: 2016.10

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
John Cutler

John Cutler

Multiple hat-wearer. Prod dev nut. I love wrangling complex problems and answering the why with qual/quant data. @johncutlefish on Twitter.

More from Medium

BURN THEM ALL — Sprint slayer🗡️

Why You Suck at Scrum: The Development Team

Is the User Story done? It isn’t, if you don’t measure it!