The importance of rituals during the Agile journey
Transitioning from traditional project management approaches to the Agile framework is not an easy task. Many organizations therefore undergo a prolonged transitional phase, and rightly so. After all, change in the organizational mindset is not something that happens overnight. The most successful teams are those who have understood and believed in the underlying principles and philosophy of Agile.
I have come across teams that started off enthusiastically on their journey to Agile, only to fizzle out in the long run. It is thus imperative to keep a close eye on the symptoms that have the potential to derail progress toward an Agile culture.
One of the symptoms that cannot be ignored is when rituals are circumvented or not followed at all. Why are rituals so important? In human society, rituals play an important role. Be it through religion, sports, or science, rituals reinforce behaviors. When performed in groups, our individual selves are transformed into collective selves. This collective behavior is paramount for teams.
A typical problem that teams face is that they think they have a grip on Agile and can now tweak it at their convenience. I am using the term convenience
here because this is actually the main reason for deviating from what is the right course of action.
Symptoms of a derailing Agile transformation
As a team, we must be aware of the following symptoms that express themselves in specific rituals.
Unfortunately, retrospection often becomes the first casualty of not following rituals. Humans tend to not look back and analyze the past so that they can learn from it. Our focus is usually on the things to come. It is therefore important to take this ritual seriously and watch out for these red flags:
- Retrospection notes are not logged for future learnings and actions. The points must be logged and categorized for future reference.
- The same points are raised in every other retrospection huddle. This means that while we are discussing the issues, we are not learning from our mistakes or not doing enough to solve the underlying issues.
- The team rushes through retrospection meetings. Most of the team members seem uninterested, or they hardly contribute.
- The retrospection huddle meetings gradually stop altogether.
During the Agile transition phase, the focus is initially on estimations and related techniques to arrive at these estimations. However, when the team believes they have matured in the process, complacency kicks in.
Here are few things that we need to watch out for:
- As team members collaborate more and become a strong cohesive unit, they tend to agree more with each other. This is an encouraging sign, of course, but the ScrumMaster and other stakeholders should keep a close eye and intervene when he or she observes that members are not questioning each other or challenging the benchmarks enough. The estimation should not be diluted because the team blindly follows one member's estimate without doing their bit.
- Teams move away from Planning Poker® or other related private estimation approaches and toward more consensus-based approaches. This dilutes the very objective of the estimation exercise. The team must stick to approaches that are aligned with the objectives of informed, unbiased, and uninfluenced estimates.
- Teams rush through estimations. Detailed discussions do not happen and therefore the requirements are not analyzed adequately. The result is inaccurate estimates, which keep changing during the course of the sprint when requirements must be clearly understood. We all know that there is no such thing as an accurate estimate; however, we must spend enough time to understand requirements to come up with the best possible estimate.
- Even though estimations are done using story points/counts, back-of-mind calculations are instead represented in units of time for every story. A hybrid approach like this fails in its very purpose.
Planning is always a tricky aspect of Agile. The magic spot is where we strike a balance between adequate planning and required flexibility. The focus must be on the exercise itself, and not too much on the result.
As Dr. Graeme Edwards once said, "It's not the plan that is important, it's the planning."
- The objectives of Agile planning fail when the team tries to strictly stick to planning or becomes so flexible during implementation that the planning activity becomes useless.
- As with all other rituals, the team rushes through the planning phase by just picking up the stories from the top of the backlog. There's no discussion about how stuff will be tested, dependencies and risks identified, and how releases will happen.
- A Waterfall approach is hidden within sprints — stories are not broken down, testing starts only when the entire feature development is completed, etc. This is a typical case in which the team appears to have adopted Agile as a process, but they have failed to imbibe the true principles of Agile.
- Sprints are planned and stories picked up based on predefined release dates or deadlines. When this happens sprint after sprint, it is a clear indication that the team is moving away from Agile.
In addition to these common rituals, there are other instances that, if not checked and acted upon, have the potential to stray the team from true Agile. One of these is the influence of stakeholders, such as functional managers, product owners, and top management. These are individuals who should have relinquished control of their products or processes over to their teams after moving to Agile, but they directly and indirectly continue to influence the team. Over time, the development team gives in to their demands. It is thus important for the ScrumMaster and the team itself to ensure that no external influences should result in deviation from the Agile spirit.
A continuous check for such symptoms will help the team advance and keep improving. For an Agile culture to flourish, the team, ScrumMaster, stakeholders, and management should nip these issues in the bud.