Legos and Sandcastles
I got some great feedback today about an upcoming talk I’m working on: “You should come up with a personal story people can relate to, perhaps about your son, and use it to teach a real world agile concept.”
Awesome idea, right? It’d be nice to not have to show that same tired scrum backlog + ceremonies + sprint cycle diagram. Frankly, I’d even like to avoid showing the skateboard/scooter/bike/car diagram. What I need instead is a good story to tell so that people don’t even realize they’re learning agile.
OK, so how about Legos? Oooh! Yes, I thought. I got excited, thinking about how I could make a fun version of the Scrum diagram with Lego illustrations. You get a big box with the picture on the front. That’s the product you’re going to build! Inside the box are bags, numbered 1 through 5. Those are what I might call Product Increments! Hmmm, so good so far. You can work with multiple people, sharing the work as a team… good. Once you put the wheels on, you can test stuff along the way… good. The instruction sheet is a set of very specific requirements, broken down into simple steps (user stories) that any team member can follow. Excellent.
But here’s where it goes awry. Have you ever put together a big set in like 119 steps and didn’t realize until you got close to the end that you missed something important somewhere? Maybe two large subsections just don’t go together the way you’d hoped. Maybe the axles were put in the wrong place. Or you used the wrong sized brick somewhere and now the Porg mouth doesn’t open when you move his tail like it’s supposed to. The analogy breaks down a bit there. In fact, if I wanted to, I could spin it the other way around completely. Building something with Legos is more like using a Waterfall process. You have very specific, unchangeable instructions. There is a predetermined sequence of events. No innovation or adaptation is required. All of your inventory and costs are determined up front. And you won’t know until you’re completely done with the entire project whether the final product works as planned or not… Damn. Not so agile.
So, then, I was stuck. But I shared with my wife the story — how I’m working on this talk and looking for an analogy to pull together something personal and a real world agile story of trial, error, learning and perseverance. She didn’t even hesitate. “How about sandcastles?” To which I might have replied something like “O.M.G. That’s awesome!”
Imagine your goal is to build a big sandcastle near the Ocean. You don’t even have to know what it looks like in advance. In fact, whoever you have working on it with you might even have slightly different ideas, and that’s OK. But one thing is clear (about your product), it must stand tall, be made of sand and be super fun to play with like a castle. Through experimenting early on, you know you need water for the sand to stick and be moldable, so you build it right near the Ocean. Maybe your whole family helps; Dad works the shovel to make a big pile, Mom does the patting down of the sand to help it stand tall, and the 12 year old son is the designer and visionary as Product Owner.
Most of the way through being done, a big wave comes and splashes hard into your creation and rolls right over the castle, melting it into a very non-castley looking rounded pile of sand. OK, first setback. We learned something. Don’t build too close to the water’s edge. Someone check to see if the tide is going out or coming in. Let’s start building it back a bit further. Do the same thing: Dad grab the shovel, Mom do the patting, but this time let’s build a big moat with a wave-guarding wall up front! Great, looking good. Uh oh. We dug too deep while we dug the moat and now we have some water collecting in the moat and it’s wearing down the front embankment and the main wall on the front of the castle. OK, another lesson learned. We fill in the moat a little and collect sand from further away to reinforce the wall and stabilize the front of the castle. Now, we’re almost done. But the Product Owner declares, “We have to make it taller with a big turret and a flag on top. I also want a big door and some stairs around the outside.” And the team responds immediately with confidence: “No problem!”
I’ll make sure to dial up the cheese factor as I tell this story. My family loves going to the beach and building sandcastles. And it’s funny, after working on agile software and building sandcastles for so many years, it’s surprising I never made the connection. But, I think I really like this analogy. A team with different skills can communicate, work in stages, collaborate, react, adapt and learn through all the difficulties presented while building a sandcastle and the product evolves as you go. What do you think?
If you’re at all interested in what the rest of my talk includes, you can catch a peek of some of the ideas in this post titled “So you want to be agile?”
Better yet, if you’re in Columbus, come catch one of two slightly different versions of the same thing at ATP on Feb 13 or Columbus Web Group on Feb 28.
About the Author: Brian Link is the author of AgileMisconceptions.com (also available on Amazon) and the owner of Practical Agilist, LLC. Brian provides leadership and coaching services as an Agile Coach at LeanDog. Follow Brian on Twitter @blinkdaddy or LinkedIn, and subscribe to his newsletter.
