Don't get it, don't make it, don't send it!

Don’t get it, don’t make it, don’t send it!

“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 more about it in his book, Gemba Kazien. This principle will help you optimize the  flow on agile projects.

Though it was first formulated for production / manufacturing industries (as most of the lean principles), it can be easily applied to agile projects.

Having the validation team as a bottleneck is not so uncommon in agile projects. Although there might be various reasons behind it -such as estimating stories without including the testing effort, tech debt, etc.-, one of the most important contributors to that situation is the “debt” that tester’s are inheriting from the upstream. A poor analysis on the upstream process will have a considerable impact on development but will have a bigger impact on the downstream process, such as the validation. The cost associated to a story lack of quality increases as the story is propagated to the downstream system.

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 overall 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 “tester”s) does not have the 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.

Don’t make it: Remember, “quality first“. Always. Do not sacrifice from the quality for the sake of cost or delivery. Keep in mind that delivering a product without meeting the quality requirements does not make any sense. Also remember the cost of the 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 it in total?

Don’t send it: Do not send a batch of work to the downstream (i.e. from analysis to development or from development to validation) if you think that you did not build the quality in. If your downstream is starving for work, it is a symptom of failed or bad process management. You should not rush and send your work to downstream to feed the starving downstream. Instead, stop and solve your starvation problem. Learn your lesson and focus on solving the root cause of the problem. Starving downstream processes are not a root cause but a symptom of the problems you have on the overall process management.

To follow these practices you can use some tools or create some guidelines.  Having hand-overs between processes might help to create awareness when you first start doing it. Try to make these hand-overs not constraining to not to alienate people.

But also, keep in mind that you need to create some standards.

No standards, no improvement.