I recently tweeted the above meme and the number of likes and retweets it received was astounding to me. It grabbed so much attention because it’s something so many of us can identify with: turning our Scrum sprints into mini-Waterfalls.
What is Waterfall vs. Scrum?
Scrum, on the other hand, is supposed to remove those sequential phases and allow for constant collaboration and movement between Product Owners (B.A.s), Developers, and Testers in a time-boxed sprint, typically 2 weeks.
When I say mini-Waterfall, I specifically mean the development environment where work is completed in sequential phases. Typically, Waterfall looks like this: A Business Analyst will write requirement specs (think multiple long and grueling pages) and pass it along to Developers who will implement everything. Once the dev work is all done, they throw it over the wall for QA to test. Testing, in this model, can last anywhere from weeks to months. I’ve seen the testing phase last an entire quarter!
Some time in the mid-2000s we realized that the Waterfall model wasn’t efficient and thus the great migration to Scrum accelerated. As we changed our way of working, we adopted new work structures, such as working in sprints. Now instead of having months’ worth of work to test at once, we have days. In addition, we are breaking up those large requirement docs into small bite-size stories. Allowing for small testable chunks of code to be tested throughout the sprint, instead of at the end of a development phase.
On paper, this all seems great! Why then, do so many of us identify with that meme above? Why does it still feel like we are taking a phased approach, even if it’s within that 2-week sprint? And how can we avoid that and truly shift our mindset?
How Can You Avoid Mini-Waterfall Sprints?
The common theme throughout the below points is to get work to QA as soon as possible and test continuously throughout the sprint. Being able to do that will help you avoid mini-Waterfalls. Let’s examine some points of consideration:
- Engage QA Early and Often: If you’re still only engaging QA when a story is ready to test, you’re missing an opportunity. Bring QA into Epic/Feature conversations as early as possible. Ensure they are engaged in Grooming and Refinement meetings. This allows QA to voice concerns and think through their testing strategy from the start of the work.
- Automate Early: By automating early, and ensuring stable tests, you will be able to run automation frequently and provide feedback throughout your sprint. To accomplish this, you must have open collaboration between Automation Engineers and Developers so automation engineers have the information they need to automate before Developers have even finished their work.
- Execute Automation Often: If your automation is stable, and runs quickly, you’ll be able to maximize value by running it often. If you don’t have a CICD pipeline setup, you can still manually kick off automation so it’s running multiple times throughout the sprint. This allows you to get quality feedback to the team quickly and often.
- Unit Testing Coverage: Prioritize unit testing and the payoff will be apparent. Being able to run unit tests every time code is checked-in will allow you to create a quick feedback loop for your developers. This is the first key to testing early and often.
- CICD: Ideally, you’re able to get your automation into a CICD pipeline and have that executing every time something changes.
- Break work up to the smallest testable size: One common mistake I see played out, again and again, is creating large stories to avoid the overhead of having multiple smaller stories. One way to recognize this is if your burn-down chart is a plateau and then randomly drops off at the end of your sprint. If you’re seeing this pattern, you need to focus on breaking down your work into the smallest testable size.
- TDD (Test Driven Development): This technique is where you write your tests to fail before you write the code. This technique helps push testing left and ensures testing and development are happening at the same time, not as a phased approach.
- Encourage Swarming: This is a hard shift, especially for organizations that have specified testers, in testing roles. Developers will wrap up their stories early in the sprint and want more work. The problem is, you have way too much to test already and there’s no way you’ll be able to test more work. You push back, and the manager tells you that developers can’t just sit there without work. And they’re right! However, instead of taking on more development work, encourage developers to help test. If you’ve documented your testing strategy, it should be simple for them to jump in and help. This could mean writing automation or manually executing tests.
- Identify test-design early: Typically, when I see successful testers, they are working through their test-design before stories even come to them, specifically during epic plannings. Test-design doesn’t have to mean full-on test case writing, it could be as simple as identifying scenarios or working through mind maps, etc… The idea is to think about testing while development is happening, and then talk through that testing approach with your development team.
Conclusion
The above points of consideration don’t fully capture everything you can do to avoid mini-Scrum Waterfalls, as the focus of this blog is around testing. Personally, when I think about how to avoid mini-Scrum Waterfalls from happening, I first think about how to reduce phases within the sprint. Development and testing can’t be separate phases as that leads right back to Watergile! When you think through the issues your team is facing, think about the whole picture. What can you do differently to get work accepted throughout the sprint, instead of all at the end?
I’d love to hear your thoughts on what you’re seeing or what is working for you!
Originally posted via the Agile Testing Alliance Blog-a-Thon!
The QA Connection Blog 