How to Deal with an Underperforming Development Team

As the product manager, you trust the development team to do a good job. But some teams are delayed due to performance issues and are unable to provide working software reliably. This article shares my tips on how product people can deal with low-performance development team and help the team get better.

Listen to this article:

What is poor performance?

Before I discuss how you can help a team with missing accomplishments, let’s briefly explore what good performance looks like, assuming an agile, Scrum-based process is used. A development team does a good job if the following three conditions are met:

First, the group reliably meets agreed sprint goals and provides product extensions that offer a great user experience and display the desired software quality. Second, the team participates in ongoing discovery and strategy, and its members regularly help reduce product backlogs. Third, the team maintains a sustainable pace. Workload and power do not affect the well-being of team members.

If one of these requirements is not met, the staff should improve its work. Here are three common symptoms of a development team having a hard time doing a good job: The team repeatedly commits or provides buggy software; Team members expect you, the person in charge of the product, to do the product accumulation and write the user stories; And finally, team members have to repeatedly work overtime to finish work in the sprint.

As the product manager, you depend on the work of the development team and you are of course affected by poor performance. This includes the inability to release working software to (selected) users and customers, difficulty in reliably predicting the progress of development, and you may make an excessive effort because you do not receive the necessary support from the development team. It is therefore in your best interest to help the team get back on track. At the same time, you are not the boss, and you can not tell the team members what to do. What’s more, agile self-management team is jointly responsible for their performance. This can make it challenging to help a development team get better.

Share your opinions but do not tell people what to do

To discuss how you can help a struggling team, let’s use an example. Suppose you are working on a brand new product. The current Sprint has an important goal: to release the product add-on to select users and verify if the proposed functionality works for them. In addition, you invited the senior management sponsor to the upcoming Sprint Review Meeting to ensure continued individual support.

But during today’s Daily Scrum meeting, you notice that the progress of the sprint has been appallingly slow: a lot of tasks have not been completed, and some stories have not even begun. The development team seems to be lagging behind in the schedule and will have a hard time reaching the sprint goal. However, the staff does not seem to be worried.

In this situation, it can be tempting to intervene, tell the development team that they must work together and perhaps even assign specific tasks to individual members. But that would be wrong. You would interfere and hurt the self-management of the team. A nimble team is responsible for planning and monitoring the work, reviewing progress on a daily basis, and deciding how the work should be done to maximize the chances of meeting the sprint goal. If you went in and took control, you would act as a project Manager and basically eliminates the power of the team.

But that does not mean you should be watching from the passive side and seeing the team fail. If you believe the development team needs your help, talk to them directly, for example, after the Daily Scrum. However, ask team members for their opinions before you share your opinion. You could say, for example, “How are things going? Do you think you’re on your way to meeting the sprint goal?” Then listen carefully to what people have to say.

If you are not satisfied with the answers and believe that the team members are not aware of the issue, share your opinion without judgment and criticism. You could say, for example, “It seems to me that development progress has been slow. Some missions have not been completed, and some stories have not begun. Do you think that is true?”

But leave it to the team to decide what to do, and do not force your point of view on them. You may be wrong after all: the staff may be doing a great job despite your concerns. If you are not sure if you need to say something or not, talk to the Scrum Master who is responsible for helping the team practice self-management, as I will discuss below.

Take stock at the end of the sprint

Once the new product add-on is available, you know for sure how much the development team has achieved. Based on a live demonstration of the add-on, you determine which items accumulated products have been completed using the definition of executed, and the quality criteria that each add-on product must meet. This allows you to understand if the goal of the sprint was achieved and if the team did a good job.

If it turns out that the development team failed to meet the sprint goal, then offer your honest feedback. State clearly what was achieved and what was not. For example, if the team was able to complete only half of the product aggregation items they pulled into the sprint and missed the sprint goal per mile, then do not find that the team’s performance was fine. it was not. The team just failed. I have seen Scrum product owners come to terms with a team that lacks accomplishments, partly because they hoped things would improve on their own and partly because they shyed away from a difficult conversation. But chances are nothing will change for the better if you do not address the issue openly.

At the same time, identify with the development team and speak kindly. Do not look at friends, and avoid blaming and judging people. Treat the team as a valued partner and acknowledge the effort the group has made. In addition, put the issue of performance into context: a recently formed team and a team that has changed significantly are expected to require a number of sprints before members can meet the sprint goals reliably. Similarly, a team facing significant technical challenges may have difficulty properly planning the sprint due to the existing uncertainty.

To give helpful feedback and maximize the chance that your message will be heard, you can say, “It’s great that you were able to provide some of the product backlog items. Thank you for that. To avoid a similar situation in the future. ” If you are angry or upset, take a few deep breaths and count to ten before you give feedback. If that’s not enough, take a short break and continue after you have calmed down. Although it’s fine to have hard feelings, to voice them is not right. I once witnessed a sprint review meeting that degenerated into a shouting battle. It did not solve anything, of course. Instead, it exacerbated the situation, destroying trust and damaging relationships.

Use retrospective to determine improvements

Whenever you run into performance issues, use a sprint retrospective to identify and address their underlying causes. For example, you may find that some of the user stories that entered the sprint were too large or lacking acceptance criteria, that the team did not use the definition of performed to identify the tasks required during sprint planning, that the software development environment was unstable, or unresolved conflicts resurfaced and slowed the team.

Take part in a sprint retrospective. But do not control the meeting and avoid blaming others and judging them. Instead, adopt a Thinking of contribution: I asked are you Can help prevent the same problem from recurring. Do not assume that a performance problem is necessarily the fault of the development team. Instead, cultivate an open mind and actively listen to suggestions from development team members. You may find, for example, that you have not shared enough with the people in refining the product backlog. This could have led to big and unclear user stories, which made it difficult for the team to meet the sprint goal. Or maybe you put pressure on the team and asked them to pull more work into the sprint than they could realistically handle. These two causes can only be fully resolved if you are willing to change your behavior.

If a performance problem persists despite determining its causes and implementing improvement measures, you may need to consider adjusting the team composition. For example, it may be helpful to dismantle a team whose members work in different areas, not related to the same product. You may also need to ask a team member who shows disruptive behavior to leave the team. However, none of these changes should be forced on the group. Instead, have an open and honest conversation in retrospect and look for a solution that works for everyone. It creates transparency, gives people the opportunity to contribute, and reduces the risk that people will end up being frustrated and feeling unfairly treated.

Finally, let the Scrum Master guide the session and suggest helpful ways to uncover the underlying causes and outline improvement steps that can be taken. If you do not have a Scrum Master or a nimble trainer, find an experienced and neutral facilitator who will ensure that everyone is heard, and no one will control.

Let the Scrum Master coach the team

As much as you want to help the development team, note that you are responsible for product management, not team coaching. This is the job of the Scrum Master or agile coach. If you do not have a Scrum Master, or if the person is not available or sufficiently qualified, then do not make the mistake of covering the work of the individual, certainly not on an ongoing basis. This will cause you to neglect some of your product management responsibilities – such as reviewing and updating your product strategy and roadmap – or sacrificing your health, none of which is desirable.

Instead, recognize that the lack of a qualified and available Scrum Master should be addressed and the decision makers in the organization should be contacted to find a solution. I personally consider it unfair to ask product people to act as the owner of the product if the Scrum Master role is not filled properly.




Please enter your comment!
Please enter your name here