Wednesday, October 15, 2008

Building a Car - The Falacy That Dev Teams Will Add on Features Mid-Sprint

You say: Build me a car
I say: Ok
You say: I want it in 2 months!

What kind of "car" do you expect me to build?

You say: Build me a car
I say: Ok
You say: I want it in 2 decades!

Now what kind of car do you expect me to build?

In the first case you probably expected an engine strapped on to four wheels and maybe some breaks. In the second case you probably expected a cutting edge car with all the safety features, smooth ride, and uses renewable resources for it's power source.

It's the same way with developers and features. Take a developer who loves his job, give him a month to do a feature he estimated would take him a week, and he'll take that whole month. Scope creep comes from everywhere, even the developer himself. "I can refactor this and optimize that, and we'll make this AJAX to it puts the burden on the client machine instead of our servers..." and next thing you know you've got a Corvette when a Taurus would have gotten the job done.

Agile says "If something goes wrong and the team isn't going to make their commitment, then it's time to cut features." And all of the product owners of the world freak out here, so we try to comfort them with this: "But if they're ahead of schedule, they can always add on features from the product backlog!" And all the product owners start to recover from their impending heart attacks. But now you realize that unless something happens to make them take another feature off the product backlog, it isn't going to happen because developers want to make the code/architecture/feature they can - adding business value is something that doesn't come naturally, preventing bugs and being on tech support calls is.

There is one mechanism that is somewhat effective in preventing internal scope creep. It's the same thing that happens when you have external sources of scope creep, the creeper has to present his creepiness to the developer, at which point the developer says "You're creepy!" and tells sales they need to bill the customer for more hours. "But Will, there's no presentation when the source is internal, I'm confused." But we can make the developer "present" I'm not talking about a stand up presentation where he can hide his work. I'm talking about my favorite tool, pair programming. Now you've got another dev, and every character you type is presented to her for review. "Why are you adding that in, we still need to build up the core functionality, quit being so creepy Will", ok, so maybe that last part was from my Google-stalking days, but you see how having an extra set of eyes keeps you honest and business minded.

No comments: