The Netflix documentary “The Speed Cubers” inspired me to learn how to solve a Rubik’s Cube. I followed the guide from Robbie Gonzalez and one piece of advice stuck out at me: “Solve pieces, not stickers”. This is profound advice is the most important part of solving a Rubik’s Cube.
If you ever tried to solve a Rubik’s Cube on your own, you probably keep twisting the cube edges until you get a single face all matched with one color. This is hard enough to do if you are turning without plans! You’ll probably examine the rest of the cube and find it hopelessly scrambled. With no idea how to solve the rest of the cube, you’ll probably give up and look for an easier puzzle.
I went through this failure pattern with the traditional 3×3 Rubik’s Cube. I even bought a simpler 2×2 Rubik’s Cube, thinking it might be easier for me to solve. But with random turns, I still failed on the 2×2. The reason I failed is I was trying to solve stickers, not pieces. I looked at a 2×2 cube as having 24 stickers – four each of white, red, blue, green, orange, and yellow. The key insight was looking at a cube as having eight pieces.
Looking at a solved cube as having pieces, several insights snap into place:
- There’s only one piece with white, blue, and red.
- That piece is always to the left of the white, red, and green piece.
- It’s always to the right of the white, blue, and orange piece.
- It’s always under the red, blue, and yellow piece.
Solve pieces, not stickers!
Solving a Rubik’s Cube is done by methodically moving a single piece into place until the cube is solved.
(The companion advice to “solve pieces, not stickers” is to solve layers one by one, from bottom to top, until the cube is solved. The advice varies by cube size, but the principles hold, at least for the 2×2 and 3×3 lessons I’ve followed.)
The rest of solving a Rubik’s Cube is beyond the scope of this post. But I was struck by the beauty and simplicity of the insight “solve pieces, not stickers”. It made me think about what else in my life could benefit from a simple reframing. I landed on software development generally and the Agile process specifically.
Agile is a cool name – it even sounds fast – and everyone wants to be Agile. There are plenty of arguments about what is Truly Agile, how one can be more Agile, along with courses and certifications. Becoming Agile is treated as an end state, not just a means to an end. This feels like twisting a Rubik’s Cube blindly to match up a bunch of stickers.
The key insight from the original Agile Manifesto is the focus on valuable software. There are twelve principles but they are all context-dependent:
- Iterations are generally good because you can’t know everything up front
- Smaller batches are generally good because you can get feedback sooner
- Self-directed teams are generally good because it motivates the team
It’s much more instructive to look at Agile as a set of useful ideas rather than a dictate. For a largely independent project, the ideas are a great way to get feedback that you are Building The Right Thing. For other projects, not all the principles are useful. Is it better for a team to be self-directed or follow an enterprise’s architectural patterns? If you’re flying a probe to Saturn, you’re not getting many feedback cycles!
The key to successful software development is understanding your context and applying solid principles useful in that context. Maybe those principles are Agile and maybe they’re not. (Probably, you’ll use a blend of those principles.) That’s fine! Your goal is producing valuable software. “Produce valuable software” is as useful as “solve pieces, not stickers”.
Solving for stickers is solving the wrong problem. Becoming more Agile is solving the wrong problem. For Rubik’s Cubes, solve pieces (not stickers). For software, understand your context and apply principles that make sense to deliver valuable software!
