“Don’t get it, don’t make it, don’t send it” is a slogan to emphasize the 'quality first' practice in Gemba Kaizen. It was first formulated by Masaaki Imai and you can read about it more in his book, Gemba Kazien.
Though it was first formulated for production/manufacturing focused industries, as were most of the lean principles, it can be easily applied to software engineering using Agile Methodology.
Having the QA team as a bottleneck is not uncommon in software delivery projects. Although there are various reasons behind it (such as estimating stories without including the testing effort, tech debt, etc.), an important contributor to that situation is the debt that QAs inherit from the upstream. A poor job done with analysis in the upstream process, will definitely impact the downstream processes such as development, testing and UAT. The cost of lack of quality in a story increases as the story is propagated to the downstream, without addressing the quality issues it contains. It is a cascade effect. The failure demand also inflates.
Following the “don’t get it, don’t make it, don’t send it” principle will have a positive effect on the quality of your product, and will decrease your delivery cycle.
Don’t get it
If you think that the story you are getting from the upstream (upstream is 'analysis' for developers and 'development' for QAs in a somewhat rigidly defined delivery project) does not have quality built in, do not get it. Do not accept it.
If the story does not have clear (or enough) acceptance criteria to start development, do not get it to develop. If the unit tests are not properly implemented, do not get it to do the functional testing. As quality is not just the responsibility of the QA, but is a practice that is nurtured and matured by the whole team, you have all the leverage to not to accept a poorly analyzed story. Story kick-offs are good instruments for quality checks.
Don’t make it
Remember, 'quality first'. Always. Do not sacrifice quality for the sake of cost or delivery. Any product which a customer is not willing to pay for, is a waste. Keep in mind that delivering a product without meeting quality requirements, does not make any sense. Also, remember the cost of lack of quality. If you sacrifice quality and decrease the first short term visible cost, are you really decreasing your cost? Maybe you are increasing your overall costs. There is a brand image angle as well, which cannot be measured by tangible financial figures.
Don’t send it
Do not send a batch of work to the downstream (i.e. from analysis to development or from development to QA), if you think that you have not built the necessary quality in. If your downstream is starving for work, it is possible that it is a symptom of failed planning and bad process management. You should not rush and send your work to feed the starving downstream. This kind of behavior will cause more issues, rather than solve your starvation problem. Learn from it and focus on solving the root cause of the starvation. Starving downstream processes are not a root cause by itself, but a symptom of the problems that you may have in your overall process management, such as poor planning, over-engineering and sometimes, even your lack of testing coverage.
To follow these practices, you can use tools or create some guidelines. Having hand-overs between processes might help create awareness when you first start doing it. Try not to make these hand-overs too constraining, so as to not alienate people.
But also, keep in mind that you need to create some standards. As Taiichi Ohno said once,
You need tangible and measurable standards to compare and find out your progress. No standards means no improvement. Flexible and Agile software delivery needs a lot of planning and standardization, although it might not seem that way if you are new to such a delivery methodology. You should have story kick-offs, have hand-overs, measure your lead time, code coverage tools, measure your velocity, have retrospectives to reflect and talk about how to improve and make showcases to your users with pride.
There are numerous tools that you can use and methods that you can apply. One size does not fit all. It is up to you to get the most efficient set of methods, sometimes even by trial and error.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.