Scrum Guide Update

A few days back there was a new update to the Scrum Guide – the definition of Scrum. So what’s new? Not much, which is a good think. Most of the changes were minor, correcting, clarifying and updating the text so it’s clearer. Few interesting updates:

The trend of using Agile and Scrum out of IT was addressed explicitly:

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”

Nothing new, for us, but it can make a difference to the people new to Scrum.

I specifically like the update in the Daily Scrum section where the three questions were only made as one option. Finally, right.

“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.”

So there is a chance people stop using it as individual status meeting and use it to inspect and adapt their plan ow they are going to achieve the Sprint Goal.

The only change I don’t understand as it is to my opinion going against the philosophy of Scrum as a framework, not a process is the Sprint Backlog section:

“To ensure continuous improvement, it (Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.”

So here we are, pushing one practice which may be good for the teams who are at the beginning of their Agile journey and don’t improve as part of their DNA to everyone. I can imagine many other ways how to improve then making it part of Sprint Backlog and soften the line between delivering value and “other important tasks which need to be done”.

I like Scrum as it is not much prescriptive and I hope such weird changes will not increase as they will eventually be the end of Scrum as a flexible framework…

Make product as wide as possible

Some time ago, when I first heard the definition of LeSS (Large-Scale Scrum) product, I found it a bit unrealistic. Large-Scale Scrum is one of the Agile Scaling methods and I happen to like it as it’s very close to what I had experienced to be successful in various environments before. But the definition of the product is quite wide. Specifically – the product shall be as wide as possible, but still practical. If the customer feels it’s the same product or if it’s similar from technical perspective, it is the same product. When you start to apply this rule, in general it means that most of the companies have one product only.

Let me give you a few examples… Amazon and all its services shall be one product because that is how customers see it, the service company delivering internet solutions and mobile apps for variety of the customers is one product despite of the diversity of the customers and technology, the maintenance and the new development is one product as it is same from the technical perspective. Your projects are just Epics in your Product Backlog. When you think about it for a while it makes sense, as you need consistency in your delivered functionalities, flexibility to be business driven and ability to prioritize your business only by business value not by technical skills or domains. This is the real crossfunctionality we aim for. It’s not that difficult despite of the complexity of your product. The people who create our software are usually having university degree which shows they can learn. They are smart and creative software engineers. They can make it. If you do it this way it makes everything so much easier as dependencies at code level are much simpler than dependencies at business level.