Does Scrum-Waterfall work?

I used to be talking with some teams who claim that they’re running Scrum on their software development projects, or, at least they believe they’re.

  • “We’re applying all the Scrum ceremonies, fixed duration Sprints, Sprint planning, Daily stand-ups, Sprint reviews, and Retrospectives”.
  • “The team is also using Burn down charts to track the performance.”
  • “The only issue is that we didn’t see big improvements after the team started using Scrum.”
  • I was quite interested why Scrum doesn’t help in their projects. So I tried to dig into the details. I was curious how their teams run the development activities inside one Sprint.
  • “Well, the first thing we do before we start a Sprint is to have the team break the User stories down into tasks. Based on the technical architecture, we’ll have three levels of development activities – design, coding and testing.”
  • “We use 3-week timebox for each Sprint, so usually in the first couple days the team will work together to get the ‘JIT design’ done; then the team spends about 7 – 8 days to complete the coding part; at the last week we’ll involve the testers to test the outcome while at the same time the developers fix bugs they identifies.”
  • I was a bit surprised since it sounds so much like a traditional waterfall approach even it happens inside one Scrum Sprint. So I tried to make it clear what the relationship between their tasks and User stories looks like. To my big surprise I got the below response:
  • “There are no direct relationship between User stories and tasks, we mix all the feature-related User stories up and have the team focus on the tasks – anyway we need to get them done by the end of the sprint, so the entire team will work step-by-step to get the feature done.”

Bad smell to me. Probably this is really the reason why their “Scrum” doesn’t help – they are just applying a Scrum-like format for the team but essentially it’s still a small waterfall inside. Some reasons I believe this doesn’t work:
  • Not working according to the User stories indicates that they’re not delivering small pieces of potentially shippable products – this doesn’t align with the Agile spirit of “eat small bits”.
In a real Scrum environment, the Scrum team should always be focused on a list of prioritized User stories, and User stories should be the simple and unique base work items to everybody. The team should be focused on User stories rather than “feature”, this is the first challenge the team will be facing if they don’t want to run Scrum-waterfall. It’s not easy to break the User story epics down into real User stories, if the team doesn’t want to do it regarding the technical layers. I like the approach what my team was using: for one big User story epic which focuses more on the business value, they try to decompose it to several independent User stories according to the user interaction. Sometimes even a series of page controls would make up one User story, if the end-user could complete a meaningful interaction with the system. And on the back of the story card, the team writes the functional tests down as the definition of done. This helps the team have a list of simple but clear User stories that 100% align to the business value, and at the same time are testable.

This is the foundation how the team executes the development in the Sprint. Different from the teams I was talking with, I believe the team should not mix all the User stories up and then have the task break down done according to the technical architecture. Team should get the User stories really done one by one – complete JIT design, development (which should be driven by tests), and the final testing for one single User story, and then start another one.

Sometimes if the team has the capacity and the User stories are really granular, I think it’s also good for the team to start a couple of User stories in parallel – but for each User story, it’s still going to be a standalone development cycle, you cannot mix them up, that is the real value Scrum provides – always focus on the highest priority business value, deliver small pieces of potentially shippable products iteratively, and be able to inspect and adapt frequently and repeatly.