Over a million developers have joined DZone.

The Rubik's Cube and Agile

DZone's Guide to

The Rubik's Cube and Agile

How is the infamous Rubik's cube related to Agile? Sometimes, if you try to do things differently, you might, just might get faster.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

It's been a while since I did my last major post. Actually, before Christmas. So, what happened? I got myself a Rubik's cube (Well, a cheap knock off from eBay) and learned how to solve it.

My solved Cube

I watched YouTube videos and learned the beginner's methods. I can now, after 30 years of getting my first cube, solve it.

I got lots of practice at solving. I get my five-year-old son to mix it up. He loves doing that, and now the quickest I can solve the cube is about one minute and 37 seconds. Most of the time, it's around two to three minutes.

Sounds impressive, but it's actually pretty pathetic. The world record for a solve is under five seconds. Yes, 4.73 seconds to be exact.

Now, the method that I'm using (if I didn't know any better) could get me down to around a minute if I get more practice and get better. If I didn't know any better about the world record, I would think that that would be impressive. However, in order to get faster, I need to change the way I solve the cube.

So, how is this related to Agile? Well, a lot of people think that getting a task done quicker means you just need to work quicker. Cracking the whip, giving carrots, etc. will get things done quicker. In my above example with the Rubik's cube, that will only reduce my time by about 33%. Still an impressive number, but sometimes, if you try to do things differently, if you learn the expert method of solving the cube (which by the way is a lot harder to learn than the beginner's method), you might, just might get faster. In fact, when I start trying the expert method, my solving time will get significantly worse before it gets better. I have read that I can reduce my time comfortably down to 30 seconds. That is a 60% reduction of my current best. The same thing can be done potentially with any task up to a limit.

So, if you are trying to increase your personal or team velocity, remember you are trying to keep quality at a high level, not skimp on any value. Then, think about trying something differently. If the method has been tried and tested by someone else, stick with it. Your velocity might suffer in the short term as you get use to the new way of doing things. That's OK. You're learning. Stick with it and you may find that as you get better, you will get significantly faster.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

agile ,agile implementation ,work life

Published at DZone with permission of Holger Paffrath. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}