OK, don’t be too concerned, I’m not going to break into some bad Bob Seger karaoke. Here’s the deal: Today over lunch I planned on doing a quick 20 mile bike ride to refactor my wetware. Based on my usual average speeds over flat terrain, I figured on about a 1 hour ride. Before I headed out, I checked the weather and the wind speed was about 2 mph (not much at all). So, out I go and I’m cranking all the way out toward the foothills of the Rocky Mountains. I get to my turnaround point and I’m right on my usual average velocity. I’m thinking, I’m getting back to the office right on time. So, about a mile in on the return leg, the wind decides it’s time to blow. And it really starts blowing a strong headwind. I can’t get over 14 mph! I get back to the office and it took me 75 minutes instead of 60!
So, what does this have to do with anything (except that now you know that I ride my bike at lunch)? While I was riding back, I thought, this is a lot like a big software development project. A lot of development teams start out thinking “This is a 20-mile ride, I usually do it in 60 minutes”. They try to figure out all the dependencies (i.e., the terrain, the wind speed), and feel really confident that they’ll get the job done in time. Then they start building the software. The wind is at their back…they’re cranking through the work. Then, one day, the wind starts blowing. This project has complexities we didn’t think of. We didn’t know it was going to be this difficult. But we still need to finish the job (we still need to get back to the office). We can’t work or pedal any faster. We know we’re going to be late. What do we do? The project goes into panic mode. Do we sacrifice quality to get it done? Do we sacrifice schedule? Do we go over budget? The reality is, most traditional development teams do all three at one point or another.
In agile, we don’t let the wind worry us. Agile embraces changing conditions. An agile team simply says, OK, it’s windy. How do we work in the wind? How do we work with the wind? Do we have to make it back to the office? In other words, agile teams can easily adapt to new conditions, new requests, new requirements, unknown complexities. And because we use prioritized backlogs with our customers, we don’t have to sacrifice quality (or value), schedule, or budget.
© Copyright 2007, ChrisSpagnuolo.com GeoScrum! by Chris Spagnuolo is licensed under a Creative Commons Attribution 3.0 United States License.