in reply to OpEd: Programming is not Team Sports
I used the agile methodology at last workplace, and I use it now at my current workplace. And both approaches were different.
At the old place, we'd gather at about 10am and have a quick stand-up meeting: 1. Here's what I did yesterday; 2. Here's what I plan to do today; and 3. This is what's blocking me. Everyone got 1 minute; committee business would get put off until later. And it worked fairly well.
At the new place, every work item is costed out very carefully, we update our issues regularly, and we meet daily. It sounds roughly the same, but it feels like *much* more process, and a bit cumbersome.
The waterfall approach is close to what I learned at university (Systems Design Engineering at Waterloo), but it's a more academic approach than what I think really works well in the real world. In the real world, you don't want to spend weeks writing a perfectly detailed specification on what the system's going to do. It's much more productive to have a good general idea of where you're starting from, and be able to show a version that does a little bit, but does it well, shortly after starting. That's a much better approach than coding for eight months, finally having a demo of the system and hearing "Nah, that's not right."
Building software is *not* like building a house or a bridge. You don't think about rebuilding a house's entire foundation after it's been in place for 50 years, but, if the software's structured correctly, that type of thing is, or should be, fairly straightforward for a legacy system.
Really, agile should be about finding a good balance between planning and doing. That's all.