Agile Software Development
Table of Contents
Up to this point in my consulting career, too often I’ve seen consultants (myself included) spend time writing documents describing what will be and won’t be included in the project. And pretty much every time, whatever the client committed to on paper, isn’t what the client wanted in the end. Requirements change between the start and end of a project. This is software development as it truly is.
Don’t get me wrong, I’m not saying documentation is bad all together. I can see the importance of writing some functional specification. Maybe some screenshots, workflows, and even the major business rules. I mean, as developers, we can’t write code out of thin air.
But if change is so natural in the software world, should it not be built right into the development process?
The traditional Waterfall Model is simply not practical for software development. The phases/stages are like a series of dominoes. Phase 1, Phase 2, then 3, and so forth, much like a waterfall. But I have never seen a project run like this. Projects are more like the Phases jumping back and forth between each other because everything needs to be revisited multiple times!
Agile Software Development recognizes that change happens, and it happens often. The work is done iteratively in short cycles with close contact with an expert user/client. It ensures that:
- The client gets their hands on something they can use right away.
- Feedback is given often.
- Changes/adjustments can be made quickly.
In the end, it should be a better product for the client that is developed with a more reasonable methodology.