Excite Bike is Software Developmentfeatured

When reflecting on how my software teams are able to deliver high quality releases, it occurred to me that it’s just like a game of Excite Bike. 

It is because we approach software development like Excite Bike, that we have a high quality, visible, and predictable products that we can all be proud of.

Excite Bike is a motocross video game from the original Nintendo console.  It was a staple in the childhood of many.  The objective of the game is to complete the race course within a certain amount of time while trying not to overheat.

If the rider is a software team and the race track is a release, the temperature is the level of defects and crashes.  When playing the game, the players do not schedule cool-down periods for the bike but rather do it real time as the rider progresses through the race track.  It’s fluid.  It’s organic. 

Move fast for a sustained period of time and the temperature climbs to critical levels.  Keep the temperature too low and you don’t complete in time.

Scheduling and prioritizing bugs and crashes with features is like a game designer putting in fixed areas on the race track to cool down and speed up.  This is inefficient without knowing the potential of the team (type/performance of the bike) and the context of the specific ride.

Always strive for high quality

High Quality is the goal for us and is made explicit at all levels of our processes.  Along with the QA signoffs needed on the various items of work, we also consider a story “Done” only when it does not introduce new bugs and crashes. 

We treat quality as something that is separate from features.  Quality is not scheduled or road-mapped; quality is considered throughout the development of a release by all members of the team.  Our Product Managers will highlight the bugs and crashes which would block a release but they do not, as a matter of course, prioritize defects against features. The teams squash blocking bugs soon and early and constantly monitor and manage non blocking bugs. 

You can’t fix what you can’t see

What’s great about the Excite Bike user interface is that the temperature gauge sits front and center on the screen throughout the race.  Having it visible allows the player to focus on the race while maintaining optimal riding temperatures.

We do the same while building our products.  Crashes and regression bugs are surfaced on the Jira board in a distinct swimlane.  This allows for the team to quickly understand how many defects are piling up.  The quantity of issues in this swimlane is equivalent to the Excite Bike temperature gauge.

Additionally, any new regression bugs are brought up at the beginning of each standup to further highlight their existence if they haven’t already been addressed.

Shared ownership

Our Product Managers do go through the bugs towards the latter end of a release to highlight the blocking regression bugs but it is very much the responsibility of the team as a whole to keep the overall defect rate down regardless of the blocker status designated.

During peer reviews, developers will compile the code and peer review to verify quality as our first line of defense.

Then we have functional QA, regression QA, and final product acceptance as further checks to quality.

When the entire team is invested in quality as a goal, you organically gain efficiencies in tackling any defects that exist and naturally gain a level of preventative coverage.

Predictability results in speed

With Excite Bike, tackling a high jump with the temperature meter on full results in the bike not clearing the jump or overheating when trying.  It’s important for the squad to maintain manageable levels of defects so that we do not “wipe out” (missed releases) when faced with a challenging work.

Enjoy your software development like a good game of Excite Bike.