LeSS and the Scrum Guide

I took a quick look, but couldn't find a rationale. The discrepancies are summarized at the bottom but without explanation. Do you know if the reasoning behind this has been expanded upon anywhere?

@Piotr - Thanks for sharing this.

Would like to know more on why they felt the changes were necessary. Would like to hear from the experts here.

What I liked 

1. Mentioning backlog refinement along with the Scrum events. It is something which is followed at most places.

What I think could be problematic:

1. Definition of done as an agreement between PO and team - This seems very short sighted and skewed. This kind of shifts the focus away from quality which was the main thing as mentioned in the 2020 guide. The irony is that DoD is mentioned as an agreement between PO and the team and neither should certify the product/increment. Also the definition of done is something that keeps evolving and inputs from customers who use the product should also be counted. 
2. Roles instead of Accountability - This is not mentioned in the difference section but seems to be the case. The 2020 guide uses accountabilities to reinforce the fact that there is no hierarchy within the Scrum team.
3. Team instead of developers: I liked the Scrum team which constituted the SM, PO and developers and each plays a part in value delivery. Using teams instead of developers kind of isolates the 3 accountabilities. 
4. Removed the language of commitment to artifacts: One of the scrum values is commitment and I don't see a reason to disassociate it from artifacts.

I don't understand the rationale for publishing a new "Scrum Guide" that results in something that isn't Scrum. The LeSS creators already say that LeSS is not Scrum, but it is "strongly influenced by Scrum". Since it isn't Scrum, I'm not sure why they would need a Scrum Guide that also isn't Scrum.

The changes are a bit of a collection of different things.

Some of the changes are around removing some Scrum terminology, like "Scrum Team". However, a number of Scrum terms remain, like "Sprint" (and "Sprint Planning" and "Sprint Retrospective"). Again, I don't see the value in this type of change, especially if you're going to call it a Scrum Guide.

Other changes soften commitments. This seems like another unnecessary change. Not only is commitment a Scrum value, but commitments are a central component of how people work together. I'm not sure why you would want to remove or soften language around commitments that the team makes to stakeholders.

Other changes appear to be about scaling. The best example is making Product Backlog Refinement an event. You also see this in the Nexus framework. When you have multiple teams, having more coordination around refinement is necessary, so elevating it to a more formal, structured event makes sense.

Honestly, the creators of LeSS publishing a Scrum Guide seems more confusing than anything else. I've successfully used LeSS as a scaling framework, and it's my top choice for organizations to look at when they have a solid foundation in Scrum and are growing to beyond one or two Scrum Teams. However, I don't see the purpose or value in calling something a Scrum Guide that ends up with no relation to Scrum and little relation to LeSS.

From LeSS…

Be dubious of messages such as “Scrum 2.0,” “Scrum++,” “Scrum#,”, “UnifiedScrum,” “OpenScrum,” or “new and improved Scrum that should replace regular Scrum.” They may miss the point of empirical process control and the implications of Scrum.

https://less.works/less/principles/large_scale_scrum_is_scrum 

Perhaps we should also be dubious of this offshoot of Scrum as well.

Some of the more concerning things for me…

A team divided. This structure has the PO and SM outside of “The Team”. Why the division? I also don’t understand the rational behind reverting back to roles over accountabilities. This is quite limiting. 

DoD is decoupled from the Increment, and downgraded to acceptance criteria. Making it an agreement between PO and “The Team” also reinforces division within the team. More like a contract negotiation. 

On the fence about Refinement as an event. Seems authors are too…

Product Backlog Refinement is done as either an ongoing activity, part of Sprint Planning, or as a separate event during the Sprint.

I feel like the new definition of PB Refinement is a bit off as well. It seems to be more about pre-planning and estimation and less about the act of breaking down and further defining into smaller more precise items. 

I do like the removal of “Topic n” in Sprint Planning. Why, What and How is sufficient. Apart from that, I remain dubious about this LeSS guide.

Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

That was in the opening statement of the LeSS Scrum Guide.  But then they go on to do exactly what is said could potentially render it useless.  My PTSD from years of proof reading 100 page requirements documents is flaring up already.

Why this update to the Guide? The latest versions of Scrum and LeSS have evolved in parallel which has led to the assumed Scrum in Large-Scale Scrum being a combination of different Scrum versions, creating inconsistency, and potentially a more complicated and less adaptive organization in a multi-team situation.

This version of the Guide describes Scrum as assumed in LeSS.

They state this is only for use when LeSS is being used.  So, it would be great if they would rename and refer to it as LeSS Scrum much like SAFe calls theirs SAFe Scrum.

I am not a fan of this guide reading so much like the official Scrum Guide.  I wonder if they were given permission to copy/paste so much of the text from previous/current guides?  

I can live with the "Team" change because having it read as "Developers" in the official Scrum Guide has issues as well.  With "Team" it is easier to include people that don't write application code (i.e. QA, UX Designers, DevOps Engineers, etc) and it can be easier to understand when implementing in a non software development organization. 

Events bother me.  Events usually mean that there is a agenda created and published ahead of time with topics decided prior to the event.  That leads to people looking at the published agenda, deciding that they have nothing to contribute and finding ways to "miss" the event.  

I am not a fan of Refinement being listed as an event.  This just encourages people to schedule meetings of for the sole purpose.  I have found that the best refinement comes from when people need a break from the current Sprint work and get together to discuss something else.  I have also had some teams that prefer using the comments section of the tool to asynchronously refine something. It keeps a history of the discussion and allows people to do it on their schedule. 

I like that in the official Scrum Guide the Definition of Done is defined to include any organizational requirements and that, if one exists, the organizational Definition of Done is the higher order definition.  Each team can define additional criteria as long as it does not lower the standards of the organizational one.  This has helped many of my teams to establish some organizational standards that elevated the quality, consistency  and manageability of code across teams.  It also helped other departments such as Support, Operations, Marketing to understand what it meant for something to be "done".  The LeSS Scrum Guide removes that cross team benefit which is strange to me since it is for a scaling framework. <shrug>

And just when I have started to make progress with people understanding that you do not have to have a job title of Scrum Master to fulfill those responsibilities and accountabilities, they go and revert back to roles.  <shake my head> 

I find this post/thread troublesome, because there is no "New version of Scrum Guide (2024)".

This post will confuse everyone forever.

I agree Mario and have changed the subject of the thread to ensure it doesn't cause confusion.  

Note:  There is NOT a new version of the Scrum Guide and the Scrum Guide is copyright and owned by Ken and Jeff.