Dealing with an Underperforming Development Team

As the person in charge of the product, you rely on the development team to do a good job. But some teams are held back by performance issues and fail to reliably deliver working software. This article shares my advice on how product people can deal with an underperforming development team and help the group improve.

Listen to this article:

What is Bad Performance?

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

First, the group reliably meets the agreed sprint goals and delivers product increments that offer a great user experience and exhibit the desired software quality. Second, the team participates in continuous discovery and strategizing, and its members regularly help refine the product backlog. Third, the team observes sustainable pace. The workload and intensity do not affect the team members’ wellbeing.

If one of these requirements are not fulfilled, the team needs to improve their work. Here are three common symptoms of a development team struggling to do a good job: The team repeatedly over commits or delivers buggy software; the team members expect that you, the person in charge of the product, does the product backlog work and writes the user stories; and finally, the team members repeatedly have to work extra hours to finish the work in the sprint.

As the person in charge of the product, you depend on the work of the development team and you are, of course, affected by poor performance. This includes not being able to release working software to (selected) users and customers, finding it hard to reliably forecast the development progress, and possibly getting overworked as you don’t receive the necessary support from the development team. It is hence in your best interest to help the team get back on track. At the same time, you are not the boss, and you cannot tell the team members what to do. What’s more, an agile, self-managing team is collectively responsible for their performance. This can make it challenging to help a development team improve.

Share Your Views but Don’t Tell People What to Do

To discuss how you might help a struggling team, let’s use an example. Say that you are working on a new brand-new product. The current sprint has an important goal: to release the product increment to selected users and validate if the functionality offered works for them. Additionally, you’ve invited the senior management sponsor to the upcoming sprint review meeting to secure the individual’s continued support.

But during today’s Daily Scrum meeting, you notice that the sprint progress has been worryingly slow: Plenty of tasks aren’t finished, and some stories haven’t even been started. It seems that the development team is behind schedule and will find it hard to reach the sprint goal. The team, however, does not seem to be concerned.

In this situation, it can be tempting to step in, tell the development team that they must get their act together and possibly even assign specific tasks to individual members. But this would be wrong. You would interfere with and damage the team’s self-management. An agile team is responsible for planning and tracking the work, reviewing the progress on a daily basis, and deciding how the work should be done to maximise the chances to meet the sprint goal. If you stepped in and took control, you would act as a project manager and essentially disempower the team.

But this does not mean that you should be a passive bystander and watch the team fail. If you believe that the development team needs your help, then talk directly to them, for example, after a Daily Scrum. However, ask the team members for their views before you share yours. You might say, for example, “How are things going? Do you think you are on track to meet the sprint goal?” Then attentively listen to what the individuals 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 view without judgement and criticism. You might say, for example, “It seems to me that the development progress has been slow. Several tasks aren’t finished, and some stories haven’t been started. Do you think that’s true?”

But leave it up to the team to decide what needs to be done, and do not force your perspective onto them. You might be wrong after all: The team might be doing a great job despite your concerns. If you are unsure if you should say something or not, talk to the Scrum Master who is responsible for helping the team practice self-management, as I discuss below.

Take Stock at the End of the Sprint

Once the new product increment is available, you know for sure how much the development team has achieved. Based on a live demo of the increment, you determine which product backlog items have been completed by using the definition of done, the quality criteria every product increment must fulfil. This allows you to understand if the sprint goal was met 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. Clearly state what was achieved and what was not. For instance, if the team only managed to complete half of the product backlog items they pulled into the sprint and missed the sprint goal by a mile, then don’t make out that the team’s performance was OK. It was not. The team simply underperformed. I’ve seen Scrum product owners who put up with an underachieving team partly because they hoped things would improve on their own and partly because they shied away from a difficult conversation. But chances are that nothing will change for the better if you don’t openly address the issue.

At the same token, empathise with the development team and speak with kindness. Don’t have a go at the members, and refrain from blaming and judging people. Treat the team as a valued partner and recognise the effort the group made. Additionally, put the performance issue into context: A newly formed team and a significantly changed one are likely to require a few sprints before the members can reliably meet the sprint goals. Similarly, a team dealing with significant technical challenges may struggle to get sprint planning right due to the uncertainty present.

To give helpful feedback and maximise the chances that your message is heard, you might say: “It’s great that you managed to deliver some of the product backlog items. Thank you for that. But I am disappointed that only half of the work is complete and that the sprint goal was clearly missed. I’d like to understand what went wrong, and how we can avoid a similar situation in the future.” If you are upset or angry, then take a few deep breaths and count to ten before you give feedback. If that’s not enough, take a short break and continue once you have calmed down. While it’s perfectly fine to have difficult emotions, acting them out is not OK. I once witnessed a sprint review meeting degenerate into a shouting match. This did not solve anything, of course. Instead, it made things worse, destroyed trust, and damaged relationships.

Use the Retrospective to Determine Improvements

Whenever you experience performance issues, use the sprint retrospective to identify and address their underlying causes. For example, you might find that some of the user stories that went into the sprint were too big or lacked acceptance criteria, that the team did not use the definition of done to identify the necessary tasks during sprint planning, that the software development environment was unstable, or that unresolved conflicts resurfaced and slowed down the team.

Do take part in the sprint retrospective. But don’t dominate the meeting and refrain from blaming and judging others. Instead, embrace a contribution mindset: Ask how you can help to avoid that the same problem will arise again. Don’t assume that a performance issue is necessarily the development team’s fault. Instead, cultivate an open mind and actively listen to the suggestions of the development team members. You might find, for example, that you did not involve the individuals enough in refining the product backlog. This might have led to big and unclear user stories, which made it hard for the team to meet the sprint goal. Or you might have 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 prepared to change the way you behave.

If a performance issue persists despite determining its causes and implementing improvement measures, then you might have to consider adjusting the team composition. For example, it may be beneficial to break up a team whose members are working on different, unrelated areas within the same product. It might also be necessary to ask a team member who continuously shows disruptive behaviour to leave the team. However, none of these changes should be forced onto the team. Instead, have an open, honest conversation in the retrospective and look for a solution that works for everyone. This creates transparency, gives people the opportunity to contribute, and reduces the risk that individuals end up frustrated and feeling treated unfairly.

Finally, let the Scrum Master facilitate the meeting and suggest helpful ways to unearth underlying causes and derive actionable improvement measures. If you don’t have a Scrum Master or agile coach, find an experienced, neutral facilitator who ensures that everyone is heard, and nobody dominates.

Let the Scrum Master Coach the Team

As much as you may want to help the development team, be mindful that you are responsible for managing the product, not for coaching the team. That’s the job of the Scrum Master or agile coach. If you don’t have a Scrum Master, or if the person is not adequately available or qualified, then don’t make the mistake to cover the individual’s work, certainly not on a continued basis. This would cause you to neglect some of your product management responsibilities—like reviewing and updating the product strategy and product roadmap—or sacrificing your health, neither of which is desirable.

Instead, recognise that the lack of a qualified, available Scrum Master needs to be addressed and engage with the decision-makers in the organisation to find a solution. I personally regard it as unfair to ask product people to act as the product owner if the Scrum Master role is not properly filled.