LATE FEEDBACK

One of the teams whose manager I coached had a problem - their tasks were systematically stuck in the TODO column during the testing phase. The team only does releases on Tuesdays. Tasks completed on Monday usually have a near-zero chance of being released the next day, and their release is usually pushed to the next Tuesday. This is a huge, unreasonable delay.

The team consisted of 5 developers and only one QA - Jean. Everyone, including Jean herself, admitted that she couldn't cope and was working too slowly compared to other parts of the team. She tried to solve the problem by working on several tasks at the same time, but as you can understand, this made things even worse.

The manager of this project identified the bottleneck and decided to increase the capacity of this stage by hiring another QA. What do you think is wrong with this decision?

Quality assurance

I am usually very suspicious of hiring. In my opinion, hiring usually doesn't solve a problem, it makes the situation more uncontrolled. So I asked some questions.

And what I finally found out was that tasks don't really stay in TODO. They get moved back to the TODO list when QA finds a bug. Then Jean invites the developer who did the task to fix the problem. It is a strange way to get around WIP limits.

So now we can conclude that even if we hire 10 QA people, it won't help speed things up. The only thing that really slows things down is poor quality work in the development phase.

But blaming developers for everything in order to motivate them to do better is not the solution. "Work better, you motherfucker" just doesn't work. I believe most people want to do a better job. They just don't know how.

Solution

The solution is to expand the scope of QA's work a bit. QA should add some test cases to a ticket before development begins, and developers should test their work against those cases.

I do not mean a huge list of all possible cases. You should avoid perfectionism - this work needs to be done quickly. It is enough for developers to check one "happy path" (a positive scenario) and do a few "negative" tests (where things could go wrong). They just need clear instructions to follow.

Someone might find it a little uncomfortable or even offensive, but you don't have to care. As a developer, if I had to choose between people endlessly pointing out my shitty work to me or having a list of expectations, I would choose the second. Similarly, in QA, if I can spend some time making a list of my expectations instead of having 10 buggy tasks in my hands at the same time, you know what I will choose.

Code review

Code review is a technique that was born in the zero-trust environment of open source software. And it is undoubtedly the right place for it. But in regular product teams, it is toxic. The team couldn't be a team without building trust.

Interestingly, the hardest defenders of this are the developers themselves. Even the regular ones who don't have the possibility to deliver their changes directly, not just the seniors.

I usually hear 3 common reasons for keeping CR:

1. I just want someone to look at my code. Maybe I made mistakes.

This is nothing else than passing the responsibility to someone else. If you are not sure that your solution is really bug-free, a quick look by someone else is no guarantee that it is. Before moving a ticket to the next stage, you need to be sure that your code works, and that you haven't broken anything. Unfortunately, you can't do that without proper automated testing. In fact, CR is pointless, since the real bugs are rarely found by eye inspection alone.

2. We share our knowledge this way

I don't think it's a good idea to share your knowledge in the context of criticizing someone's work. That person will be under a lot of stress and can't be a full member of the discussion. Just find another time to do it.

3. We prevent bad coding style or architectural decisions from seeping into our code base

Coding style should be defined by linters. The team would discuss linter configuration once and forget about it. Other problems in the code could be found by static analysis tools and others specific to your language - there are many tools out there. Developers need to know the basic expectations of their work before they start.

SOlution

Simply remove CR from your process and give everyone permission to merge.

But if you have a "unique situation" and you can't just remove this step, know that you're giving people feedback too late.

One solution might be Design Review. It's a technique where you don't discuss a final result, but a plan. And yes, now developers should create the plan before they start coding. But I think it is wise to articulate your thoughts before you start coding. Even just for yourself.

You create a kind of schema of the changes you want to implement. You will spend much less time on this than on full feature implementation, and you will be less likely to stick to it. Then someone will review your plan and discuss any bugs they find with you. Reviewing a small plan is easier and faster than reviewing 3k lines of code, and of course more productive.

But it still blocks the flow. So my advice would be to just train developers, agree on some rules, and get rid of Design Review after a while.

CONCLUSION

1. If you think you have a bottleneck in QA, you are probably wrong. It usually means you have a poor quality in earlier stages.

Do not increase the number of QA people. It won't speed you up.

Instead, get your developers to properly test their own work before pushing it to the next stage.

2. These traditional steps like QA and CR don't add value to the product. They just record losses. And it's good if they find some real problems.

But usually, they are just centers for cultivating perfectionism. When people try to do more work at this stage, they try to find defects that have about 0% impact on customer satisfaction.

3. Create a safe, fast technical environment with instant feedback and educate people instead of creating another blocking stage of QA.

Every time QA or CR stages block a work item from going to the next stage because of a defect, it's a huge problem. It's a Muda. Devs could know about expectations by having test cases, linters, and autotests.

And of course, if your QA work is slow because their test environment takes a few hours to set up, you should fix that problem.

And even if it seems complicated and you do not have time to develop all these new processes, at least now you know where to start. Take a few short steps.