Short delivery cycles are good but no shorter than necessary to deliver what’s required to do the right job. Not much worth having gets done in software in 1 month or less as the Agile proponents are advocating. Moving software under development to test as soon as possible and delivering to test daily if possible thereafter is a great practice, but even those delivery dates cannot be artificially imposed.

I agree. It’s been my experience that unrealistic schedules don’t improve project success, and that’s what I was intending to suggest in my post, but not very well. Here’s what I believe. The deliveries should dictate the schedule and the delivery date is just one of the many requirements. If the delivery date is the most important requirement, you find the suite of requirements that can be delivered on that date. If you can’t find them, you are back to delivering to unrealistic schedules. Too often teams will find themselves here — committing to unrealistic timelines, and too often product managers don’t appreciate the damage they do to their products when they are stubbornly inflexible. Now, what do we do about it when we know we are there and have no choice? I’ll try to address that in future posts.

I like to believe I advocate agile methodologies too, but not what’s currently being advocated by the Agile methodologies that are attempting to support the Agile Manifesto: Scrum and Extreme being two flavors. What Agile means in these approaches is foregoing rigorous requirements analysis and design and doing it all on the fly as you code: parallelism. I don’t agree with that approach, and I don’t believe it would have been successful on any product I was involved in delivering. I have seen projects deliver that way, and they were very unsuccessful.

Refactoring is an expensive approach to software development. It’s much cheaper to change things in a document before you code it — whether it is a design or a requirement. Could you imagine constructing a building without architecture plans and using refactoring to get the architecture and requirements right? You could actually build a building like that, but the constant constructing, tearing down, and reconstructing would be expensive. That’s what the Agile crowd is advocating in refactoring: use refactoring as a process to develop the requirements and design. I will never agree that, that’s a successful approach to developing software. So the Agile proponents are arguing for a very expensive paradigm for software development while companies are moving entire software departments offshore to save money. This is a good thing?

I generally used Agile methods, albeit before Agile was described as such. A big advantage of short release cycles is that you get feedback much faster — both feedback to the developers and their managers, and feedback to the users of the software.

In my quote, I was merely observing that everytime *I* made a managerial decision (typically against building some tool or automation), it was wrong, and ended up resulting in lower quality and longer schedules.

The programmer’s version of the fable of the cobbler’s children’s shoes, sadly.

I don’t really have an opinion about shorter schedules — but I do strongly believe that schedules should be realistic and attainable. If the shortness of the schedule is externally imposed, as it often is, the resulting schedule is most often unrealistic. Unrealistic schedules don’t improve project success, obviously.