Growing Our Team with Retrospectives | Hacker News Reader

Growing Our Team with Retrospectives

blog.plaid.com

86 pointsbjacokes22 comments

The effectiveness of a retro rests upon the empowerment of the entire team. If the team isn't empowered to own their own success/failure, then there is no point in doing a retro.

From my experience, business units need just as much coaching on agility as development teams. It's hard to change culture, but it's essential the BU gets out of the way (let the team own how they plan on delivering a solution) and facilitates empowerment of change for the team to thrive.

Again, from experience, the main driver of apprehension is middle management feeling the squeeze from making everything transparent. They're use to being the routers (worst case, bottlenecks) of information and work, when in reality their role should be to empower the team with the resources they need to own their work. The shift in focus from delegation to facilitation is essential to the whole process, making retros more effective once realized. Empowerment builds in psychological safety for the team to sink their teeth into their own issues and solve those issues themselves.

Another main driver of apprehension is power within the team. If there are only 1 or 2 main members of the team that dictate the pace of the conversation, that crowds out the rest of the team from buying in and/or providing their insights. The entire team needs to be empowered to own their success, not just a handful of members.

> If there are only 1 or 2 main members of the team that dictate the pace of the conversation, that crowds out the rest of the team from buying in and/or providing their insights. The entire team needs to be empowered to own their success, not just a handful of members.

I notice this all the time, some folks might be really outgoing, and love to talk and drive conversations, while others are content with staying silent. But all opinions on the team are valuable.

I've experienced this first hand where I've worked on great teams, and we all got involved in discussions about equally. I think it's easy to get someone quiet to speak up (if they have thoughts about the topic at hand they aren't saying), the more difficult challenge, at least for me, is trying to quiet down the team members that go on tangents.

A good practice is to ask people to write as opposed to speak. You can give some space for everyone to put their thoughts on post-it notes before the conversation starts (or to put things in a doc before the retro meeting).

There are so many dimensions: shy v. not, or introverted v. extroverted, or active v. passive thinker, or oral v. written communication, etc. Ideally you shape practices that can account for this diversity of thought.

And +1 to setting expectations so that people who are very vocal don't take up all of the space.

Retrospectives are great if they actually lead to change. Unfortunately that’s often not the case. The same issues keep coming up repeatedly and soon the retrospective is just another chore.

I would love to see retrospectives where managers one or two levels up attend (usually it’s just the devs), listen to issues and address things that need support from a larger point of view. Agile theoretically should transform whole organizations that way.

I've worked at a place where all that IS often the case: retrospectives surface issues, those issues typically get resolved, managers attend, etc.

Even at one point when we felt like retrospectives were getting less effective we actually retro'd that and made a bunch of changes to the process (namely, checking in a set number of weeks after each retro to follow-up and see whether action items were indeed followed through on)

+1 to meta-retros (or retros on retros). Once you have a group with a ton of trust, you can retro all of the things.

(and hi Ozzie)

In my experience retrospectives are just lip service. Managers who attend use them as an opportunity to make excuses for the company and focus on what’s wrong with you, the employee, and what you can do better. People eventually realize that the smart thing to do is to stop making yourself an easy target for down-sizing by not speaking up. Then when someone has a complaint about the development process a manager can say, “If you had such a problem with it you should have mentioned it in the retro.”

Employers who want to hear from you will foster an environment that is open to discussion and even polite dissent. When an employer formalizes that mentality and slaps a label on it you can be sure that it’s a managerial con.

One point of the post is that if you do constant retros (say every 2 weeks), within teams with the engineering manager, you can help foster an "an environment that is open to discussion and even polite dissent" (as you put it).

As a VP Eng, I've found that it can definitely hurt for upper management to get involved in retros. I try really hard to create bottom-up empowerment where individuals and teams can solve problems and improve their processes independently. That kind of ownership is really powerful. Retros really help with that. Plus, from my perspective, I can just read retro-notes to find common threads across teams that may require my help to improve or fix (e.g., if we're consistently underinvesting on testing or if aren't providing enough avenues for career growth or ...).

I obviously can't speak to your experiences, but what you're describing sounds really dark: management "conning" management. I hope you've been able to get away from such places!

This is literally what I did as a VP Eng. I let the teams drive the improvements and kept my role to a) ask questions to help the team identify areas of improvement and b) help implement the changes when necessary. The result was that I had many teams with fairly different processes, definitions of ready & done, etc. but that was the whole point. It's all about what helps the team work best, and ownership of the process along with the result goes a long way.

When there are actual management problems happening, probably it's also not so comfortable for the manager to get criticised as a single person, no matter how polite it is. So jointly discussing topics should probably happen regularly.

I make great efforts to make sure we follow through on action items on my team, and strong top level support has indeed transformed our entire organization and consistently makes Plaid a better place to work. Retrospectives without follow through can become very frustrating that's why action items and owners are a key component.

“why action items and owners are a key component.”

We have that too. The only thing that’s missing is follow through :)

Maybe you can discuss follow through in your retros and come up with a plan to increase that sense of ownership from the bottom up :) I know depending on your org that isn't always possible, but it's an idea!

The whole idea of retros rests on the people in the meeting having the power to change the things under discussion.

If that's not the case, it's not really a retro.

I've been in retrospectives with middling managers and diddling directors, it's all part of the agile theatre being put on by erstwhile high schoolers

The present team I'm on is really good at being open and honest during our retros but we can never seem to do anything with the action items for improvement that comes out of them. We've tried everything from mentioning it explicitly in our daily stand-up or making it a zero-point story in our current sprint but nothing seems to work.

What do you mean by "nothing seems to work"?

Are the action items achievable and will completing them actually improve the situation?

Are the action items assigned to an individual? Is someone responsible for seeing them through?

Retros are great when there's follow up! We always make sure to document things that come from the session.

Do you know those screenshots from what product are from? Look a bit like.. Confluence pages?

I believe that's a Confluence page. Confluence already has a "Retrospective" template for this occasion.

Reply on news.ycombinator.com