This blog discusses one of several advantages of a continuous flow model when compared with a timeboxed iteration model such as scrum. Specifically one affecting QA. A continuous flow model eliminates QA bottlenecks that often occur at the end of every sprint in a timeboxed iteration model.
QA in Kanban
This blog assumes that your team has separate QA and development team members. That is, some team members specialize in coding/unit testing software and others that do not code but rather focus specifically on test.
In a timeboxed iteration model, the team is working on items that complete throughout the timebox. Some items will be coded/tested by the developers and ready for the QA specialists to test early in the sprint timebox. But by definition, some items must complete towards the end of the timebox. I have even seen some teams where the majority of items complete at the end of almost every sprint. QA gets left holding the bag every sprint. This pressure felt by the QA team members to complete all the work each and every sprint cannot always be remedied with aspirin, beer, or M&Ms.
Options that are often unrealistic
Aside from QA working lots of overtime at the end of every sprint, there are a few potential solutions to this common problem. The 1st is to fully automate testing such that there are no QA specialists needed. But that is out of scope for this blog and often times simply not realistic.
The second solution is for the developers to pitch in each and every sprint to help the QA specialists. That sounds good in concept and scrum says all team members should be cross functional. But, in reality, there are often issues with this option. The developers may not be as good at testing as the QA specialists. After all, the QA specialists chose test as a career for a reason. They are the ones who are passionate and good at what they do. So there is a chance that quality will suffer if done by the developers. If the developers pair with the QA specialists that may solve the issue. But in this case, the team is probably not performing as efficiently as they could be.
Many teams wind up putting pressure on QA to finish as much as they can and then whatever items do not get complete get carried over to the next sprint. This option skirts the whole purpose of the timebox model in the first place as work is continually carried over from sprint to sprint.
The answer is simple
The final solution is to simply switch to a continuous flow model. It is the timebox that is causing the issue since everything must complete at the end of this arbitrary timeboxed constraint. If you remove the constraint then all items will be tested whenever they are done. If test spans a 2 week timebox window, it is not an issue. The picture below depicts this difference.
The blue part of the diagram depicts a scrum team doing 2 week iterations. By definition, QA has to be the last activity at the end of every 2 week sprint. The yellow part of the diagram shows a Kanban team where work continuously flows from dev to QA. As you can see from the diagram, QA happens whenever Dev completes without an arbitrary 2 week cut-off. It is simple, yet powerful.
QA in Kanban is one advantage of a continuous flow model over its timeboxed counterpart. To read about another advantage of continuous flow, see the blog https://kanbanmentor.com/continuous-flow-saves-time-over-moving-work-back-and-forth/. That blog discusses the waste inherent on most scrum teams moving work back and forth between the product and sprint backlogs.