Agile has become THE buzzword in the software development industry. It seems to be used almost everywhere, and some lost souls even argue that might be the closest thing of the silver bullet we have seen yet. And if you spend your days listening to sales presentations, you might be under the impression that the search of the Holy Grail of software development is finally over. The funny thing is that sales persons have been saying the same thing for the last ten years, which I have been working in the IT industry. I don’t dare to call myself an expert of agile software development, but I will still put my five cents in by describing briefly some of the most common characteristics of agile software development.
Continuous improvement should in my opinion be the goal of every self respecting employee. That is perhaps why I believe that the best part of agile software developments is the aim of continuous improvement. However, when working in a team, the continuous improvement of an individual developer does not necessarily improve the performance of the team. So, instead of concentrating only to improve one’s quality of work, each team member should be more interested in improving the performance of the team. That is one characteristic of a truly agile team.
Besides testing, one common complaint, which I have been hearing from developers, is related to level of documentation. Agile software development does not remove the need of documentation, but it greatly reduces the amount of unnecessary documentation. The traditional approach to software development pretty much dictates the level of documentation, whether the created documents are really useful after the project or not. I believe that when using agile approach, documentation efforts should be targeted for areas where most value can be obtained in comparison to the time spent.
The Agile Manifesto introduces a phrase:
Responding to change over following a plan.
At first, I must state that constantly introducing new changes is not agile software development. It is a state of utterly mess, which only insures that nothing gets done. In agile development, introducing changes must be done by following a plan, which gives the team time to implement the changed requirements. When the team has done that, the outcome should be reviewed and changes can be made to the requirements if necessary (Naturally the requirements should also be prioritized to ensure that the team can focus on doing the right things).
Agile methods has proven to me that there really is something deeper behind all the hype, which is currently going on. I have some doubts though, but I also believe that the used methods should be fitted in with the needs of the organization using them. Thus, I have the courage to say that the Holy Grail has not been found yet.