Skip to content

Jenga Analytics

You hold your breath, steady your hands, and deftly pull a block out from the tower. As you move to place the block on top of the tower, you pray for it to hold long enough to complete your turn.

The game of Jenga rachets towards instability by design. The only guarantee is the tower will eventually fall and someone will lose.

What if I told you that your analytics development process may be a game of Jenga.

Ad-hoc models are built, tweaked, passed around, manually refereshed with more data, and tweaked more. Your rickety analytics tool is constructed brick by brick until one day it collapses at the wrong moment.

Sound familiar?

Let's use the classic game to help us build a better process.

Rules of Jenga:

  • If the tower falls on your turn, then you lose - no one actually wins.
  • Once you touch a block, it has to come out - no testing allowed.
  • Once you pull a block, it has to be placed on top - no way to remove it.

Behaviors that ensue:

  • You make changes only to reduce the likelihood of personal failure.
  • You hold back information on what blocks may be safer to pull.
  • Your turns slow down dramatically as the game progresses.

What can we do to change the incentives?

The goal should be to build the tower as tall as possible together. The agreed-upon rules should allow for testing, re-dos, and removals. Then, our behaviors will reflect both the motive to expand collective opportunity and the diminishing fear of personal risk.

Remind me - how does this relate to analytics?

Imagine a set of team rules and tools where:

  • You can confidently experiment with changes to a data model in a separated development environment with no chance of messing up production.
  • A peer can thoroughly review the proposed changes without having to painstakingly re-evaluate the whole thing every single time.
  • You can measure what will change (ie. data diff) before an edit is made in production.
  • You can run tests to ensure only valid changes are introduced.
  • You can communicate with your stakeholders on the upcoming changes before they are made.
  • You can deploy small changes easily and if something goes wrong, then you can roll it back.

Now our behaviors evolve to:

  1. More confidence in updates so changes are made more often.
  2. More frequent changes so each update can be smaller and more contained.
  3. Smaller releases so bad updates are detected, reverted, and resolved more quickly.

As an organization chooses to invest in the maturity of the analytics development lifecycle, then the game of Analytics Jenga becomes something different altogether. The once unstable tower of data assets (dashboards, visualizations, models) can now reach new heights and stay there.