Format of Retrospective
In the previous version of Scrum guide, there were 3 questions to discuss in daily call. But it was removed as the developers can decide whatever structure they want.
Sameway I see for retrospective, it is given in guide as below,
The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
which also looks like a format or alteast used as a format in lot of tools for retrospective. Not a problem just my viewpoint.
Agreed, the new Scrum Guide has softened prescriptive language because over the past decade it had become more prescriptive.
There are other examples too: Product Backlog item attributes, shorter sections (i.e. Sprint cancellation).
I see where you're coming from, but I've never really viewed that sentence as a description of a format. I've tended to view it as an extension of the purpose of the Sprint Retrospective:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
Talking about things that didn't go well, what problems came up, and if and how the team solved those problems seems like a natural way to accomplish the purpose. However, talking about things that went well is also essential but may not be quite as obvious. When things happen that lead to success, I've found it helpful to talk about those and see if it is possible to repeat those things in the future or keep those things in mind when making decisions.
I see it as more of a reminder to also remember the good things. Personally, I like to end my retrospectives with the positive. I've found that leaving the discussion on a positive note helps the team feel better going into the next Sprint, especially after Sprints where things didn't go well or the goal wasn't met. A reminder to think about the things that went well is a good thing.
I'm amazed at how hard people try to find process or rules within the Scrum Guide. It is clearly stated that Scrum is a framework. And if you look at any of the dictionary sites on the web it is clear that a framework is a supporting structure. Much like the frame that supports a building. It shapes the building and can create separate rooms. However any of those rooms can be used for whatever the occupants of the building choose. Even rooms with plumbing can be used for things other than bathrooms or kitchens.
The word Retrospective is also pretty clear in all of the definitions in the web's dictionary sites. Some of them will say something similar to "given to the act of retrospect". But in the end, the word is about the act of reflecting on the past. Not reflecting on the bad things of the past or the good things of the past. Just on the past. Pair that with empiricism, which is the heart of all things agile, and it seems pretty obvious that the Retrospective is an opportunity to inspect the past and learn.
How a team chooses to accomplish that activity is entirely up to the team. There is no standard way. There is no prescribed way. There is just the guidance of why it is important. My experience shows that doing the same thing the same way becomes a routine and is not interesting. Sometimes that is unavoidable. But if possible, varying the way that things are done can make them more enjoyable and engaging.
Stop looking for "the right way" and start using the "the right way for right now".
it is given in guide as below,
The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
which also looks like a format or alteast used as a format in lot of tools for retrospective.
The Scrum Guide says, in the same paragraph, "Inspected elements often vary with the domain of work". Does it really look like a format is being offered?