Learn About the Agile Methodology by Watching a Toddler Solve a Puzzle

Back when I was first cutting my teeth in the working world, Agile Methodology had just started being a buzzword. The manifesto was written in 2001 and our company was still chasing waterfalls, like TLC in the 90's. We started implementing SCRUM, poorly, sometime between 2010 and 2015. We were really trying, except doing it all wrong. Meetings were still scheduled to plan when we would plan for things. There was a deadline to march towards and we made the estimates work to fit that timeline.

It was awful.

Originally posted on TeachingTechLeads.com

My new company is a bit better at it. At least my team is, the rest of the floor and our upper management? Not so much. But, I finally found a way that made it all click for me.

I taught my toddler to solve a puzzle, using quick iterations and feedback loops.

Up Front Design in Puzzle Solving

I was sitting on the floor with my son, trying to lay out some basic patterns for how to solve a puzzle. This one was tough, he was zoned in on a hippo and had completely forgotten about the half finished monkey in the tree on the other side of the picture. He hadn't even found all the corner pieces yet!

I, of course, have been doing puzzle solving since the 80's. I know the ins and outs. I have a list…

• Setup the puzzle box, so I can see the reference material - Requirements Gathering
• Flip over all the pieces, so I can see what we're working with - Architectural Design
• Separate the border pieces, so I can lay the groundwork - Context Design/Framework
• Group the pieces by shared color/context, so I can create work divisions - Container Design
• Build out from a corner, one grouping of pieces at a time, so I can complete the entire puzzle in one fell swoop - Implementation

Seems logical right? I can't know where I'm going until I know everything about how I'm going to get there and how I'm going to turn this one big pile of pieces into a masterpiece.

Agile Methodology in Puzzle Solving

That's not how my kid approaches it. He dumps the puzzle box over and dives in. This is the rough overview of his process:

• Dump out the puzzle
• This is a hippo, I'm going to put this hippo piece here
• And this is a Tiger
• But this is another HIPPO!
• Good, the hippo is done, and it looks like it connects to something with long spotted legs, let's just see where this goes if I connect it to this other one
• Oh man, I found a monkey, where does this monkey go? Another monkey! Awesome.
• Dad said something about a giraffe, I guess that neck piece should go in between the body and the head, that makes sense.
• THERE'S A PANDA!

We're putting together the same puzzle, but he's having way more fun. His approach resonates too, let's see if we can break it down.

• Get it all out there, lay out the high level solution design.
• Start working.
• Did you finish a requirement? Cool, release and move on to something else.
• When working on the next requirement, did you learn something about your previous requirement? Great, update it and re-release.
• These two things pair well, we can connect one implementation to the next to fulfill the next requirement. Then release.
• Hey, we got some feedback from the client that something doesn't look right. Great, we'll add it to the next release cycle. Thanks for the feedback.
• THERE'S A PANDA!

Why My Toddler is Smarter Than Me

Subheading: Because he takes after his mother.

While my go to was the old waterfall style of starting only once I knew exactly the route I was going to take towards completion. And then once we start, we head forward and out in all directions, like Romans conquering everything in sight.

My kid, on the other hand, would knock out some low hanging fruit, and then move on to something else completely. Opposite side of the puzzle, who cares, this looks interesting for the moment and maybe it will connect with the other chunks I worked on at some later date. Whenever I offer a suggestion, he takes it in stride and applies it to things he may have made a mistake.
Mistakes are completely fine when you have a quick feedback loop and can correct them.

Key Takeaways

I think that's the biggest part of the Agile approach that has always hit home for me. Quit feedback loops, fast and frequent releases. Get the solution in the hands of the users and listen to whatever they have to say, often.
There are tons of other lessons we can learn from watching a toddler figure out a puzzle and a lot of them line up with the Principles in the Agile Manifesto. Like, I didn't think it'd be this close when I started writing this entry, but it's pretty spot on.

1. Early and continuous delivery of valuable software[puzzles]
2. Welcome more puzzle pieces
3. Deliver parts of the puzzle frequently
4. Cooperation between puzzle solvers
5. Trust those other puzzle solvers…
6. Especially when they're sitting right next to you
7. Pieces that fit together is the primary measure of progress
8. Sustainable development(maybe not this one, we take lots of breaks)
9. Not so much
10. Not so much
11. He reinforces his own patterns every time he does the puzzle
12. We sometimes talk about how we can connect pieces in a different order to see a different outcome

I mean, some of these are a stretch, but a lot of them are in line with the original Agile Manifesto. So, out of the mouths of babes?

Yes, Mr. Beck. You are in like minded company with my three year old. I think you'd get along swimmingly.

Callouts

Have you guys ever had a tech pattern or paradigm just click for you one day when you were doing something no where remotely related to it? I love seeing real world examples reflect things that I use in my development, like... solving puzzles.