When Scrum rituals are used without a deep understanding of their purpose, they can degenerate into hollow activities done for the purpose of following the form, but without creating their expected benefits. For example, I have seen many sprint retrospectives following the form precisely that produced nothing more substantive than “the team communicated really well this sprint” or “we rolled over too many tasks from this sprint to the next [AGAIN].” The issue was that the team wasn’t thinking about what the purpose is of the rituals and how to assure that they produce value.
In our team’s use of Scrum, I’ve promoted the principle that for every tool and each element of a tool, the team must know its purpose. By knowing each element’s purpose then for its application to the project being considered you:
- Can determine if the element is relevant and needed
- Can understand what is needed to meet its purpose and then can focus on ensuring that its purpose is met.
- Can choose to use the tool for analogous situations that don’t specifically require it but where it provides significant value
These in turn allow you to make decisions about how to apply each element of the methodology or plan intelligently to achieve the purpose as efficiently as possible.
In the case of retrospectives, the primary purpose is to identify specific team techniques that work well so they can be reused and reinforced, and to pinpoint specific team techniques that aren’t working well so they can be remediated. This understanding of the purpose should drive the conversation that the team has during retrospectives. From the discussion, there should be specific actions following from the retrospective and they should be assigned to an individual on the team.
For more about pro-forma rituals in software projects see: Cargo Cult Agile.
