The Race Car Metaphor

 

Since 2001 agilists have been focused on finding ways to improve how software is developed.  This article describes what we’ve come to call the Race Car Metaphor for process improvement.

Agilists Know How to Build Great Race-Car Engines (Development Teams)

We’ve adopted fundamental strategies such as regular coordination meetings, regular demos, product owners, developer regression testing, retrospectives, and incremental releases of working software.  Disciplined teams have adopted more advanced strategies such as active stakeholder participation, continuous integration (CI), test-driven development, continuous documentation, continuous deployment, measured improvement, and incremental releases of consumable solutions (to name a few).  We experiment with new techniques to learn what works for us in the situation that we face, improving our approach as we do so in an incremental kaizen-style manner over time.  In effect we are finding ways to tune our “development engines” so that we can deliver more valuable functionality, to reduce our cycle time, and to be more productive as a team.  This is very similar to a Formula One team who over the years improves their racing car engine to deliver more power and more speed for less fuel consumption so as to help them win the race.  How to approach agile solution delivery in a streamlined manner is the focus of Disciplined Agile Delivery (DAD).

But Then We Plunk Our Great Engines Into Our Organizational Tractor

We see too many agile teams, who on their own are doing a great job at improving the way that they work, get bogged down by the organizational environment in which they work.  This is particularly true in established enterprises that have been in operation for decades and sometimes even centuries.  Your development team tries to work in an agile manner but they’re forced to conform to your PMO’s existing traditional governance strategy that requires creation of inappropriate artifacts following a lifecycle that is far from agile; they’re forced to work with a bureaucratic data management team who often takes weeks or months to do work that should be accomplished in minutes or hours; or they’re forced to work with a review-focused enterprise architecture team who hasn’t been actively involved with software development for years (to name but a few common challenges).  This is akin to putting their racing car engine into an organizational tractor.  Is it any wonder you’re not winning the race?

But We Really Need a Race Car (Disciplined DevOps)

But agile software development alone isn’t sufficient. We see too many agile teams, who on their own are doing a great job at improving the way that they work, get bogged down by their organizational environment. This is particularly true in established enterprises that have been in operation for decades and sometimes even centuries. The software developers are agile, but you still have a “quality assurance (QA)” group that insists on manual testing based on a detailed requirements document. Or it takes days and sometimes weeks to release a new version of a system into production because of your existing release management practices. You’ve got this great agile team, a great car engine, but you’ve put it into an organizational tractor. Is it any wonder you’re not seeing the desired improvements? Many organizations have come to realize that agile software development alone isn’t enough and now are focusing on DevOps. They’ve increased the scope of their improvement efforts because they realize that their race car engines really need to be put into a race car.  Enterprise-class DevOps is the focus of Disciplined DevOps.

We Need a Great Team to Run the Car (Value Streams)

But this isn’t sufficient either. Just like a race car needs a driver and pit crew to operate it, your DevOps strategy is part of your value stream. If your product management approach is based on traditional thinking that requires teams to large, detailed requirement specifications then that’s the equivalent of a pit crew putting square wheels onto the car and then holding the driver accountable for losing the race. Similarly your DevOps efforts will be for naught without the support of business operations capable of supporting customers working with updated offerings. Just like your race car requires an effective team to run it in a race, your DevOps strategy requires a supporting value stream to be effective, the focus of Disciplined Agile's Value Streams layer.

And We Need a Race Where We Can Make Money (a Disciplined Agile Enterprise)

But this still isn’t enough. A race car and team is of little value if there’s nowhere to race! They are part of a larger racing business which has multiple value streams through which they generate revenue: They make money from ticket sales, from advertisers, from merchandising, and from many other sources. Similarly, your value stream are supported by your larger organization, involved with and supporting many value streams from which you make money. This is what the Disciplined Agile Enterprise (DAE) is all about.

No Team is an Island Unto Itself

So, to summarize, an engine is part of a race car that is evolved and operated by a team of people and this race car team is part of the overall racing business. Similarly, our software/solution delivery teams are part of an overall DevOps effort, which in turn is part of your IT strategy. Your IT strategy is one aspect of your overall organizational strategy. All of this must work together smoothly, given the challenges described earlier, in order for you to have a truly agile organization. And, on top of that, you need to accomplish this given the myriad of internal and external challenges that you face. How hard could that be?

What About Non-Software Teams?

No metaphor is perfect.  This metaphor works well for software teams because the way that they work are described by the Disciplined Agile Delivery (DAD) process blade, which is part of the Disciplined DevOps layer, which in turn is part of the Value Streams layer, which is part of the overall Disciplined Agile Enterprise (DAE) layer.  But consider an agile marketing team.  It's already part of the Value Stream layer and supports Disciplined DevOps efforts as appropriate, but isn't explicitly part of the Disciplined DevOps layer.  Bottom line is that we need a second metaphor to address the realities faced by non-software teams.