A few months ago, during the coffee break of a seminar, I spoke to a ScrumMaster who works at a prominent financial and media organization in the Big Apple. We exchanged notes, and he surprised me by posing a question that I had assumed would never need to arise in an organization of such stature. Sadly, my assumption was scuttled, and I reaffirmed my long-held conviction that, in the world of Scrum at least, there are no holier-than-thou organizations.
This was the question: Would you cancel a sprint planning session or a sprint retrospective to accommodate a periodic auxiliary activity at the end of the sprint, an activity that isn't directly related to the project but is considered strategically important by upper management? Obviously this was a ScrumMaster who was not grounded in the fundamentals.
My response to him was along these lines:
- Canceling — or, for that matter, even postponing — Scrum events is not recommended. If you do this, you are not following Scrum.
- As a ScrumMaster, you should expect external disturbances, and this is where you step in to keep the team firmly focused on the sprint goals.
- Since this is a periodically repeating activity on the sidelines of the main project, you have been forewarned as ScrumMaster; plan your team's capacity accordingly.
He countered my argument by saying that the Scrum team, being a well-oiled machine, felt that the sprint retrospective and planning were redundant and could be discounted whenever it seemed necessary.
I then stressed that the sprint retrospective was an opportunity for the team to pause and reflect, however exceptional the team's performance might be. Complacency is a malaise that can take a long time to heal, and following Scrum is an effective way to prevent teams from becoming too complacent.
As for sprint planning, I could only laugh at the folly or, more aptly, the arrogance of a team that felt it was beyond planning. If Benjamin Franklin and Winston Churchill felt that failing to plan is a recipe for failure, then surely the rest of us would do well to spare some thought for planning.
Perhaps this organization in the Big Apple felt it has been immunized against failure after the global financial crisis of 2008. I hope its purported immunity stands it in good stead when its Scrum sins catch up with it.
Have you encountered similar situations, and how did you go about handling them? Do you believe it is ever permissible to ignore Scrum events? I would love to read your thoughts on the matter.