As a project manager, I am often asked about the differences between software development life cycles. For some, it’s easier to understand and adopt a waterfall approach, and for others, Agile is the only accepted norm.
Keeping it simple, I explain that the key difference between the two styles is time. Waterfall functions more on the line of “We have to do this first before we can do that” and it emphasizes getting all the work done in the correct sequence rather than how long it takes to complete the project. Whereas Agile emphasizes time and addresses the situation “Here’s a feature I want to build. How much of this can I get done in 30 days?”
But let’s face it: a lot of companies operate as waterfall, even when they label it Agile. This is otherwise known as “Scrumerfall,” and it tends to bother hardcore Agile types when a project slips into waterfall.
For instance, Scrum created daily stand-ups which are morning meetings of 15 minutes or less. Each team member actually stands up and informs the team (1) what they worked on yesterday, (2) what are they working on today, and (3) what is blocking them from getting their work done. Only the people doing the work are allowed to attend, managers are not. This is basically an easy way to assess progress and deal with potential issues. The three discussion points are intended to keep the team focused for the day, before they start working that day.
Scrumerfall happens when a manager turns the session into a roll-call and project status update, and ends up blowing way past the 15 minute rule and the original intent of a daily stand-up. The waterfall personality type says “That’s okay because I want everyone to know everything that’s going on everyday” because they are worried about getting criticized for lack of communication with the project team and stakeholders. The Scrum Master types think “I have to get people back to work because they only have x hours in the work day and x days in the sprint” because taking a developer and tester away from their work is very disruptive to their productivity.
Likewise, a tollgate check is more suited to a waterfall methodology as it determines suitability or production readiness of a newly developed feature. This is also known as a “Go/No-Go” session, and if used by an Agile team, it can be an effective means of communicating with key stakeholders. The waterfall type thinks “This is a risk management technique, so we don’t cause a stock market flash crash.” The Agile mindset though is that “It’s easier to ask for forgiveness than to ask for permission.” Scrumerfall happens when an Agile team conducts a tollgate check or the new feature goes thru an arbitration or release management group before consumers can use it.
So the questions are “Which one is better?” and “Am I really doing something wrong if I deviate into Scrumerfall?” A deeper question might be “Does standardizing project delivery mean greater efficiency?” In my experience, the answer for any method used comes down to the people – those doing the actual work versus those who have a need to know about the project. Whether your project is time sensitive or not, if you are not working with or taking care of those people, then your project will suffer. You can’t dictate a method, but you should let your project team decide which method or hybrid method works best.