More on the Agile Debate

Alec recently replied to one of my Agile diatribes with a very interesting set of comments. His point is that no project will succeed if it is badly run. I’d be the first to admit that in some cases, I should probably have stood my ground or found a more stable compromise. But we have to admit that many project managers are likely to be less savvy or less principled than Alec.

The reason we learn as we go along in an Agile project is because we never asked enough questions to begin with! The whole point of an up-front intensive design phase is to bring as many of those ‘doh!’ moments ahead of the development phase as we can. Catching a design (or requirements) flaw midway through a project is definitely better than catching it after delivery. But catching them during the design process is even better. Everything changes around us because those who ought to have given more thought to the requirements have postponed thinking (indefinitely?). What can reasonably be delayed? My initial gripe is that one man’s reason is another man’s madness.

I’m not suggesting that we drop Agile and go back to waterfall models (although maybe we should for big projects). All I really want is that we feel obligated to think before we act. Is that so much to ask?

About these ads

4 comments

  1. Recognizing that SCRUM (and Agile in general) is appropriate to a phase of your overall SDLC causes us to also see that planning is not the devil. We can design and plan before an iteration begins, that’s why god made white boards.

    If a developer has to wonder “why am I making this?” during an iteration, there was not enough planning.

    I will be blogging our solution to this soon.

  2. Hi David,

    I look forward to hearing your thoughts on the topic.

    I think that the consumers of software systems need to be educated in the harsh realities of the SDLC. As _you_ are already aware, software development is hard – you routinely deal with extremely complex systems. But, without experience in writing software those who commission software _have_no_idea_ of how hard it is to do what you do.

    That’s not conceit – just a simple statement of fact. A surgeon wouldn’t change their mind midway through a procedure, nor would a civil engineer change the design of a building halfway up. (By now) it’s common sense to plan a civil engineering project up front. Besides, the complexity of what they do is tangible.

    That’s not true of software projects. It is still a mark of enlightenment for a manager to protect the design and planning phases of a project! Until it is plain old common sense, clients of software teams will continue to think that the least dispensible phase of a project is the one where they get tangible deliverables.

    It’s quite possible that that won’t happen until the requisite skills have diffused out into the community. And I don’t see that happing very soon.

Comments are closed.