By now you've probably heard about it. Agile Software Development is the rage. It is said to bring to software development benefits that are usually attributed to Just In Time inventory management. It is a development strategy that deals with change easily and produces results. The Agile Manifesto and its Principles lay the groundwork. It combines the best of traditional engineering wisdom with the best of a late night self-help guru.
Ahh, you're thinking, here is someone who doesn't get it. On the contrary, I can see the advantages of the Agile approach. It is something that has been unconsciously nagging in the back of mind mind for all of the twenty plus years I have been developing software. Let's face it. Tools often don't work as advertised. Processes (at least the ones management want) usually are self defeating. Documentation never is up-to-date and is often wrong. Contracts usually specify tasks that are little understood and maybe impossible. And plans always change.
And non-programmers distrust programmers because they don't see results until late in the project. In the past some people have advocated building non-functional prototypes just to get something for the end-users to see and keep them off their backs - even if the prototypes were to be thrown away.
Now people working together side-by-side, face-to-face conversations and self-organizing teams just make me all warm and fuzzy feeling. How about you?
But... (You were waiting for that, weren't you?) but there are just some things that just don't fit the "agile" mindset. And what concerns me is that the Agile Manifesto may be in danger of becoming a full-blown religion. Let's look at an example:
Maybe you've heard of a piece of software called AutoStitch. A PhD student named Matthew Brown developed the algorithm and his paper is available on the same web page. Now given a team of programmers who already know the research, it would certainly be possible to develop a software project using agile techniques. Of course the software is worthless until it stitches together its first panorama. But what about Matthew Brown when he first set out to develop this idea. I hardly think he was working together side-by-side, having face-to-face conversations with his self organizing team. This guy's self organizing team was entirely contained within his own head. I don't know how long he worked on the underlying math and algorithms, but I'm willing to bet that delivering frequent working results on the shortest timescale possible was not an overriding concern. If anything, just coming up with the right answer at all was probably his main concern.
This is the problem I see with Agile development. While it may support innovation, it leaves only little room for invention. Sometimes producing something really new demands that some very talented individual or some talented group submerge in a project until a solution is forthcoming. Agile Software Development talks about quality, but results are usually being measured by a list of features that can be implemented in short timeframes, like weeks or months and by delivering continually working software. And unfortunately for the world there are just some things that will never be able to be done this way. In fact, there will always have to be projects that fail miserably if there is to be any progress. For one thing, not everybody is as talented as the next guy. Or just sometimes the problem may have no viable solution.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
I sure hope so.