If your Sprint begins with two days of design followed by six days of development and finally two days of QA, each phase stacked right behind another like dominoes, then congratulations…you have a mini waterfall.
Your Sprint May Be A Mini Waterfall If….The Team Is Working In Silos
Let’s walk through a scenario. Let’s say we have a team of four Developers and two QA. The team pulls in four Stories into the Sprint. What would be the most “efficient” way for us to assign out the work?
Parse out one story to each developer and let them own it from beginning to end? And then split the QA folks across two stories each? Developers may prefer it this way because it’s easier for them to work on their own with total control to do things the way they want. When I was a developer, this was also my preference.
While it feels efficient at an individual level it makes for a long feedback loop and a greater risk of carrying work over to the next Sprint. It has the same Risk Iceberg that a waterfall release does where we compress QA at the end. Finding defects late will lead to unpredictable velocity.
So what do we do?
In Agile we want to focus on delivering early and often. We want to shorten the feedback loops. Instead of going for individual efficiency, we suggest acting as a team and trying to get stories all the way to “Done Done” every few days.
Your Sprint may be a mini waterfall if…The Team Is Not Swarming
Running the scenario above and switching from a mini waterfall to a true Sprint is hard work and requires teams to learn new skills like breaking work down and swarming. In order to finish stories completely, multiple developers must swarm and determine ways to get QA involved earlier. Sometimes that is done by Developers writing Unit Tests early; sometimes that means getting early drops of code to QA. This mentality will force process change.
Once upon a time during a team retro when I was a ScrumMaster, our QA lead, Dena, asked the developers, “How do you test your code without deploying to the QA environment?”
They explained how they build, run, and test the code locally. She asked if she could do the same. They trained her on how to sync the code and run the server locally. From then on she was able to get code updates throughout the day as opposed to waiting on the nightly build.
Your Sprint May Be A Mini Waterfall If….Stories Are Not Decomposed
In order to swarm effectively we recommend creating tasks no bigger than a day. This allows developers to pick up different pieces and work collaboratively together for the common goal with daily visibility into progress.
If teams were using a task hour burndown, it might look fine throughout the project but there is a big risk in carryover because there may actually be no progress on stories at all. It is more important for a team to measure a Sprint story point burndown during the Sprint because it’s a more accurate window into the progress throughout the Sprint.
By breaking work down and swarming this should allow us to see story point progress thus reducing risk and allowing the team to become more predictable. Also, a side benefit of swarming will be increased quality and more knowledge transfer.
In football, a team can get in the red zone, but they don’t score until they’re actually in the end zone. Same with Agile. In fact, the Agile Manifesto, “Working Software is our primary measure of progress.” Instead of delegating work by developer and working in silos, create cross functional teams that can swarm and get stories past the pylon.