I'm puzzled. Product development teams are frustrated by their ways of working. They have a dedicated time slot to discuss and improve things. Yet, it doesn't work. Most teams believe nothing will ever change. As part of product discovery for Codigy Retro, I interviewed 62 companies. I broke down my findings into categories, to see if it would be possible to to solve this. Systematically. Bad experience on the individual/team level: Broken trust. The team raises an issue. It gets lost or left unresolved. No one likes to work without results. If there is no feedback, people will rightly think that it is a pointless exercise.
Peer pressure. When feedback is shared in public, everyone pats each other on the shoulder. It's hard to be the grumpy one who points out something bad.
Poor memory. What did you have for breakfast 4 days ago? We ask people for feedback on the spot, after a hard working week. It's not that we don't have problems to discuss. It's just hard to recall them on the spot.
Lack of structure. Instead of fixing the trust, some facilitators replace problem-solving meeting flow with games and vague discussions. Everyone is engaged, but are there any outcomes? Interactions with Leadership level: Participants raise issues outside the team's scope. That's expected since their quality of life mostly depends on company policies and culture. Topic samples: "Shifting scope", "Lack of product vision", "HR Processes", "Access Policy", "Collaboration with other teams". If we don't address them, we return to the "Broken trust". Why is the high-level stuff usually left unresolved? Your suggestion is discarded as "individual opinion". The team champion gathers insights. Uses all the relationships within the company to share findings. Result? Frequently discarded as an "insignificant issue" or "your opinion”.
"Our tiny team can't change this". Individuals and teams avoid raising issues, thinking it only affects them and is not important enough to be escalated higher. The company is made up of tiny teams. Maybe this issue affects everyone - but we will never find out, because it's never discussed outside the team silo.
Fear of retaliation. Some relationships are not as rosy as we want them to be. Anonymity matters. Especially when rallying support for a controversial topic.
Dev talk vs Business talk. There is plenty of feedback going around in closed peer groups. Devs talk to devs. Leadership talks to leadership. Without a common language and effective communication channels, a meeting between two groups turns into a blaming session. Teams with high autonomy, seem to be happier and not affected by this as much. Maybe that's the long-term solution. How to get out of this situation? After discussing this with the Agile community on Reddit, it seems like teams in this situation have a few options: Continue the struggle. Leave things as they are. Not a happy choice.
Focus team attention on improving the 10% of experience in their control. Barely better. Like cleaning your desk when someone is chopping your arm off. Hard to focus on the small stuff, when your experience is harmed by something bigger.
Go and solve this individually. Build relationships in your organization. Back your argument with team data (anonymized). Try to convert your case into business language. This is by far the best choice. But unfortunately, this is frequently disregarded as "your opinion" because you came alone.
Wait for consultants or leadership to make structural improvements. This may improve things, but when? Take team experience into your own hands The key is to rally support and show that even a small issue can be significant. A different story if it bothers 15 teams or 50 developers. → Gather issues that bother the majority of the teams. Talk with other teams. Extract data summary from retrospectives with Ai, and use data analytics (E.g. Team Health Check trends). → Open a channel/inbox visible to leadership. Submit issues and get public upvotes from other teams. → Convert findings into business language. What are we losing? What could we get, and how? This kind of work would be done by consultants. The benefit of doing it internally, is you get incremental changes NOW. And feels good😎 I'm puzzled. Product development teams are frustrated by their ways of working. They have a dedicated time slot to discuss and improve things. Yet, it doesn't work. Most teams believe nothing will ever change. As part of product discovery for Codigy Retro, I interviewed 62 companies. I broke down my findings into categories, to see if it would be possible to to solve this. Systematically. Bad experience on the individual/team level: Bad experience on the individual/team level: Broken trust. The team raises an issue. It gets lost or left unresolved. No one likes to work without results. If there is no feedback, people will rightly think that it is a pointless exercise. Peer pressure. When feedback is shared in public, everyone pats each other on the shoulder. It's hard to be the grumpy one who points out something bad. Poor memory. What did you have for breakfast 4 days ago? We ask people for feedback on the spot, after a hard working week. It's not that we don't have problems to discuss. It's just hard to recall them on the spot. Lack of structure. Instead of fixing the trust, some facilitators replace problem-solving meeting flow with games and vague discussions. Everyone is engaged, but are there any outcomes? Broken trust. The team raises an issue. It gets lost or left unresolved. No one likes to work without results. If there is no feedback, people will rightly think that it is a pointless exercise. Broken trust. Peer pressure. When feedback is shared in public, everyone pats each other on the shoulder. It's hard to be the grumpy one who points out something bad. Peer pressure. Poor memory. What did you have for breakfast 4 days ago? We ask people for feedback on the spot, after a hard working week. It's not that we don't have problems to discuss. It's just hard to recall them on the spot. Poor memory. Lack of structure . Instead of fixing the trust, some facilitators replace problem-solving meeting flow with games and vague discussions. Everyone is engaged, but are there any outcomes? Lack of structure Interactions with Leadership level: Interactions with Leadership level: Participants raise issues outside the team's scope. That's expected since their quality of life mostly depends on company policies and culture. Topic samples: "Shifting scope", "Lack of product vision", "HR Processes", "Access Policy", "Collaboration with other teams". If we don't address them, we return to the "Broken trust". Why is the high-level stuff usually left unresolved? Your suggestion is discarded as "individual opinion". The team champion gathers insights. Uses all the relationships within the company to share findings. Result? Frequently discarded as an "insignificant issue" or "your opinion”. "Our tiny team can't change this". Individuals and teams avoid raising issues, thinking it only affects them and is not important enough to be escalated higher. The company is made up of tiny teams. Maybe this issue affects everyone - but we will never find out, because it's never discussed outside the team silo. Fear of retaliation. Some relationships are not as rosy as we want them to be. Anonymity matters. Especially when rallying support for a controversial topic. Dev talk vs Business talk. There is plenty of feedback going around in closed peer groups. Devs talk to devs. Leadership talks to leadership. Without a common language and effective communication channels, a meeting between two groups turns into a blaming session. Your suggestion is discarded as "individual opinion". The team champion gathers insights. Uses all the relationships within the company to share findings. Result? Frequently discarded as an "insignificant issue" or "your opinion”. Your suggestion is discarded as "individual opinion". "Our tiny team can't change this". Individuals and teams avoid raising issues, thinking it only affects them and is not important enough to be escalated higher. The company is made up of tiny teams. Maybe this issue affects everyone - but we will never find out, because it's never discussed outside the team silo. "Our tiny team can't change this". Fear of retaliation. Some relationships are not as rosy as we want them to be. Anonymity matters. Especially when rallying support for a controversial topic. Fear of retaliation. Dev talk vs Business talk. There is plenty of feedback going around in closed peer groups. Devs talk to devs. Leadership talks to leadership. Without a common language and effective communication channels, a meeting between two groups turns into a blaming session. Dev talk vs Business talk. Teams with high autonomy, seem to be happier and not affected by this as much. Maybe that's the long-term solution. How to get out of this situation? How to get out of this situation? After discussing this with the Agile community on Reddit , it seems like teams in this situation have a few options: Agile community on Reddit Reddit Continue the struggle. Leave things as they are. Not a happy choice. Focus team attention on improving the 10% of experience in their control. Barely better. Like cleaning your desk when someone is chopping your arm off. Hard to focus on the small stuff, when your experience is harmed by something bigger. Go and solve this individually. Build relationships in your organization. Back your argument with team data (anonymized). Try to convert your case into business language. This is by far the best choice. But unfortunately, this is frequently disregarded as "your opinion" because you came alone. Wait for consultants or leadership to make structural improvements. This may improve things, but when? Continue the struggle. Leave things as they are. Not a happy choice. Continue the struggle. Focus team attention on improving the 10% of experience in their control. Barely better. Like cleaning your desk when someone is chopping your arm off. Hard to focus on the small stuff, when your experience is harmed by something bigger. Focus team attention on improving the 10% of experience in their control. Go and solve this individually. Build relationships in your organization. Back your argument with team data (anonymized). Try to convert your case into business language. This is by far the best choice. But unfortunately, this is frequently disregarded as "your opinion" because you came alone. Go and solve this individually. Wait for consultants or leadership to make structural improvements. This may improve things, but when? Wait for consultants or leadership to make structural improvements. Take team experience into your own hands Take team experience into your own hands The key is to rally support and show that even a small issue can be significant. A different story if it bothers 15 teams or 50 developers. → Gather issues that bother the majority of the teams. Talk with other teams. Extract data summary from retrospectives with Ai, and use data analytics (E.g. Team Health Check trends). Gather issues that bother the majority of the teams. → Open a channel/inbox visible to leadership. Submit issues and get public upvotes from other teams. Open a channel/inbox visible to leadership. → Convert findings into business language. What are we losing? What could we get, and how? Convert findings into business language. This kind of work would be done by consultants. The benefit of doing it internally, is you get incremental changes NOW. And feels good😎

This story contains new, firsthand information uncovered by the writer.

This post provides insights into new product. 

My Teams Hates Retros. What Should I Do?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Smashing Retrospective!

QA Isn’t Just About Fixing Bugs

The Noonification: The Bitcoin Mining Writing Contest by GoMining (1/14/2024)

10 Things You Can Do Better While Working With Programmers

10 Key Aspects To Consider When Managing Tech Projects

A Smashing Retrospective!

QA Isn’t Just About Fixing Bugs

The Noonification: The Bitcoin Mining Writing Contest by GoMining (1/14/2024)

10 Things You Can Do Better While Working With Programmers

10 Key Aspects To Consider When Managing Tech Projects

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps