This incredible video of a Formula One pit crew in action has been making the rounds on the Internet. Have you seen it? The crew performs an entire pit stop in under three seconds, with no errors, working in perfect synchronicity -- like a “pit stop ballet.” Go ahead and watch, we’ll wait ... (it’s only 56 seconds, and safe for work.)
Watching this video got us thinking about the performance of Agile teams. Rally knows a little something about team performance thanks to the Software Development Performance Index and our Insights® analytics functionality.
Using real, non-attributable data from the performance of nearly 13,000 active Agile teams, Rally’s analytics provide insights across four dimensions of team performance: productivity, predictability, quality, and responsiveness. You can use the results to help you optimize your Agile team performance.
To demonstrate, let’s use the F1 crew as an example. Each F1 pit crew mechanic has a distinct role, and performs only one job. In Agile terms, you might say that this crew has extremely low Work in Process (WiP.) And on an an Agile team, having fewer work items in process means that each item gets done faster. The amount of time that a work item spends in process is a measure of responsiveness. So lower WiP means faster time in process, faster time to market … and in the case of the pit crew above, highly responsive pit stops.
In Agile, teams with poor control over their WiP take nearly twice as long (see Time in Process on the Y-axis, above) to complete their user stories as teams with low WiP. This makes intuitive sense: as with the F1 mechanics, the more focused you are on just one thing, the faster you'll get each one done.
Lowering your WiP can have benefits besides responsiveness: teams with the lowest WiP have 4x better quality than teams with the highest WiP. And when your job is to affix a tire to a car that’s about to drive more than 200 miles per hour, well … quality really matters.
But performance like that of the F1 crew comes with some costs. Though teams with low WiP may cut their time in process in half, and have one-quarter as many defects, they also have 34% lower productivity.
In Agile, productivity is measured by the number of user stories and defects completed in a given time period. Take a look at this NASCAR pit crew as an example.
NASCAR races allow a limited number of pit crew members "over the wall” during a pit stop, so each mechanic must be more productive. Changing a tire takes about 5 seconds, and each mechanic has to change 2 tires. While this crew may not seem as responsive as the F1 crew (its Time in Process is about 20 seconds vs. under 3,) it’s much more productive.
Speaking of numbers: did you happen to count the number of mechanics on that F1 crew? There are a whopping 21 of them, standing around waiting for their car to pull in. By contrast, the NASCAR pit crew is limited to 7 mechanics. (The recommended size of an Agile team is 7 ±2.)
So what does this all mean?
- If your WiP is high and you’re at risk for missing a market window, then drive your WiP as low as possible by focusing on just a few things and getting them to market faster. In other words, make like an F1 pit crew.
- If your WiP is already well-controlled, however, consider your economic drivers. For example, if productivity drives your bottom line, don’t push your WiP too low. Instead, take more of a NASCAR pit crew approach. Balance is key.
Hungry for more?