Though approaches like Agile seem to be the right solution for our software development issues, they are far from delivering an answer, and I'll explain that to you in this post.
Since I started working for the ICT world, I've been working most of the time by the old-fashioned "waterfall approach". According to it, all software should be developed by small incremental steps, as the following image reflects:
Source - Wikipedia
From the moment, the most important consulting firms try to convince us that new and better approaches are available (let's focus on Agile!), they tell us to follow this path:
Now I have tried and worked with both approaches, I'm perfectly ready to give a deeper idea of what they both mean, their CONS and PROS.
Waterfall -> When working on a classic waterfall model, steps are not thought to be iterative. There is little room to change once the project has started, so it means all requirements and business needs must be well analysed in advance, and those same needs are understood as "fix" over the passing weeks or months the project may take to be delivered.
Agile -> When working on an agile model, its own iteration means there is always room to implement changes (user may raise his hand anytime and ask for a change without much problem).
The truth is:
Waterfall -> Based on a nice and deep understanding of project scope. Based on agreement of all parties involved in the project. Based on a given budget and little room for change during the project development.
Agile -> Based on subtle understanding of project scope. Although there is agreement, changes may get in as soon as any of the parties want it... as long as there is budget left... and here it is when from my point of view, problems arise... and let me get into that.
My own experience got me believing the agile approach would be the answer to all the problems I had already endured when working on a classical approach to software development.
First iterations, and first deliveries of software (they are called "sprints" in the agile approach) were poor on expectations. You get thinking that each delivery will offer a good and usable chunk of software, and it can be as an atomic unit of it as useless.
As in any software project, deliverables have always a good portion of criticism, of improvements, of misunderstandings, and if in a classis development those problems arise close to the end of the cycle (normally at the user acceptance test stage), on an agile approach those disagreements arise every two weeks (depending on the number of sprints you define).
The well-known discussion about what is a mistake the development team did or what is a change the user wants, is this way repeated periodically (due to the iterative method the agile approach follows). Statistically, the more discussions we have, the more chances we have to lose the battle, and therefore be asked for more money to implement those "changes" the user needs in order for the software to be compliant with his requirements.
This way, project managers see how their assigned budget goes down the sink in a blink of an eye, resulting in the best of the cases, in very few deliverables completed, though to be true, brilliantly executed since all budget and care has been put on them.
As a conclusion, and trying not to let agile approaches down, do please think twice before throwing your team onto an agile development cycle. At least, if scope is close to being well defined and if the customer is not bound to keep changing requirements, do not go agile, stay by the waterfall model.
If those two simple issues are not clear, them, go agile, but always taking into account point mentioned above. Budget and requirements come me put at risk unnecesarily, so, be cold-minded, and do not follow what seems to be fashionable now, unless you do a clear study of your needs.
Should you have any mention or questions, do not hesitate to address them to: asalbares[at]gmail.com and I will be willing to help you out!
No comments:
Post a Comment