How to deal with a Dev Team that refuses to analyze/investigate the source of the issue, and just blames the process

Question

I work with the development team as a Scrum Master/PM. We usually follow a structured process where features are delivered to the dev team in a sequential, broken-down manner. This helps avoid complicated dependencies that could result in blockers.

Typically, the team doesn't take on many user stories in a sprint to keep things manageable. However, in the past two sprints, we had to expedite a release to production, which led to the team working outside of our usual process.

After the release, during regression testing, the QA team discovered a major issue — something incredibly obvious that we somehow missed. I asked the team to investigate this issue or conduct a post-mortem to understand what went wrong (beyond just working outside the process).

This request resulted in significant backlash, with the Technical Lead even yelling in caps lock, "CHANGE THE PROCESS." This reaction shocked me for several reasons:

1. No one was blaming the team.;
2. The bug was so serious that we needed to understand how it was missed;
3. We can't use the process as an excuse to ignore issues.

It's important to note that this situation was unique. Usually, the team works in a relaxed manner without such issues. This incident kind of showed that we aren't prepared for stress scenarios, which, while rare, we need to be equipped to handle.

The team, along with the Team lead, refused to investigate further, insisting that the issue was purely due to the process and citing a lack of time for testing.

Do you have any suggestions on how to handle this situation?

Answer 1

The framing that the team is refusing to investigate further doesn't seem to be accurate. They have surveyed the issue and the leading causes and determined that the expedited process is a likely cause. Based on my experience, I can confirm that having alternative process flows, especially those that try to "expedite" or otherwise shorten a process to get work done faster, often have problems. I don't see a reason why this shouldn't be the start of a conversation between the development team and the product team to understand the need for an expedited process.

One example of a flow for such a conversation would be to first understand when the expedited process is triggered and what needs to be done to reduce, if not fully eliminate, the need for using such a process. Reducing or eliminating the need for an expedited process will likely take time and effort, so the conversation can pivot to low-cost and low-effort changes to the expedited process to reduce misses until it can be removed. If it cannot be fully removed, coming to an understanding of when it will need to be used and what the risks of using it are can be a part of the conversation.

Focusing on the process - the process for choosing to use the expedited process, the overall risks with the expedited process, and the workflow and timing of the process activities in the expedited process - should be the point of the conversation.

Answer 2

I work with the development team as a Scrum Master/PM.

No, you don't. Either you are a Scrum Master, then you should tell yourself that there is no PM in Scrum... or you are a Project Manager, then you should tell your Scrum Master to get lost because you aren't doing Scrum.

Either way, get your process straightened out. I am not saying it is wrong, but it isn't Scrum.

Do you have any suggestions on how to handle this situation?

For starters, you have asked, they have answered. Why don't you just believe them? You normally do more testing, they have identified the mistake as a direct result of skipping testing, they want to do more testing.

That sounds perfectly reasonable. What exactly did you expect to happen?

"Expedited" is a nicer word for saying whoever is in charge of planning failed at their job. That happens. We all do. If a programmer fails, it's a bug, if someone fails in planning or managing, it's "expedited". Or Crunch time. Or "we need this real quick". But make no mistake, your developers know exactly who failed. And it wasn't one of them.

To force them to grit their teeth and suggest words by which the planning failure could be twisted into their problem is going to produce resistance. They told you nicely, that the failure lies squarely with you. And you insisted that that cannot be and it has to be them. Well, I can see why they are unhappy.

Answer 3

You rushed a release to production and it went sideways. The team is telling you that they didn't have enough time to test and that the "expedite" process used was to blame. Yet with this statement: "We can't use the process as an excuse to ignore issues" you imply that the process is just fine.

Well, both of these things can't be true at the same time. So you need to sit with your team and discuss what happened. Do it during the retrospective.

The purpose of the retrospective is to see what went well, want didn't go so well, and what can be improved going forward. Capture this as a "didn't go so well" and discuss it. If you had your retrospective already, then maybe wait for everyone to calm down and then have a separate discussion about it.

You did mention this is important. And most likely you will have this expedited approach again. So do you want to fail again?

Whatever happened needs to be explored and an agreement needs to be made on how to do it next time. If lack of time for testing was indeed the issue, then the solution seems simple: allow enough time for testing.

Make sure the retrospective is a safe environment to discuss this. There seems to be some tension already, so make it obvious that, as you added in your bullet points, no one is blaming the team and the issue was serious and you need to understand what happened to prevent similar things from happening again. But stop at this. Don't add your third bullet point to the conversation.

Your third bullet point just dismisses the conversation entirely because it indirectly reads as "let's not find excuses to ignore the TRUE reason we failed". You basically concluded they are wrong before even having the conversation. So it's no wonder everybody is pissed off.

Answer 4

I think the problem is that you want to pull everyone to a table and "have them talk about the situation". That is absolutely tedious and futile for the team. For them this is all in the past already. The team does not bother investigating. They already made up their mind. And for a reason. Also the team lead told you in his authority what the problem was.

There is no point in digging deeper or try to "understand" what went wrong. The situation is blatantly obvious. But it seems the result is somehow not "acceptable"? That is a management issue. The team has nothing to do with it. Leave them alone. It's your job to investigate and find out on your own what lessons to draw from it, not theirs.

So my suggestion is: If you need more information, do not conduct meetings with everybody. If you want to have details on points which are not clear to you in your attempt to investigate, then make a one-on-one meeting and make it a casual talk, not an investigation. Better yet, have your questions ready, do not let them make the work. Make clear, that you need the help at this special question, not to have the whole thing explained to you by them. Preferably invite the team lead, so the others can continue their work.

Accept the team lead to be the speaker for the team. That is a must. Otherwise the whole team feels like being questioned or otherwise scrutinized. That is detrimental. It fosters mistrust towards you. You need to accept their judgement, even if it is not the answer you like to hear.

In this presented case, nobody is happy with how it went. Just tune into that. Don't force "improving things for the next time we want to rush things" from this situation, it is already tensed up enough. There were special circumstances which should not be tried to make the standard for next time. That is not a sustainable/normal mode of operation for a team.

Save/protect the team, not the process. Shit happens, so what. Better luck next time.

Maybe even an apology is in order or some sign of appreciation at least. Value their efforts trying to deliver and fulfilling what was ordered (rushing, not making an error-free release). This was as good as can be. The circumstances are not their fault.

(On a sidenote: It is evident that the team is not the problem, because QA were able to detect the problematic bug. But it did regression testing after the release... what a non-sense. Regression testing is of course to be conducted before releasing. Then the problem would have had been detected as expected -- Ok, maybe release is meant as the normal handover from DEV to QA, not going live. But in this case, the bug never went live, right? QA detected, DEV fixed, re-release, re-test, until going live. That is just how it goes, nothing special about it. Think of your team unit (DEV+QA) of having performed flawlessly. If you think QA/re-release/re-test is too expensive, maybe consider a continuous integration setup like Jenkins or TeamCity etc.)