Joel Spolsky, in his blog “Joel on Software” wrote:Dmitri Zimine has a hypothetical story of how interrupting a programmer for a two hour emergency request needed to close some sale can actually waste two weeks. “If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one,” he says.Joel goes on to say,Agile development is supposed to be about agility. It’s supposed to mean that you can change plans quickly. It’s not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can’t rearrange their schedule a bit to serve the needs of the customer. Dmitri’s conclusion, I’m afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn’t take customer’s needs into account.I think I’m going to file this one under “adventures in missing the point” or “All the facts? What’re those?”
I’ve never seen Joel say anything good that didnt promote his company’s bug tracking software, the consumate salesman in that regard. Agile development methodologies stand opposed to the old fashioned “waterfall” method. We all know that ____ rolls downhill, and the “waterfall method” of software development is a great example of that maxim in action. Agile development aims to take the big design up front and the long testing time at the end of the classic waterfall process and wrap them around a given sub-unit of the software; Agile methodologies attempt to bring manufacturings “Total Quality Management” processes to the software arena. Agile development will reduce, but not eliminate, the need for a dedicated testing group and therefore the number of licenses of bug tracking software that the testers would use to communicate back up the waterfall to the developers. And so, I come back around to why Joel displays a dislike for all things agile.
Why “adventures in missing the point”? Simply this: every agile project measures team velocity. After the team estimates the amount of work involved in finishing a given sub-unit of the project, that estimate is compared to the time that it actually took. Meetings, phone calls (blogging!) and other distractions will reduce the overall code-output of a developer: a given developer will never work a “perfect” day. Team velocity tracks the effects of these distraction and accounts for them when assigning work for a given iteration. The team may well be delivering a clean build that brings business value to the customer every 2 weeks, but their velocity will allow for a certain amount of “emergency” items to slide into place as they move along. If Joel knew agile development instead of simply attacking it, he’d have recognized this fact.