Hearing a team say “Scrum doesn’t work for us” can trigger a negative reaction, based on an assumption that the team doesn’t understand Scrum or isn’t doing it right, but it could be a positive sign – maybe the team is growing and needs to move beyond “Scrum by the book”.
Scrum can be a good starting point because it provides structure and guidelines on how to “do” Agile – the Scrum Guide specifies roles, artifacts, and events. It specifies pillars (transparency, inspection, and adaptation) and values (commitment, focus, openness, respect, and courage), so it also tries to instil a mindset of “being” Agile. Scrum’s definition states “Scrum is simple” and “purposefully incomplete”; it is not intended as an endpoint but as a stepping stone on an Agile journey.
But rather than say “we’ve outgrown Scrum” and throw it away, this could be an opportunity for the team to inspect the way they work, consider which aspects they would like to change, and then run experiments to try to move towards where they want to be. That might sound like a retrospective, and that’s not an accident – effective retrospection is, I believe, the engine that powers change. If, for example, a team identifies the way that they collaborate during a sprint as something they could improve then they may decide to try pairing for the next couple of sprints. After those two sprints, they should ensure they discuss collaboration in their retro and whether pairing is helping – it could be they decide to extend the experiment, try something different, and adopt it permanently as part of how they work.
Another example could be to move towards kaizen (continuous improvement); maybe the team decide it’s working so well that they decide to drop scheduled retrospectives from their calendar. A purist might ask if you are still doing Scrum if you aren’t doing everything in the Scrum Guide; as a pragmatist, I would be pleased to see the team grow and wouldn’t care what they call it.