English | EN Why Agile won’t solve maintenance problems
Aug 27, 2014
As you all know, more and more companies are moving their development processes toward so-called Agile Methodologies. From a (very) high-level perspective, the goal of these methodologies is to avoid long development cycles, where the user won’t see its product until it’s finished. This goal is obtained by using incremental development cycles where a few functionalities are developed during each cycle, but in each cycle a fully functioning (sub) product must be delivered to the user.
Using these methodologies, a higher interaction with the user is put in place, which allows for better communication, less misunderstanding, and finally, a more satisfied customer.
To allow these short development cycles (usually a few weeks), some renouncements have to be taken: small and highly skilled teams instead of big hierarchized teams, daily meetings and exchange between team members, continuous testing (instead of the usual: let the customer do it…), and lightweight documentation instead of complete requirements and functional analysis.
What we have here is a theoretical model, and as usual, each company has its own implementation based on one of the numerous declinations of the Agile Manifesto (foundation document of Agile development methods), such as Scrum, Kanban, AUP, etc.
In the last 5 years, Agile Methodologies have been skyrocketing here in Spain, almost all of our customers have implemented or are experimenting with Agile, and we have already seen an important number of projects developed using Agile. And there is, as usual, as much implementation as customers.
In most cases Agile implementation has been positive. It allows possible disasters to be detected much sooner than with traditional development lifecycle. This is an important point that allows either to correct the problem or to scrap the project with much lower costs than big monolithic projects. Of course, some failures have also been registered, but probably much less than with traditional projects.
In every case, there is a common result that I must say is not directly related to development methodologies, but more to human being natural procrastination allied to unrealistic planning: the lack of good documentation at the end of projects. Butthe methodology used is a good excuse to not deal with it, since it is considered as not being the core of the development as in traditional methods …
The Agile projects, once in production, will probably be better adapted to customer needs, leading to higher customer satisfaction due to projects being done on time and on budget. From a maintenance point of view, they will be the same nightmare as usual…
About the author
