For a year or two, I have been using Tetris as a metaphor for a slew of software product development anti-patterns. It works on the individual, team, sprint, project, program, and organizational level. And not just for development…it works wherever people are coordinating to do work.
This is no knock on Tetris. It is a great puzzle game and it IS possible to be “good” at Tetris. When I talk about Tetris, I’m talking how most people experience the game.
We all know what Tetris “feels” like. It’s a fun game. But as Murray points out, there is an element of futility and masochism to it as well. It’s stressful! Now imagine you’re the blocks and pieces. Imagine that the gameplay is not within your control. That’s how working on the front-lines in software product development can feel like sometimes!
Some examples of [Sprint, Feature, Team, Project] Tetris in software product development include:
- Pulling “small stories” into a sprint to hit some illusory “velocity” target (even when the stories have nothing to do with a meaningful goal).
- Encouraging high individual utilization rates. Optimizing for “looking busy” instead of optimizing for efficacy, outcomes, and flow.
- 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).
- 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).
- 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.
- Rapidly reshuffling/rotating teams to tackle an onslaught of projects.
- 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).
- Never going back to fix things. The “holes” remain, eating into the collective psyche of the organization.
- 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”).
- 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. You get the idea. There are some common themes:
- 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?
Jabe Bloom hits the nail on the head with this Tweet:
- 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”.
- 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.
- 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.
- **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.
- 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.
- 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. The one nice thing about Tetris is that it is very visual! The reason that it serves as a great anti-pattern metaphor is that you can see/touch/hear the collapse. Figure out a way to bring similar sensemaking to your organization. That way, if you DO play Tetris with teams, individuals, projects, and programs…the net effect will become painfully obvious.
Your biggest danger is playing Tetris (and suffering the impact) but having no way to reflect on that because it has become too ingrained in your culture.
Q: How do we know that we aren’t caught in a Tetris game?
A: On a super high level…a sense of sustainable (and effective) flow.