Motley says: "What’s wrong with mixing Scrum and Waterfall? You get a nice ‘Scrummerfall’!"



Motley:  An effective modification to Scrum is to do a requirements sprint, followed by a design sprint, implementation sprint, test sprint, and stabilization sprint. It has the benefits of Scrum and has commonality with our older processes, which makes the developers happier.


Maven: Scrummerfall, or mixing traditional Waterfall with Scrum, is less effective than Scrum itself. Deliver real business value with each sprint for early and frequent feedback, and improve collaboration amongst team members as no one is left blocking and waiting for others to finish their tasks.



[Context: Motley and his team of able developers have been brainstorming ways to improve their Scrum process, and he is about to upset Maven with the details of his "improvements"]


Motley: Hey, Mave. Where have you been hiding lately? I haven't seen you around the office much.


Maven: Summer time is busy time. I had softball to play, a week of karate class with my sensei's sensei, and a couple of backpacking trips. I've been taking my vacation in small chunks.


Motley: I thought you were just slacking off, as usual.


Maven: Funny guy. This year I've had lots of small vacations instead of one big one. It really doesn't allow you to recharge enough, but I do like the variety.


Motley: Ok, enough about your relatively boring personal life. I'm thinking of making some changes to our Scrum process. With our next milestone fast approaching, the team really wants to transform Scrum into something more effective.


Maven: That's great! A key tenet of agile development is frequent introspection and continuous improvement. Glad to hear it.


Motley: Yeah. The team is thinking of having a requirements sprint, followed by a design sprint, followed by an implementation sprint, followed by a test sprint, followed by a stabilization sprint. Because the company wants to see these document deliverables as early on as possible, it might make more sense to get these done in sequence like this. The team also likes it because it is more similar to our old process.


Maven: I take it back - that's not so great.


Motley: What's the problem? The changes sound reasonable to me.


Maven: What you are proposing can be referred to (depending on the circle) as "Scrummerfall" or "WaterScrum". I'll call it "Scrummerfall", as I like that term better. In essence, you are proposing to combine two methodologies that typically do not work well together. With the proposal, you are basically doing Waterfall development, with more frequent check-ins (more akin to the way Waterfall was supposed to be, but typically is not). You lose the benefits of being an agile team.


Motley: How is it really different? We obviously still preserve the core of Scrum, including the daily stand-up meetings, planning, burndown chart, retrospectives, continuous improvements, and all the other pieces.


Maven: The proposed process is fraught with issues. In fact, you are no longer an agile team - you are back to waterfall, like it or not. Remember our previous chats on agile development? This process would break many of those principles. For example:

  • Scrummerfall abandons the idea of vertical slices, or delivering end-to-end functionality in short iterations of 2-4 weeks. Your deliverable at the end of a "sprint" in this model is a document, such as a requirements specification. Does that add real customer value that you can solicit meaningful feedback on? In my experience, it is hard for a user or fellow engineer to provide real valuable feedback on something that is not real (i.e. there is no working software, only a description of what that software will do).

  • Scrummerfall loses the benefits of the improved collaboration that Scrum provides. Sure, you can still have your daily stand-up meeting, but the feeling of marching toward a common goal is somewhat lost. What are the developers doing while the "Requirements Sprint" is happening? What is the test team doing while the "Design Sprint" is happening? Scrummerfall just doesn't work in a truly collaborative way vs. delivering real business value at the end of a sprint. Additionally, it forces you into doing too much up-front work with requirements and design, leading to overthinking the problem.

  • Scrummerfall violates the "working software over comprehensive documentation" piece of the agile manifesto. Don't get me wrong - documentation is necessary even with agile teams. Here, however, you tend to generate much more of it, which often falls into the waste (i.e. wasted effort) category, and we want to eliminate waste.

  • Scrummerfall makes change harder. If you get to implementation and test and realize something is amiss, you have a bunch of rework to do, including potentially large adjustments to design and documentation. Don't forget, with agile, we want to embrace change.


The team needs to deliver working software every sprint for early and often feedback. Yes, you can apply some of the practices of the Scrum methodology that contribute to team success, but Scrummerfall violates the fundamental principles of agile, which put you back in a Waterfall world.


Motley: But we still only need to plan for short iterations instead of long term crystal ball-like planning, which is a benefit and better than pure Waterfall.


Maven: Scrummerfall forces the team into a longer-term detailed planning phase because the end date of specific functionality in working software is important to the management team. You'll be predicting the future farther in advance for each feature instead of delivering features in just a few weeks. Of course, if you have a management team that wants crystal clear concrete delivery dates for all functionality up front, then you have less leeway here and have to do up front planning anyway to increase their confidence and minimize risk (even though that may be a fallacy anyway).


Motley: What about bugs? I don't want the team to be distracted with a bunch of bug fixes while we are doing feature development. We need that stabilization sprint at the end once everything is complete to fix all our bugs.


Maven: Don't forget - agile thinks about bugs differently. Instead of leaving bugs until the very end of the cycle, address them in the next sprint after a small end-to-end scenario is implemented. Bugs are a sign that the feature developed in the iteration is not done. Address the bugs as soon as possible, as they lead to increased technical debt (plus potential bug postponement, forgetting context of the bug, fixes growing more complicated, etc.) if they hang around. Avoid leaving them until a stabilization sprint at the very end. As we discussed previously, it is okay to have a quality sprint where you just focus on bugs as your iteration goal - it is more about when you fix the bugs.


Motley: Although I think the proposed process can work, I see some of your points. Small iterations of complete functionality, focused shorter-term planning, better collaboration and efficiency of team members, and less emphasis on documentation.


Maven: I actually agree with you - the proposed process can work. But, you are either an agile team or you are not. Mixing the two models can confuse people and actually make team effectiveness worse. With small chunks of deliverable software, you can get the test team private builds quickly to hammer on, and the test team does not fall behind as quickly. Because the team is marching to a common goal, the constant collaboration leads to priority adjustments and work breakdown to help others succeed (e.g. dev can build stubs and the  test team can start to write test automation).


Motley: Ok, ok. I'll have a meeting with the team to discuss putting the brakes on this proposed change. They might be a little upset.


Maven: There is no one right way to build software. The idea here is to set the team up for greater success than it would have had otherwise. Other factors can get in the way of putting in your own completely customized process, but that is a topic for another day.



Maven's Pointer:  Brad Wilson, a blogger on the "Agile Programmer" site defines Scrummerfall as:


Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.


Interesting definition. His description of Scrummerfall is slightly different than above. It involves embedded Waterfall within each sprint in a one-two-one pattern - one week of design, two weeks of implementation, one week of test. Although, in my opinion,  this situation is not nearly as bad as full requirements, design, implementation and test sprints, it is still somewhat outside the spirit of Scrum unless you parallelize the tasks and help each other succeed.


Maven's Resources: 

Comments (0)

Skip to main content