What I Learned About Agile By Building A Giant Carrera Racing Track
Originally published on October 07, 2019 by Udo Wiegärtner
Last updated on February 10, 2020 • 13 minute read
Here I stand, with duct tape in my hand, trying to fix an insane series of 39 loops of a giant Carrera slot car racing track. I screwed up, nothing works and time’s running out. I used to think that I’m better than a third-class hotfixer. But wait – I probably should start my story at the beginning:
🏎️🏁 A few months ago, my colleague Patrick at Paessler AG announced his crazy plan to build a giant Carrera race track in our office. The idea was to demonstrate that we can monitor even unusual tech with PRTG in a fun way. He asked the whole company for help and of course I signed up as one of approximately 20 track builders. Turns out, the whole project had so many similarities with the work of Agile software teams that I wanted to share my key insights in this article.
Upfront Planning & Estimations
We had almost 500 meters of race track at our disposal, along with huge piles of curves, ramps and more than 40 cars. The project's mastermind Patrick did a decent amount of upfront planning to calculate the amount of required parts and to design a rough blueprint of the entire track. Hearing Patrick’s kickoff speech reminded me that upfront pre-planning makes sense and that the work actually starts way before the first development sprint starts. I guess, I sometimes lacked the respect for the all the initial work done by Sales and Post-Sales in the past. Agility doesn’t mean starting headless.
We planned to start Friday after lunch and finish Saturday afternoon. Well, we fell behind schedule very soon. Why is it that we tend to trust our estimates, even if 90% of the team never used the given technology – building loops with Carrera or with C++ makes no difference.
Yes, You Can
I never had a slot car track as a child, so I started as a complete newbie. I heard Patrick talk about a series of 39 loops and race tracks on the ceiling and thought, “There's no way we can build such a thing! The guy is nuts!” (if you look closely in the video you see a guy giving a disbelieving stare while Patrick describes his plans– that’s me in the very moment I just mentioned).
Nevertheless, after a while I got familiar with building tracks and started to think bolder. I had no idea what I was capable of before I started doing it.
For a Product Owner, it’s completely worth it to dare sharing a big vision that’s beyond mediocrity and to give the team time to tame the technology. The product owner might just be amazed at a result that is beyond mediocre.
Humility And Loops
My part of the track was a series of more than 30 loops. As an Agile coach, I should have known to first build an initial loop and test it. Then, add a few more loops and test again. Add even more loops and test again. You get the picture. Well, I didn’t.
We built the first loop and even tested it successfully. Testing done. We didn’t even need pillars for stabilizing because the loop was that stable. We felt more than prepared to create the whole line of loops without further testing. Guess what: one can’t extrapolate the behavior of a system by just testing one tiny increment. After finishing all 39 loops we realized that the race car added a little vibration with every loop it passed. Halfway through, the vibrations added up and the track shook like a dog’s tail, catapulting the car away. Gosh!
It was only then that we realized that we had to disassemble and rebuild the whole structure because we were no longer able to attach the pillars. I probably don’t have to mention that none of us ever looked at any kind of manual (RTFM, you know). Now that I write this section, it sounds stupid and ridiculous. Well, it probably was. Mature Agile software teams use concepts like “Continuous Integration” and “Continuous Delivery” to not fall into the trap of integration done too late. In our Carrera project, it was my little son who helped us understand that.
Eat Your Own Dog Food
Some colleagues brought their kids to help with the track and so did I. My son taught his old man some lessons. His first lesson was that it makes no sense to build a Carrera track and not race on it. The little one was instantly and continuously racing the segments we just built – just for the sake of it. Besides the fun of racing that looping-madness, it did the whole trick of Continuous Delivery.
The second lesson from our kids was about the power of diverse teams. The excitement of the children was absolutely contagious and their playfulness made us come up with ideas we never would have thought of. Daring to think wild, to be playful and including assumed rookies beats every team of specialist-clones when it comes to Innovation.
“Didn’t You Test It?”
As my coworker Bruno mentions in the video, we tried to make the track as unnecessarily complicated as possible. That involved the kitchen sink as well. The idea was to use the running water tap as a waterfall so that the race car could pass behind it.
The car had to vertically elevate up the kitchen worktop and then turn using a loop. We tried very hard to streamline the track so that the car could gain enough speed to make it up to the top. It took us some time but in the end it worked. Well, it worked a while. Some other teams modified the section of track just before our kitchen climb. Nobody bothered to re-test the kitchen sequence because the change seemed too small and the sink was around the corner and out of sight. In addition, people switched teams quite often. Too much team-churn resulted in a lack of overall responsibility for each feature that was built. You may have observed this pattern in unstable Agile teams as well.
When the camera team showed up on late Saturday afternoon (did I mention that our time estimates were lousy?), every car came off the track in the kitchen and someone shouted, “Didn’t you test it?”. Without having the context of the Carrera project, you could have had the same exact conversation in any Agile software team. We just didn‘t agree on the fact that our team’s “Definition Of Done” should have, of course, included regression testing. Priceless.
Bottlenecks And Big Visions
Patrick was the brain of the project. He provided the vision, was the owner of the blueprint, did the upfront planning, and was the only one who had already built a Carrera track that was bigger than normal. In German we have the term “Wollmilchsau” to describe a person with so many skills ("Swiss army knife" in English). Although it helped a lot to have him managing all the details, Patrick was at his best whenever he shared the project’s vision and encouraged us to think even bigger. Again, it struck me like lightning how valuable a product owner is when he has time (and talent) to spread his big idea.
As an Agile coach, I should have helped Patrick in creating a Kanban board to help us visualize our work. I didn’t because I was knee-deep in technical debt. You probably know the blues when your Scrum master has to write code as well, don’t you?
For me it was one of the biggest "Aha!" moments to realize that a team can achieve crazy cool things if there is a vision and someone communicating it while having faith in the creativity of the team and without interfering with the tiny details.
Working on a project I felt connected to created a kind of flow that made the hours go by in a flash. I felt so much more connected to the folks who built this giant Carrera track with me. Building stuff together creates team spirit and every Agile team can tell you that purposeful work can beat even the occasional team pub crawl. You might disagree with me on the drinking part, but I guess you are with me on the purpose.
The two days building that giant Carrera racing track were not only the best for me in Team Paessler so far, but also those with the most "Aha!" moments about Agile development. I didn’t expect that.
At the end of the day people involved in complex projects facing the same obstacles falling in the same kind of traps. It's good to remind ourself of this behavior. For an Agile team it doesn't matter if a loop is made out of Carrera tracks or out of C++ code.
Hotfix Expiration Date
My article started with me trying to fix things with duct tape. It wasn’t until the system test phase of the project that I realized that the tape I used to fix the long line of loops had lost its bonding on the carpet after a few hours. All the cars got lost in the wobbly track. Again. Although some hot-fixes have a long life in our software projects, most of them have an expiration date. I hope I can fix those stupid tracks before the camera team shows up soon to shoot the race cars in action. I learned from my software projects that if in a hurry, just add more duct tape. I promise to do a proper refactoring next time.
I’d love to hear what you think about my Agile Carrera experience and what aspects you can add. Thank you for your comments below.