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.
🎧 You can listen to this article here: https://www.romanpichler.com/podcast/dealing-with-an-underperforming-development-team/
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 meetingdegenerate into a shouting match. This did not solve anything, of course. Instead, it made things worse, destroyed trust, and damaged relationships.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/dealing-with-performance-issues-on-the-development-team/
Learn More
You can learn more about dealing with poor team performance by attending my product leadership workshop, which is available online, and by reading my book How to Lead in Product Management.
Source: https://www.romanpichler.com/blog/dealing-with-performance-issues-on-the-development-team/
