Simple question
Should the focus of a retrospective only be internal to the team?
1
-
Yes. Only the team should be present. No You can address issues that are external to the team. Let's say the third party graphics designer is always late with his material. This does impact the ability of the team to deliver done functionality. As such it is relevant and a restrospective is a good opportunity to discuss options to correct or mitigate the problem. It can also be helpful (in more mature teams) to deliberately focus a retrospective on a specific topic to uncover issues that were previously withheld from discussion.– KempethNov 2, 2017 at 13:04
Add a comment
|
6 Answers
You should constrain your retrospective if you need to limit the lessons to be learned.
answered Oct 30, 2017 at 18:33
-
Sounds like a really bad idea when you put it that way. But I like you point of view Oct 31, 2017 at 5:51
-
@Breezecom, wrote it this way because, arguably, it is generally a bad idea to constrain a lessons learned effort; however, in some cases, it could be warranted and beneficial. For example, limiting your focus can mean a deeper dive into your focus area versus a shallow dive across a broader view. So in some cases, you could justify this as long as you understand the risk of missing valuable input. Oct 31, 2017 at 12:29
-
I believe that's also important to mention that these lessons should be looking internally to the team and focused on items that can be actually addressed by the team. If you keep the meeting internally pointing fingers externally, then it's not a retrospective, it's just a place to cry out loud.– Tiago Cardoso ♦Nov 14, 2017 at 11:04
A retrospective is a chance for the team to review and reflect on their way of working - the things that went well, the things that didn't go well, and potential improvements. The Principles Behind the Agile Manifesto says that teams reflect on "how to become more effective" and then "tune and adjust its behavior accordingly" "at regular intervals". In Scrum, this is embodied in the Sprint Retrospective and is held by the Scrum Team (the Development Team, the Scrum Master, and the Product Owner).
It is preferable that the team participates without too much outside influence. The team should have a good deal of trust and respect, and keeping the event to the team encourages openness and more free discussion. However, there may be instances where it's beneficial to bring in people from outside the team. However, this should generally be done with the team's consent beforehand.
The four main components are people, process, tools, and relationships. These aren't restricted to things that are internal to the team - if the team had big successes or had to overcome problems with working with people outside the team, that should come up at a retrospective. However, not every problem is solvable by the team - some are broader, strategic or organizational problems. The team can identify these as problems, work on mitigation strategies, but should generally escalate these to be solved at a higher level.
answered Oct 30, 2017 at 18:31
The purpose of the retrospective is for teams to improve. If there are external issues which hinder the team then I prefer that they are discussed in the retrospective. Even if they need to involve people outside the team to address them. Such issues probably won't go away unless handled, attention is needed.
Principles behind the Manifesto for Agile Software Development
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The participants in the Sprint Retrospective event is at a minimum the Scrum Team (Product Owner, Development Team, and Scrum Master). There is nothing in the rules of the framework the prohibits additional participants. However, most interpret the section as limiting the event to the Scrum Team members only.
ADDITIONALLY
Any issues that affect the ability of the team to efficiently and effectively deliver quality, working software should be open for discussion. For example, if there is a business silo or resource dependency impediment then it should be expressed. Of course these issues should be raised at any time. The Sprint Retrospective is simply an official event to inspect and adapt. If a team desired to hold a separate meeting to address these issues, that is also their prerogative. The ability to make these decisions come from understanding the agile philosophy and desire for self-organization.
-
Thanks for this, I did check the above sites before posting. However my question was more should the team highlight issues external to them or only focus on them selves? Should issues with other departments and teams slowing or blocking the scrum team be raised in a different forum? Oct 31, 2017 at 5:56
-
@Breezecom Hopefully the addition provides the more direct answer you were seeking. Oct 31, 2017 at 12:00
I usually prefer to keep the retrospective to the project team as we tend to get more focused and honest discussion, without worrying about what you say or how it's presented. However, if there is an issue involving another department, or something they can add to the discussion then we bring them in on an ad-hoc basis.
Usually if we do add anyone else it's someone from our Customer Support team, as they have great 'on-the-ground' feedback.
-
Hey I agree, my question was about the "focus" of the session. I always keep the retro a closed session. Nov 16, 2017 at 21:42
The Agile retrospective can be called as a "lessons learned" meeting. The team reflects on how was everything in the previous sprint and then discuss the changes they want to make in the next iteration. The attendees should be limited to the project development team and the ScrumMaster. The ScrumMaster generally act as moderator of this meeting and should listen to his team member carefully. The PO and other managers should only join the meeting if invited by the team to discuss specific issues.
The team members can discuss the process which's been followed and give any suggestions for improvement. The team members discuss any idea that could improve their productivity. The ScrumMaster prioritizes actions and lessons learned based on team direction. The retrospective helps build the team's sense of ownership and its self-management.
