Back to Blogs

Using Agile and MVP to Build an Arcade

  • Publish Date: Posted over 3 years ago
  • Author: Todd Sussman

Using Agile and MVP to Build an Arcade

In my world, every user story we deliver should start out as some high-level outcome. This could range from reducing support call times by N% to simply adding top line revenue. But today, we aren’t going to just talk about software delivery, but rather how I used an Agile mindset and a clear understanding of MVP to build an arcade for my family. Those of you who are quarantined with kids at home this month - maybe this can spur some creative ideas!

We are a gaming family, and consequently, our formal dining room is a family game room. In December of 2018, my wife set a family new year’s resolution to improve our gaming experience. At the time, we had a table and a cabinet that stored all of our games. Improving the experience was not going to be a stretch.

You should be aware that I am a hobbyist woodworker, so when my wife suggested we make improvements, I wanted to make something. In larger agile organizations, PI Planning, or Big Room Planning, has become very popular. And just like those planning sessions, we as a family gathered in the game room, reviewed the outcome we were trying to achieve, and then started discussing what could help us get there.

My youngest son wanted a Harry Potter inspired puzzle box table that we could store the games in and play on (he saw it on YouTube). My oldest suggested we build a simple table topper so the dice don’t fly off the table, and we could remove the game from the table without finishing it. I didn’t think that was impactful enough, and suggested we build a full-fledged gaming table with a sunken pit, LED lighting, cup holders, and a sleeve you could pull over the gaming surface if you need to take a break from the game. Then, my wife suggested a retro arcade. She had also seen it on YouTube. Not only can we play the arcade, but she pointed out it would also supply much needed storage. We watched the video, got excited, and agreed a retro arcade sounded cool.

We couldn’t just run off and build an arcade. Having watched the video, it was clear there is more to building an arcade than cutting some wood and screwing them together. This is true for most of our projects; even simple requests can have profound impacts.

We needed to define the features that made up an arcade. Things like the emulator, control panel, tv orientation and cabinet design. And even within each of these features, there are several epics. I could run arcade games and/or console games. The control panel could be as simple as a USB gamepad, or as complex as a fully modular custom console. The cabinet represented a decision that had permanence, so while other decisions could be made a little quicker knowing we can back out of it, changing the cabinet design was far more expensive and time consuming.

Using Agile and MVP to Build an Arcade

Eric Ries coined the phrase MVP in his book The Lean Startup. In it, he talks about the least amount of work required to validate assumptions and answer critical questions about what we intend to build. Using that that as our reference point, we installed Retro Pi on a Raspberry Pi (I already owned a 3B), installed a MAME emulator, configured some basic games, used an Xbox 360 controller, and plugged it into our TV. We had our first prototype! We had invested almost no money, and very little time, yet had a fully functional example of working software. I am not suggesting that this MVP is something we could have released to the market; after all, it was made up of borrowed parts from other people's products. But it was exactly what we needed and when, so we could validate assumptions we had made before starting the project.

For example:

  • Will the kids play arcade games or was this just for the “adults”?

  • Which games did the kids want to play?

  • How will game choice influence TV orientation?

  • What button combinations do I need to support for the games we play?

  • Can we get the kids to play standing up?

In case you were wondering...

  • Yes, the kids loved arcade games, and even the 80s games were popular

  • They liked Pac-Man, Donkey Kong 3, and Super Mario the best.

  • This led to the discovery that they wanted Super Nintendo on the arcade.

  • Since they liked the Super Nintendo as much as they did, we went with a horizontal TV.

  • The kids rarely played anything requiring more than 2 or 3 buttons and a joystick.

  • And yes, if The Arcade doesn’t count as screen time, they will stand.

Having validated the idea as best we could, we set out to deliver our first Minimum Marketable Release. This is something that will deliver value to both our customers as well as ourselves. In other words, it should be usable in the market.

I mentioned the permanence of the cabinet earlier, and this is like the architectural patterns we choose to implement. I was lucky in that I knew I wanted a cabinet that had the same look as Moon Patrol, and we knew the whole bottom half would be storage. We tried to limit the opportunities for errors by only building as much of the cabinet as was required. We installed the light box without a marquee (we could have forgone the lights, but I had them already), and the control panel was slapped together (I had to learn how to do the wring) for a single person with an XBox controller for the second player. But it was in the house, and we were playing with it.   

Then came two more quick releases. First, we added a marquee and that cool 80s plastic trim. Then, in a major release, we built out a two-person control panel that also added a roller ball. Eventually, we added doors to the cabinet (nine months later), and my son painted them a month after they were installed. The arcade is a constant work in progress, much like our software delivery products.

I love when my passion for agile software delivery and my personal life get to intersect in such an obvious manner. Taking advantage of a lean mindset allowed us to validate most of our assumptions. Of course, I didn’t validate the ones about my behavior, but we’ll save that for some other blog post. Small incremental and iterative deliveries ensured we were able to focus on what we needed and deliver it with quality. The goal should always be to understand how the real world will use our products while we figure out how to build it.