When I think about the beginning of our experience with QA, it seems similar to the early stages of the automotive industry. I wasn’t around before Henry Ford introduced the assembly line, but I can imagine what it was like when a person built a single vehicle at a time. I can just imagine a car builder getting half-way through assembling a car and realizing he has no idea if he put the bolts on properly, or getting to the paint stage and realizing that the doors are not flush with the body. It couldn’t have been fun.
In the beginning of our QA timeline, the development staff was responsible for performing their own testing much like that early car builder. Sure, there might be others around who could lend a hand, but they might not have the time or proper skills to test correctly. Each programmer was essentially responsible for assembling the entire task together, mimicking their counterpart at the factory.
What if the factory builder decided to skip a step or relax on some of the guidelines? Who would notice? Who would care?
What if the developer decided to skip a step or relax on some of the guidelines? Who would notice? Who would care?
Obviously, the automotive industry decided this was not an efficient manner to build cars, and the same logic applies to the development industry.
When a development team is expected to move at an accelerated rate, especially during a ramp-up to production, the flow of changes requires everyone to move at the same pace – product, development, QA, etc. By moving more toward a true Kanban style of issue management, this can all be controlled without everyone getting lost or stalled. The issues to be worked are put at the top of the heap, they are taken off by the development staff, worked through to completion, cycled through the QA department, and deployed (or sent back if they do not meet specs); all while keeping the product assembly line humming along.
The benefit of getting the QA department right into the thick of this Kanban style of production is to eliminate the extra time needed at the back-end (the final stop on the assembly line) and to minimizes the delivery of a buggy product to customers. There no longer needs to be a substantial amount of time after development is complete to put everything through the final QA sign-offs; the testing is completed along the way.
Matt, you are right. Positioning QA so that it is at the heart of your dev efforts makes a lot of sense. Couple this with user testing that provides A/B options to dealers so that we develop highly usable work flows, and you have a clear win. Finally, if you insert solid QC before a product goes live, then you are golden. Good thinking!
Growing into these QA Kanban shoes, and since they are still new, blisters are to be expected 😉
and since my team turned on a dime, and adopted Kanban in exchange for our Agile hybrid SDLC during a very large and long release campaign, we’re currently suffering a bit of “……. bottlenecks in your process so that they may be addressed. Once we spot a bottleneck we stop adding more work to the bottlenecked queue and collaborate within the team to eliminate the blockage (e.g. move resources off build tasks and onto QA tasks).” (-from “An Introduction to Kanban by Rich Hewlett”)
One thing I don’t like with QA and Kanban, at least in the limited experience I had with it, is that it promotes the idea that QA starts working only when a particular task as been designed and coded because the QA column always come after the Dev column.
Years ago when I started in QA, I was told that half the job of a good QA occurs before there is a single line of code even written. And, IMO, if you don’t agree with this statement it means you are doing only testing (or Quality-Control), not Quality-Assurance.
I feel scrum gives me some visibility on how features are developed (are they testable? Could they break something else? Will we need to update our automated test suite?, etc…)
So being new to Kanban, I am searching for solutions to integrate rigorous QA processes in the flow. I suggested having a QA-review column before the DEV column but the team didn’t buy into it.
Any ideas?
I think the QA column you are talking about may be coming too late in the process. I think that a ‘story’ (or whatever you want) should not get onto the board until the quality controller has been involved to the point where they have made it testable (ideally with something like a Cucumber).