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…
More information
Patrice Marillier has been working in the IT industry for more than 25 years, and is part of Sogeti for 14 years, since specialized in Software Testing activities.
He is responsible of the Sogeti’s Spanish Software Control & Testing delivery, trying to convince Spanish customers that saving money on a development project does not mean necessarily shaving testing budget…
Having leaded for 7 years a Compatibility Lab for one of the major computer manufacturer, Patrice has a good knowledge of Infrastructure and Load Testing, and has recently been involved in various Mobile Testing Solution setups where he gained experience on the matter.
0 comments on “WHY AGILE WON’T SOLVE MAINTENANCE PROBLEMS”