I'm no petrol head, but I enjoy Formula 1 racing. It's not so much the thrill of watching elite drivers battle it out, but rather understanding how teams carve out winning strategies by managing many variables -- like weather, fuel load, and tire selection.

Sure, the winning driver gets to spray the champagne, but it takes slick teamwork to win a bigger prize – the constructor’s championship at the end of the season.

In many ways, the development of modern software applications is like Formula 1. Not only do IT teams have to speed application delivery to help their business gain a winning edge, they must also ensure performance is never compromised -- even at times when conditions seem beyond their control.

[Government needs the disciplined flexibility of DevOps. Is your agency ready for it? Read Bringing DevOps To The Federal Government]

DevOps, with its focus on teamwork and collaboration, might just be the winning strategy in IT. But there's a fine line between winning and stalling. So let's explore some of the strategies teams can use to help businesses take pole position in a race that's increasingly driven by software.

Pit stops are never perfect – Pit stops have definitely evolved. Fifty years ago, disorganized crews took almost a minute to change tires (the driver even got out of the car!). Now any stop longer than three seconds is a fail. It's the same with software, where teams previously tasked with updating enterprise applications at a sedate pace must now build processes that deliver new systems-of-engagement continuously.

The problem for today's enterprise, however, is that traditional testing processes are mismatched to the demands of modern software development. Mobile applications may be released, updated, and even retired over the course of a month, meaning the stop start method of developing and then testing doesn't work anymore. It's like a member of the pit-crew replacing a tire and checking wheel nut tension before the next one can start -- the race would be over before the car left the pits.

Pit crews don't work this way -- they work in parallel. DevOps teams also aim for this level of agility. So as code is being developed it should be continually tested and validated. Furthermore, this parallel method of development should cater to both functional and non-functional testing -- continually checking and tuning each software artefact for usability and performance.

This is especially important in the mobile world, where poor user experience will kill an app however good the design – something akin to an eye-catching Ferrari failing on the track because someone forgot that aerodynamics is more important than aesthetics.

Blended roles win races – Every Formula 1 pit crew is made up of the mechanics and engineers who work to develop the cars. Sure, one guy might be selected over another based on strength, but mostly any one of the crew can do the job of another. They're all really good generalists. DevOps too extols the benefit of multi-skilling across the organization. After all, if coders can test code as it's written, the likelihood of defects going undetected and forcing release delays diminishes significantly.

However, life in the fast lane of modern software development isn't always so clear cut.

Today's complex enterprise development conditions mean that teams will be coding and testing composite applications made up of mobile apps and web user interfaces, SOA and RESTful APIs, plus an eclectic mix of middleware, legacy back-office databases, and even cloud services. But unlike Formula 1 crews that have a standard set of tires ready when the car comes into the pits, enterprise IT teams are always constrained by limited access to physical infrastructure when testing.

This is why service virtualization is becoming increasingly adopted by DevOps teams to achieve agile parallel development. By simulating real-world conditions and removing testing constraints, DevOps teams are more likely to stay aligned -- with the result being more frequent deployments, faster lead times, and fewer software defects.    

Feedback is essential -- Sebastian Vettel only came in sixth in the 2012 Brazilian Grand Prix, but it was enough to win him the overall world championship. That race demonstrated the thin line between success and failure -- a line drawn by feedback and communication. For example, constant analysis of Vettel’s car after a minor crash helped him stay out on the circuit longer, but poor communications with the crew also meant long delays when they weren't ready to change his tires when he was forced to pit stop.

DevOps places similar emphasis on feedback, which as with Formula 1 racing, must be constant, uninterrupted, and bi-directional. For example, if DevOps toolsets have allowed testing to be conducted against production-like virtual services, realistic performance requirements can be quickly obtained and factored into development. Then, these app performance baselines are baked into the operational fabric to drive continuous improvement.

In Formula 1, nothing is static. Rules change every year. Similarly, in today's software-driven economy, the conditions that dictate how we must build and operate applications are always in flux. Individual Formula 1 driver heroics might win you one race, but it's the ability to truly work in parallel that helps your DevOps team stay the course.

InformationWeek's new Must Reads is a compendium of our best recent coverage of project management. Learn why enterprises must adapt to the Agile approach, how to handle project members who aren't performing up to expectations, whether project management offices are worthwhile, and more. Get the new Project Management Must Reads issue today. (Free registration required.)