Scrum is seen as an adaptive and flexible software development methodology which aims to improve the development process. Over the years, there have been many success stories which have been attributed to Scrum. However, some teams continue to smell a good amount of inflexibility and rigidity. Is it Scrum at fault or is it a flawed adoption process?
Terry Bunio, in his letter to Scrum mentioned, how he was initially charmed by the processes and procedures in Scrum. However, slowly he felt that the rigidity of the framework did not help him with the freedom that was required for the success of the project.
I really did need a process where I could add requirements during a sprint when it made sense. I didn’t want to be limited in the duration of retrospectives if I thought there was more to discuss. … I hated being referred to as a Scrum Master. The actual role seemed to diminish my value as a Project Manager and made me just a coach of the process instead of a valued team member. I felt that I wasn’t actually part of the team anymore.
Marek Blotny, had a similar feeling about the practice of daily standup. According to Marek, he did not like the idea of team members being in a 'hold state' until their turn to speak. This killed spontaneous knowledge sharing. He mentioned that at times, keeping to the hard set limit of 15 minutes did not help either. If there is a good discussion going on and the entire team is involved then that discussion should flow.
So if you ask me if enforcing so rigid structure of daily scrum make sense. I will answer … definitely not! On one hand you have effective and useful daily scrums which encourage teamwork and on the other quite rigid structure and doing everything by the book.
Rod Claar mentioned that though Scrum is flexible, teams adopting Scrum tend to make it rigid so that they can do right when they are doing it for the first time. Rachel Davies also saw this tendency in teams adopting Scrum. She mentioned,
When I hear about Scrum Masters or teams attempting to "do Scrum by the book" it sets alarm-bells ringing for me. Scrum is a starting point on a team's journey towards agile software development. Being Scrum is not the real goal. We use Scrum to deliver product increments. No one is going to come along to your team to check up on your Scrum conformance.
Geoffrey Wiseman added that rigidity of a process and agility are not necessarily diagrammatically opposite. The process might define that there should be no interference once a sprint is started. The sprint might be seen as an atom of planning and implementation but it is definitely open to practical flexibility.
Is that a hard line to take? Perhaps, yeah. Some might argue that if you can't live within those constraints, you shouldn't use that process. But practically speaking, can a sprint survive a momentary re-routing of a resource? Yes, I think it can, both in letter and in spirit.
Thus the rigidity of the process is as strong as the team wants it to be. Though, it is good to adhere to the constraints lest the entire process ends up in chaos however, being rigid to the extent of ignoring practical conditions is detrimental both to the project and the team.