I’ve seen teams get way too caught up in the mechanics of a methodology or framework, to the point of forgetting why it was introduced in the first place.  You’ve got to deliver – otherwise the rest becomes academic.

One of the projects that I worked on had about 25 people in three teams. Two thirds of them had never had an introduction to agile. They had been been assigned or joined the project and were told: we’re agile, this is how they work. So they were going through the motions (or ceremonies to be more exact) of Scrum – but they had no idea why. They weren’t using estimates or sprint/release burndowns, it didn’t matter if stories didn’t fit in a sprint, retros were done as a group rather than per team etc. So, the first thing to do was to start with some training about the agile mindset, scrum by the book (i.e. ideal Scrum Guide scrum) and then the compromises of doing Scrum in real world organisations.

There was a fair amount of skepticism and resistance – after all, Scrum is just quick waterfall and why split stories up when it needs to be done anyway? Gradually they were won over to splitting and estimating stories, clearing the board, proud of their burndown and planning releases in a realistic way. I was quite proud when they started handing stories back to the PO and saying they couldn’t make them in their forecast 😉