Marginal Gains: What Software Development Can Learn From Riding Bikes

They say that practice makes perfect. Take learning a new language for example. Developing fluency is as simple as learning a single word —then voilà!— every other word and syntactical construction falls neatly into place, right? That's not the way it works. When learning a foreign language, you build up your fluency one word at a time, adding new vocabulary as you internalize what you've previously learned. You practice your sentence construction and slowly refine your grammar. You move forward bit by bit, building your skills in the process. Learning a language is an iterative process.

Software development is similar to learning a new language. Multiple languages to be exact, and coding is at the heart of it. Gaining proficiency requires continual practice. Human nature runs counter to gradual progress and iterative processes though; we want learning to be enlightenment, a watershed moment. While radical progress is always a thrilling prospect, there's much more to be gained through small, continual improvements. We call those improvements "Marginal gains."

British Cycling and the Marginal Gain

Dave Brailsford made the concept of the marginal gain famous when he was named performance director of the British Cycling Organization in 2003. Here's his story in a nutshell.

The British Cycling team had a long history of failure. Their performance in both the Olympics and the Tour de France were both dismal at best. The team had only won a single gold medal in 100 years, and they'd never come close to winning the prestigious French race. To the outside observer, it would seem that a sweeping programmatic change was necessary in order to rehabilitate the team. Throw out the old playbook and start brand new. But that's not how Brailsford saw things.

Mr. Brailsford believed in the power of incremental change. To that effect, he began to analyze the team's habits and lifestyle, focusing on any little piece that might contribute to their performance during a race. Those factors were sometimes as small and seemingly miniscule as the fabric on their racing clothes or the way they slept on their pillows at night.

Brailsford took small, inconsequential factors, studied them, and made minor improvements. His approach favored making dozens of changes that made things slightly better, the 1% cumulative effects. He called this, "The aggregation of marginal gains." Over time, all those little improvements created a snowball effect. 100 little gains added up into a monumental culture change for the team.

Brailsford's coaching style had a profound effect. In a matter of only 5 years the British Cycling team became one of the most dominant forces in the entire sport. So the question is: what can we as software developers learn from their success?

Leaps and Bounds Versus Iterative Design

We live in a world filled to the brim with innovations. We've become used to a business climate dominated by Apple, Google, and other tech giants who introduce radically reimagined software products every couple of years. These kinds of gains advance the industry by leaps and bounds, but don't discount the efficacy of marginal gains.

While radical new tech serves to shift industry perspective, it is iterative design that achieves real progress. Radical change can be messy. Think of what it's like to migrate to a new framework or deal with a completely overhauled OS. Numerous software updates and patches are usually required to make a new software into a functional product. It is the software engineer that is responsible for implementing a series of marginal gains to improve the base platform, and those gains are the core of iterative design.

How Marginal Gains Can Improve Your Design Process

The philosophy of marginal gains is a large-scale idea that applies to the entire conceptual framework of your design process. As a result, it's difficult to prescribe a direct "If you do X, you'll get Y" formula under the auspice of marginal gains. There are, however, some key areas of the software development lifecycle (SLDC), and associated design activities, that your team should focus on.

It begins with the first stage of the development cycle. Planning precedes all other software development activities. It is essential to break the problem down into all its constituent parts before designing a solution and implementing it. Here a philosophy of marginal gains truly shines. Encourage your team to probe the customer's needs as deeply as possible to truly understand what they need out of their new application. If your team has a profound grasp on the task at hand, they can work collaboratively to introduce as many small, beneficial features and attributes as possible before they build and prototype the solution. A hundred small innovations in the planning phase results in a superior design process going forward.

Marginal gains also have a big impact during the actual development cycle. The goal of any efficient development team is to increase both the velocity and quality of their coding. You can't achieve that all in one shot. Streamlining your workflow is a matter of setting achievable goals every cycle —reducing task size by 10% every week— for example. If the entire team shoots for, and achieves that goal, it has a gigantic effect on the entire process.

As useful as the philosophy of marginal gains is to the traditional software development cycle, however, marginal gains fit most congruently within the scrum framework, notably in the sprint and the sprint retrospective.

Celebrating Marginal Gains With the Sprint Retrospective

At its core, an iterative design in a sprint format is simply a series of marginal gains carried out in a very systematic, deliberate format. By its very nature, the sprint process is designed around incremental progress. Sprint teams are purposefully split into smaller groups, each one tasked with a very specific goal. The parameters of the sprint process are extremely narrow; there is a set time frame with an exact deliverable expected at the end of each sprint. Due to the laser-like focus of the sprint process, embracing marginal gains within each sprint generation is essential for creating better end results.

The sprint retrospective, which directly follows the sprint cycle, is a period of analysis in which the sprint team and their supervisors meet to discuss what was successful about the sprint and what could use more attention in future iterations. By definition, the sprint retro is the process of recording and cataloguing marginal gains or suggesting additional improvements.

Implementing a culture that celebrates marginal gains isn't just reserved for the sprint retro or a blameless culture, however. Whether your team employs an agile development process, or you rely on a more traditional development cycle, embracing and encouraging marginal gains has a big impact on your workflow. Through small, iterative gains, the individual members of your team will enjoy huge overall gains, reaffirming the quality of their work and their passion for high-level development. For your team, marginal gains bring tremendous results. As the saying goes, "The whole is greater than the sum of its parts."

Build Your Development Fluency

Whether it's designing a new application, learning a new language, or even riding a bike, success never comes instantly. It takes time and practice to achieve fluency in a new field and that success comes as the result of one hundred little revisions. While there's something to be said for radical change that shakes your industry to its very foundations, true progress is made by taking measured steps.

‍