I always find this subject fascinating. All views below are my own.
I’ve now been programming professionally for about 30 years, and one of the things I have been asked by younger programmers is which methodology is it best to use, and I have never been able to produce an adequate answer. The only answer I can ever give is that it depends on the project, the team, and in all brutality, the competence of the stakeholders.
Let me try to explain.
Waterfall
There seems to be a lot of negativity towards waterfall due to it’s strictly linear progression. This linear progression is both a good and a bad thing. Many of the games I have worked on were produced using strict waterfall methods, with well-defined milestones in a full project schedule. This schedule would be created at the back end of creating the full game design document (GDD).
There would be a lot of time spent on this document with all team leaders (programmers, artists, designers, audio technicians, etc.) and it would be created to be as watertight as it could be. It would be analysed heuristically to see if any gameplay mechanics, or level designs had flaws that would lead to “dead ends” and so on, and once all team leads were happy with the GDD and the schedule it naturally created it would then be signed off and sent to the publisher for approval.
Once approved by the publisher everyone had a roadmap of what needed to be done, and an accepted timescale, so people (rightly or wrongly) could be held accountable. Weekly schedule meetings would be held to ensure no slippage, but the time for these was catered for in the schedule.
For me, the only time this methodology didn’t work was when the publishers changed their minds about gameplay mechanics or design, but in these instances, most of the time, we could re-work the schedule to allow for these changes to be made.
On big projects, with a strong team, and strong leadership (publishers) I found the waterfall method to work very, very well.
Scrum
There has been a strong move towards using scrum in modern software development, and I cannot argue against it. My boss would call it the “fire the rocket and correct in flight” way of doing things.
I find scrum works better where you have weak stakeholders. What I mean by this is stakeholders who do not have a clear vision of what it is they actually want, despite prior engagement and a plethora of user stories. In these circumstances the rapid iterative approach of scrum allows software to be presented, reviewed and accepted (or not) at regular periods. If it is not accepted, because of the approach of showing often, not a lot of time, code and energy is really lost, and this regular show approach also, in my experience helps focus weak stakeholders so they have a better understanding of what it is they want and require.
The other big positive of scrum is the daily meetings where you are focussed on short term goals of “what did we do yesterday” and “what are we doing today”. I actually now ban non-scrum team members from attending these meetings, as they would continually interrupt. If we needed their input we would schedule a proper meeting.
The one thing about scrum I do find a little tedious, if you’re the scrum master, is keeping on top of the “paperwork” aspect. I’ve always found that the lead programmer (probably bias) makes the best scrum master, but then they spend too much of their valuable time on administrative tasks of keeping the group focus.
My Conclusion
So, my conclusion is that there is still space for both of these methodologies in modern software development. If I was working on a big project, with lots of team members I think I would struggle if we were working with anything but waterfall.
For small apps, especially experimental software from an idea which you might be unsure will actually work, scrum is absolutely the ideal approach.
So, that said, for me, it looks like the choice comes down to project and/or team size. That’s something I guess had always been in the back of my mind but it’s only writing it down that brings it out.
Hey Francis, interesting read & good to hear your views on the waterfall vs scrum methods. What do you think about evaluation & disposal. I think evaluation is pretty straight forward to understand for most people as it’s a form of reflection & continued development, but in terms of disposal, I have a lot of feelings about this one that I am not too sure how to summarise.
Aaron. First off, thanks for taking the time to read this.
I’m actually going to add another couple of posts tonight. A short one purely on what the course tells us about the waterfall method and a longer one on scrum going into more detail obviously.
I plan on going through evaluation and disposal in there.
For me though, evaluation is pretty much what I’ve always called the “project post-mortem”. You’re right, in that’s in important development tool to learn what’s gone right, what’s gone wrong, and how a team can improve.
Disposal, for me, is a lot wider area, and, bluntly, not only involves data and hardware, but team members as well. Not necessarily out of a job, but maybe out of a role they are not suited for. Like I say, I plan to spend more time going through “disposal”, but only in terms of what we have been shown.