Closed ThomasOwens closed 4 years ago
Jon1776
commented
4 years ago @ThomasOwens this is an interesting point. I'm curious, what are the best practices you have seen? You mention the only good scaled-retrospectives have been cross-team on a common product. Have you seen a single team, with a complete product that tried to do this @ scale and failed or have you just not seen a single team try that in a scaled environment?
ThomasOwens
commented
4 years ago @JonHaase I don't fully understand your question.
A single team working on one product is not scaled, at least by the definitions of LeSS or Nexus or my understanding of Scrum@Scale. The frameworks for scaling Scrum support multiple teams working on a single product. Frameworks such as S@S and SAFe take it more levels up into what I would consider a portfolio of products and those interactions as well. I don't know how a single team with one product would apply anything at scale.
As far as single teams in a scaled environment, I have seen teams hold internal "reviews", but as preparatory events leading up to the Sprint Review, which includes all teams. These events are a chance for the team to organize what and how they wish to execute the review. At most, some participants are external to the team but internal to the development organization at these events. I don't think that they meet the criteria for a Sprint Review from the Scrum Guide, however.
Jon1776
commented
4 years ago @ThomasOwens thank you for clarifying. I think I understand the nature of your comments. So, in your experience, how do teams handle reviews at the team level?
I understand that at a higher level, cross-teams do combined reviews to demonstrate the entire product.
ThomasOwens
commented
4 years ago @JonHaase In my experience, teams don't hold reviews at the team level. I have yet to see a team find value in holding such an event in a way that is value-adding in a scaled environment. Instead, teams will set some time aside to prepare for the cross-team Sprint Review, without including stakeholders from outside the team. This is consistent with practices from both LeSS and Nexus, which opt to totally remove the team level review in favor of a cross-team, product level event.
I'm looking for a few things:
jeffsutherland
commented
4 years ago The current Scrum@Scale Guide is a complete rewrite based on hundreds of comments.
We found that constant small updates on Github were useful in the beginning but the document was becoming less readable with constant small changes.
We have move to a form for suggested changes. We will do an update to the Guide incorporate proposed changes on a regular cadence, faster than the Scrum Guide but no less than six months.
Please use this form for proposed changes: https://docs.google.com/forms/d/e/1FAIpQLSfSL4FEjF4U8ATepzkkvQkC2rO_WnOThVauXdV6jvK94BnrMQ/viewform
Regards, Jeff
-- Jeff Sutherland, Ph.D. Founder and Chairman, Scrum, Inc. www.scruminc.com One Broadway, 14th Floor Cambridge, MA 02142 P +1 (617) 225-4324
Scrum@Scale Guide HBR papers: Embracing Agile Agile at Scale Scrum: The Art of Doing Twice the Work in Half the Time Courses: scruminc.com/scrum-courses-and-training/ Twitter: jeffsutherland jeff.sutherland@scruminc.com On Apr 9, 2019, 7:53 AM -0400, Thomas Owens notifications@github.com, wrote:
This may be related to #57 but that issue doesn't call out the Sprint Review. It does call out the backlog refinement and retrospective. Based on the wording in the Scrum@Scale Guide, it seems like the core Scrum events simply live at the Scrum Team level. However, having worked in organizations at scale, with multiple teams supporting a single product, I have yet to see this be a value adding event when the Sprint Review is scoped to a single team. I've had success with the Sprint Review being a cross-team event that includes all of the Scrum Teams that are supporting a single product. This makes sense since the increment being delivered and reviewed by stakeholders is a single product supported by a single Product Backlog. I'd also note that the other scaled frameworks that specify events (I'm familiar with LeSS, Nexus, and SAFe) have their form of the Sprint Review at a cross-team level. I'd be curious to see if the Scrum@Scale Guide follows along or if it introduces a new pattern for scaling the Sprint Review event. If the Sprint Review is held at a team level without a cross-team event, I'm curious as to why teams using Scrum@Scale are not having product architecture issues if teams aren't being exposed to each others work via the Sprint Review. If it's held at multiple levels, I'm curious as to how the investment in time from the teams for multiple review events is justified and managed by the organization. Regardless, I'd like to see some discussion of the Sprint Review event in the Scrum@Scale Guide, minimally with advice on how to make it effective for a scaled environment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
ThomasOwens
commented
4 years ago Thank you, @jeffsutherland - I've submitted feedback there and I'm closing this issue.
This may be related to #57 but that issue doesn't call out the Sprint Review. It does call out the backlog refinement and retrospective.
Based on the wording in the Scrum@Scale Guide, it seems like the core Scrum events simply live at the Scrum Team level. However, having worked in organizations at scale, with multiple teams supporting a single product, I have yet to see this be a value adding event when the Sprint Review is scoped to a single team. I've had success with the Sprint Review being a cross-team event that includes all of the Scrum Teams that are supporting a single product. This makes sense since the increment being delivered and reviewed by stakeholders is a single product supported by a single Product Backlog. I'd also note that the other scaled frameworks that specify events (I'm familiar with LeSS, Nexus, and SAFe) have their form of the Sprint Review at a cross-team level.
I'd be curious to see if the Scrum@Scale Guide follows along or if it introduces a new pattern for scaling the Sprint Review event. If the Sprint Review is held at a team level without a cross-team event, I'm curious as to why teams using Scrum@Scale are not having product architecture issues if teams aren't being exposed to each others work via the Sprint Review. If it's held at multiple levels, I'm curious as to how the investment in time from the teams for multiple review events is justified and managed by the organization.
Regardless, I'd like to see some discussion of the Sprint Review event in the Scrum@Scale Guide, minimally with advice on how to make it effective for a scaled environment.