I read a great article today on the future of software development. It gives a great summary of what is wrong with the waterfall method of development and how agile methodologies try solve this problem.
The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that lead to the development of agile methods. (article)
Management is often slow to learn of new trends in software development. The fact that agile has been around since the nineties and many institutions still have not heard of it proves this point. I believe the best way to bring agile methodologies into an existing organization that uses the waterfall or another approach is to bring them in slowly. This is what we have done in my organization and it has been very successful. Here are some good starting points for change.
- Change how requirements are viewed. If you are handed a set of requirements for an entire product release, plan for them to change no matter how “final” you are told they are.
- Split the development cycle into iterations. At the end of each iteration reprioritize your tasks for the next iteration. 3-4 weeks is a good length for an iteration. Create a full release of your product at this point whether someone will actually use it or not. Hopefully you will have a QA team to test it at this point but it is important to create a fully working version of the product anyway.
- Leave the design of system components to the iteration they will be developed in.
- …
Pretty soon you will find that your Waterfall approach is a lot more agile than it used to be. I encourage you to keep changing your approach as you find what works best for your organization.