Scrummerfall - Mixing Scrum With Traditional Software Development Methods

Friend and colleague Brad Wilson 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.

Which gets us to our story. I was having an email conversation with a person that I am coaching on pair programming and some colleagues that will be helping (names changed to protect identity). In his email, “Bob” said that the timeline for us to start the pair programming pilot with him and his team was in line with their “Sprint planning week”. This is a term I had not heard before - not from any literature on Scrum or agile practices or from my friends in the agile community. I asked the obvious question:

“Bob, what is a sprint planning week - I’ve never heard of that” I asked.

Bob responded, “I’m probably not using proper Scrum terminology but in our team, we commonly use “sprint planning week” to describe the single week before the 4-week sprint where we work out the sprint backlog, people resources, and timeline for implementing and testing backlog items.”

What I found is that this particular team breaks their work out by the following:

• Week 1 - Planning
• Weeks 2 - 5 - The actual sprint. During this time, developers code while testers write test cases and do light testing
• Weeks 6 - 7 - Integration
• Week 8 - Deployment to live site
• Week 9 - Buffer, just in case

This is further compounded by the following:

“Notice there’s not a period for writing PM specs, dev design docs, or test plan/specs. We’re trying to address that starting in our next sprint.”

What scares me in this approach is the fact that there are 5 weeks of work (and growing) to encompass a 4-week Sprint. This is an example of a larger problem that looms in companies across the world. Instead of working inside a time-box, the team chose to do its “coding” during the Sprint and do everything else outside the Sprint. Being potentially shippable does not play in this model.

Being Agile is a mindset. It is understanding that writing code is only 5% of the work needed to ship software. Yes, he actually did write that. Writing code is 5% of the work needed to ship software. By taking an approach such as the one listed above, that 5% swells into close to 50%. As a result, things fall through the cracks. Integration testing, stress testing, environment management, documentation, you name it - it will be forgotten.

Just remember, in the end, Scrum is a framework. If projects fail, it’s not because of the framework, it’s because of the people. Frameworks do not fail, people do.