During my testing career I have attended a number of training courses and sat through more than my fair share of interviews; it is impressive how many times I have been struck that somehow ‘Waterfall’ has become a dirty word. Attend an ISTQB training course and tell the class you follow a ‘Waterfall’ approach and you’ll be surrounded by faces of sympathy. Worse, tell someone you work with that your team is following a waterfall approach and they’ll hit back with the classic ‘this is V-Model not Waterfall’ response. I have worked on many so-called ‘V-Model’ projects and each time we seem to drop all the evaluate and re-work stages that make V-Model so much more reliable than Waterfall.
So why, if we are really following a Waterfall approach can’t we say so? Maybe deep down we all know that our first attempt at doing something is never going to be the best way. Many projects are successful but I think if we were really honest then everybody would be able to identify something, or a certain time when things started to go wrong. Panic, long hours and compromise are all accepted parts of software projects but maybe it shouldn’t be that way. An essential part of an Agile approach is regular retrospectives, focusing as a team on what went badly and even more importantly, what went right will give you far more benefit than daily stand-ups and writing on story cards. Iteratively developing software whilst continually reviewing and improving is what makes agile such a powerful approach.
Time pressures, laziness and a million other things can get in the way of reflection and performing retrospective actions but take the time to schedule in half an hour a week to review your own work, attitude or approach and you will quickly identify positive patterns which can easily be repeated. You don’t need to change the whole project to change yourself so start small and reap the benefits of review.