A team can be found in many operational states; the usual ones are forming, storming, norming, and performing. Each state has challenges, but most can be attributed to the storming phase. Here the team shows the "Five Dysfunctions of a Team*": Absence of trust, Fear of conflict, Lack of commitment, Avoidance of accountability, Inattention to results. Usually, the finger-pointing goes through the manager at this state, and they are generally addressed to the chain's weakest link. Most cases involve engineers working in isolation from the rest of the team, such as QA, DevOps, or to best blame a functionality on, the Frontend Engineer. Complaints can come in many forms, but they usually find their way as a written communique; hiding genuine emotions and breaking through the defense is more manageable.
Solution: The team's conclusion from the low quality of the product is focused on the work of the DevOps engineer. From personal experience, I have worked with excellent DevOps practices in place, such as those provided by the "Accelerate*" study. I've also worked with a great team with no DevOps practices. They did everything manually since that was the nature of the application, and placing DevOps would open unnecessary burdens to the team and prolong the deployment cycle even further. The first team, even though they had a perfect CI/CD in place, had a terrible throughput, while the second team yielded much more excellent results faster. DevOps is not a silver bullet, as argued in the book. Good research has to be done on whether DevOps or, more recently found as CloudOps is a way to go in a specific case, ex. Do we plan to develop and maintain this product for a more extended period (is it an engineering effort?), or do we plan to try out an idea as an MVP that we can perhaps include a CI/CD/CD pipeline (a programming effort?). For more information about the difference between software engineering against coding or programming, read the first chapter of "Software Engineering at Google*."
Sometimes the client can provide feedback about what they see as a possible root cause of a problem. Usually, they give this feedback through an email without any prior investigation, and it shouldn't be acted on immediately. First, we need to further address this on a call as a better approach in this situation, if possible, to get a better insight and more information on why this is their conclusion. Let's say that they usually see the result of an effort and jump the gun that it has yet to be implemented as expected, so the logical conclusion is that the frontend has not been according to specification. This conclusion that the Frontend Developer is the chief problem can be challenged. How did they reach this conclusion? Who reviewed the Frontend Developer's work? Are they unsatisfied with the UX design instead of the frontend work? Who provided this information and why? We need crucial information that can dictate the course of action. We need to find the root cause of the problem, taking every branch to its origin; perhaps this will lead back to a conclusion that it was wrongly specified or there were many ambiguities at the start that were not addressed, so the team did the best they could, given what they knew.
Assuming that the client is correct, and we should always investigate this option no matter how we feel about it, we should schedule a call with the FE developer to see if this is the case and inspect the things where they are pointed at. We should also talk with the Team Lead before the call and perhaps one or two of the FE developers' peers to collect more background information from several sources, so they are not biased. We should also consult the QA Engineer who has been testing out his work in the past and collect their insight.
Finding that the accusation is correct, we need to plan our next course of action – communicate this with the Frontend Developer face to face, carefully, and try to find out the cause. Perhaps there is some lack of knowledge, or perhaps there are some problems of personal nature. Maybe they did not find their proper place in the team, or their work is not appreciated. Anyhow, seeing that we can't solve the problem immediately, i.e., the quality of the frontend can't be improved, we can try to look for another Frontend Developer with a better experience as an addition to the team or as a mentor. This should also be communicated with the current Frontend Developer for openness and fairness, and transparency is the chief pillar of Agile, so they will know their options. Perhaps having a second Frontend Developer in the team can motivate the current one to provide higher quality, thus keeping both developers, if not in the same team, perhaps in the same company.
A similar approach can be taken for the DevOps work. Also, throwing away work should never be our first option. However, if the work of the DevOps Engineer is causing more harm than good, building on the existing work can slow things down even further. If no knowledge of how to improve the work of the DevOps Engineer is present, there are, again, several options on how to proceed. Maybe external consultancy can be used in addition to better educating the engineer on proper techniques and practices or to "patch things up" for the time being. However, a short-term solution to work without DevOps practices will significantly reduce the team's deliverability. Hiring a more experienced engineer in this position or a DevOps team lead can increase the quality of these roles for all teams and put higher standards and solutions into practice for long-term benefit. But we should be mindful of Brooks's law: "Adding manpower to a late software project makes it later."