If you're interested in a more specific way to run a retrospective, check out the article on my blog where I provide a specific agenda that I use with my teams: www.notonlycode.org/effective-retrospective/
At the outset, let me first thank you for publishing such great content on your channel which I am sure many 1st time EMs transitioning from senior IC role (like me) must be finding extremely useful. About this particular video - I found the content a bit in contrast to how Scrum alliance (and a lot of other resources) defines the concept of Retrospectives, mainly on the participation of EM in Retrospectives. Among various reasons on why EMs should not participate in retros, one that comes out rather strongly is - there shouldn't be a heirarchy in retrospective and team members should feel psychologically safe when participating in Retrospectives. Since the concept of Retrospectives is a 'Scrum way-of-working', I let my scrum-masters run the show and I look at the items (post-facto) and resolve/work on them wherever possible. Looking forward to hear your thoughts on participation of EMs in Retrospectives 🙂
Hey, thanks for the comment, this is a really good question! Overall I'm not a fan of Scrum and I don't use it in my daily work, so I don't look at Scrum rules when I design our working process with my teams. I don't have a Scrum Master in my team, instead I share responsibilities of running team with Product Manager (and Tech Lead in some cases). In this setup, attending the retrospective is a must for me, because I run the meeting. Scrum was created back in the 1990s, when the Engineering Manager role in the current form didn't exist, so it's hard to fit it into the framework. But if I tried to use it and decide about my participation in Retrospective, I would consider a few things: * if you run a single team and participate in day to day work (not necessarily coding, but reviewing code, supporting developers in their tasks, etc.) then you are part of the team and you should join the the regular meetings * if you run multiple teams then you are a bit more outside and in that setup it makes sense that you don't participate in every meeting but maybe occasionally attend them * think about what kind of value you can provide by participating vs not participating in the retrospective - for example, by looking at the retro items after the meeting, you lack the context, you can't ask questions to better understand it; in my case a lot of problems that are reported by the team can't be solved within the team and require talking to people across departments - in such case I can solve these issues easier than developers The argument of psychological safety and hierarchy is interesting here. In terms of hierarchy - Scrum says that there are no hierarchies in the team, which means the manager can't be part of the Scrum team. That also means as EM you should not participate in the planning and daily Scrum, which essentially reduces the role of EM back to where it was in the 90s, where managers were accountable for delivery and people management, but they were not technical and didn't participate in the daily work. Also, whenever I hear the "no hierarchy" rule, I keep thinking that it's a lie - the hierarchy is there, it's just not explicit. A team veteran's opinion will be valued more than a newcomer's one - that's a hierarchy, even though on paper they're equal. Regarding psychological safety - I consider creating a safe and healthy environment part of my job as EM, and if my presence in the meeting makes people feel unsafe and makes them self-censor themselves, then I failed to create a safe working environment and should work on that.
Thank you so much for taking time to reply in detail. Much appreciated! I re-read my comment and it felt like I was being an advocate of sticking to how Scrum alliance defines certain ceremonies be held; actually I wasn't, in case you felt it too. 😀 I am with you on the points you made around when it is acceptable/required for an EM to be part of Retrospectives and when it isn't. 👍 Now this is rather interesting where we are consciously comfortable in not strictly sticking to the "mainstream? scrum way", and hence the methods/ways of doing certain things within an engineering team becomes very subjective in context to a particular team. I wonder if SW industry in general is moving towards the same understanding, otherwise it would be quite a discussion to explain to someone - why we as a team don't follow certain scrum practices as they are meant to be followed. 🙂
If you're interested in a more specific way to run a retrospective, check out the article on my blog where I provide a specific agenda that I use with my teams: www.notonlycode.org/effective-retrospective/
At the outset, let me first thank you for publishing such great content on your channel which I am sure many 1st time EMs transitioning from senior IC role (like me) must be finding extremely useful.
About this particular video - I found the content a bit in contrast to how Scrum alliance (and a lot of other resources) defines the concept of Retrospectives, mainly on the participation of EM in Retrospectives.
Among various reasons on why EMs should not participate in retros, one that comes out rather strongly is - there shouldn't be a heirarchy in retrospective and team members should feel psychologically safe when participating in Retrospectives.
Since the concept of Retrospectives is a 'Scrum way-of-working', I let my scrum-masters run the show and I look at the items (post-facto) and resolve/work on them wherever possible.
Looking forward to hear your thoughts on participation of EMs in Retrospectives 🙂
Hey, thanks for the comment, this is a really good question!
Overall I'm not a fan of Scrum and I don't use it in my daily work, so I don't look at Scrum rules when I design our working process with my teams. I don't have a Scrum Master in my team, instead I share responsibilities of running team with Product Manager (and Tech Lead in some cases). In this setup, attending the retrospective is a must for me, because I run the meeting.
Scrum was created back in the 1990s, when the Engineering Manager role in the current form didn't exist, so it's hard to fit it into the framework. But if I tried to use it and decide about my participation in Retrospective, I would consider a few things:
* if you run a single team and participate in day to day work (not necessarily coding, but reviewing code, supporting developers in their tasks, etc.) then you are part of the team and you should join the the regular meetings
* if you run multiple teams then you are a bit more outside and in that setup it makes sense that you don't participate in every meeting but maybe occasionally attend them
* think about what kind of value you can provide by participating vs not participating in the retrospective - for example, by looking at the retro items after the meeting, you lack the context, you can't ask questions to better understand it; in my case a lot of problems that are reported by the team can't be solved within the team and require talking to people across departments - in such case I can solve these issues easier than developers
The argument of psychological safety and hierarchy is interesting here. In terms of hierarchy - Scrum says that there are no hierarchies in the team, which means the manager can't be part of the Scrum team. That also means as EM you should not participate in the planning and daily Scrum, which essentially reduces the role of EM back to where it was in the 90s, where managers were accountable for delivery and people management, but they were not technical and didn't participate in the daily work. Also, whenever I hear the "no hierarchy" rule, I keep thinking that it's a lie - the hierarchy is there, it's just not explicit. A team veteran's opinion will be valued more than a newcomer's one - that's a hierarchy, even though on paper they're equal.
Regarding psychological safety - I consider creating a safe and healthy environment part of my job as EM, and if my presence in the meeting makes people feel unsafe and makes them self-censor themselves, then I failed to create a safe working environment and should work on that.
Thank you so much for taking time to reply in detail. Much appreciated!
I re-read my comment and it felt like I was being an advocate of sticking to how Scrum alliance defines certain ceremonies be held; actually I wasn't, in case you felt it too. 😀
I am with you on the points you made around when it is acceptable/required for an EM to be part of Retrospectives and when it isn't. 👍
Now this is rather interesting where we are consciously comfortable in not strictly sticking to the "mainstream? scrum way", and hence the methods/ways of doing certain things within an engineering team becomes very subjective in context to a particular team. I wonder if SW industry in general is moving towards the same understanding, otherwise it would be quite a discussion to explain to someone - why we as a team don't follow certain scrum practices as they are meant to be followed. 🙂
Fantastic video. I learned quite a bit.
Thanks for sharing!
Glad it was helpful!