How to provide feedback when a feature is not ready for release?

Question

I've been having quite rough time at work recently. I found the functionality that we have been delivering was not ready for release: too many bugs and we were not able to get feedback about the feature from a pre-production environment, because the environment was not ready.

So I have escalated the problem to managers stating that the main story is not ready for production. A developer that spent last months on implementing this and related stories felt offended. I guess because he has been asking the team for feedback, testing and reviewing for some weeks, and we provided that too late. So it seems he may have read "not ready" as saying that this is all his fault.

I know I could do better. But how should I have written it?

And how to provide a feedback to avoid such conflicts?

It is one of the hardest skills for me to learn.

Answer 1

From your explanation I get the feeling you are not working Agile, or not very effectively? It sounds as if the core issue here is the (testing) process.

Firstly, quality is the responsibility of the entire team. See also the whole-team approach. In this sort of team spirit, your developer should not feel offended.

Secondly, in your phrasing you should simply note (1) your advice (GO/NOGO) and (2) the reason: the acceptance criteria have not been met (including the obstacles why not). You didn't make the deadline as a team. Especially in your case, it's doesn't appear like it's one person's fault. Then, in a retrospective meeting, figure out what went wrong where, and how to prevent it next time.

Thirdly, environment not available, too many defects to fix in time, ... This again seems like no issue with people but with processes. Maybe sit together with the developers and management to think up a better way of planning the project or sprints.

Also, since you mention "months"... I assume you have technical/testing debt? If you don't treat this correctly, the snowball-effect will end up screwing you over. To the point where the release might be cancelled, as in your case.

So try to have a constructive meeting about the aforementioned items, if you can. This will be profitable in the long run.

Answer 2

You did not say what in particular the developer objected to about your assessment, so it is hard to advise you on how you might have improved your writing.

That said, the best feedback focuses on repeatable, measurable specifics: measurable specifics because they are less subject to interpretation, repeatable because anyone with the same data can reproduce those measurements.

It helps to talk about the results you want to achieve rather than the people who need to achieve it.

As an extreme example, "Bob's code isn't ready" may sound like a criticism of Bob, who in other circumstances may be a great software developer. It is also not specific enough, because everyone may have a different sense what constitutes ready.

On the other hand, "System X still has N high-priority bugs" is both quantitative and repeatable (anyone can query your bug tracking system and count the bugs). Similarly, "We need N days to test system X in a pre-production system, which unfortunately was not available until very recently" should make it clear that the lack of pre-production feedback was not the developer's fault.

Answer 3

Long projects should have milestones every few weeks. As time passes by and milestones are not met, it would be obvious that final deadline will not be met. You can even have weekly meetings where you can ask about the confidence that next milestone will be met, to see where more resources are needed (if available).

This way, delay is not a surprise.

QA cannot "assure" quality, just "assist" business managers by providing the information about status of the project. QA cannot say "not ready". This is business decision. QA can inform about the number of outstanding bugs, and time estimate to fix them (if not new would be found), and possible confidence level about more bugs present.