Agile or Not: How to Get Things Done
Agile software development always felt intuitive to me. Developing software incrementally, in close collaboration with the customer is the obvious way to deal with the uncertainty inherent in both software requirements and implementation. The technical practices of automating necessary but time consuming tests, and deploying, early and often are the obvious ways to give an team the ability to evaluate the functionality you have and to to decide if the software works as expected. And it's also important to decide if what you built still makes sense given the current environment.
Agile software development always felt intuitive to me. Developing software incrementally, in close collaboration with the customer is the obvious way to deal with the uncertainty inherent in both software requirements and implementation. The technical practices of automating necessary but time consuming tests, and deploying, early and often are the obvious ways to give an team the ability to evaluate the functionality you have and to to decide if the software works as expected. And it's also important to decide if what you built still makes sense given the current environment. Agile isn't the only way that people build software, and it may not be a perfect approach, but it's one of the best ways of dealing with a system that has unknowns.
- The development team didn't test thoroughly enough.
- The code was not agile enough, so the bad assumptions were embedded into the code so deeply they were difficult to address.
- Communication was bad.
More complete specifications that address all of the issues a system might encounter are one way to build software. But the best that people can do is to write specifications that address what they know. Quite often no one has complete advance knowledge of what a system needs to do.
- Everyone involved needs to be committed to the approach and
- There needs to be a feedback loop to correct errors in time.
User Comments
Steve, excellent article. A lot of people think that the deliverable for agile development is code. It isn't, it's a working system. And that system should have exactly as much documentation (specs, user guides, whatever) as is needed. There is absolutely no reason why these cannot be developed in an agile manner as needed. Particularly if it is necessary to use a complex algorithm, that algorithm needs to be explained, how it works, why it was chosen and the problem it solves. The overall architecture (which I know is a dirty word to a lot of agilists) needs to be defined somewhere. I always refer people to David Parnas's classic paper "A Rational Process: How and Why to Fake It", which is a great explanantion.