After reading the materials provided and getting to the conclusion that waterfall was even originally perceived as a faulty model, that probably was taken on board because it was the only one that could provide companies with certainty at the time, I would say that trying to amend Waterfall keeping its structure is a lost battle.
During my work on FMVEK module last year, as part of my research work I found a paper that I perceived then as regressive; the paper reflects the research done by Hong, N. et al. (2010) that created a "Waterfalled Scrum" because they found this worked for them in outsourced projects.
Avoiding using here the approach they took, I personally would try to move the model a bit towards agile, by trying to solve the disconnection with the customer and make it iterative plus gathering external and internal feedback.
It will not be really Agile, as explained in Mike Cohn (2015) an iterative Waterfall is not Agile, but at least it will be a step better than it is now. Dividing the work and requirements gathering in small phases would help to limit risks and adding reviews and retrospectives at the end of each iteration would help to receive customer feedback, and learn/improve from what have been done and how.
We would be doing mini-waterfall inside each of those iterations instead of doing agile but the small benefits we can scratch would improve the Waterfall model, albeit if just creating an "agile" illusion.
[250 words]
References
Hong,
N. Yoo, J., and Cha, S. (2010) ‘Customization of Scrum Methodology for
Outsourced E-Commerce Projects’, In
Proceedings of the 2010 Asia Pacific Software Engineering Conference (APSEC
'10), Nov. 30 -Dec. 3.
IEEE Computer Society, Washington, DC, USA, 310-315. Available at: http://dx.doi.org/10.1109/APSEC.2010.43
Cohn, M. (2015). An Iterative Waterfall Isn’t Agile [online] Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile
[Accessed 05 February 2017]
No comments:
Post a Comment