Retrospect your Scrum: Stop making these most common mistakes !

Scrum has become a widely-adopted practice for managing software development projects. It has all the ingredients of agile methods, addressing the core issues confronted by the traditional waterfall model and delivering iterative and incremental end results.

Scrum, just like any other management practice, finds it difficult to be applied the same way it was originally envisioned. It is quite often adapted to the needs of specific development projects, extending the natural benefits of scrum by integrating with other best practices that could arguably strengthen the process for better team culture and quality deliverable.

As long as the core values of scrum are assured, any topping over scrum would look just like crown of the queen. But unfortunately, the reality turns out to be different, as people might end up overlooking or losing the scrum values on the fly. Here in this article, we would carefully consider some of the most common scrum mistakes that should be eschewed.

Directed, rather than self-driven:

Practitioners of scrum, especially scrum team members, are expected to be self-organized and self-driven, not directed (or in a critical term, micromanaged). Apparently, it intends to express the idea that everyone in the scrum must be aware of Sprint (a single unit of development iteration) goals and tasks to be performed as an individual in order to achieve the common goals as a team.

Ironically, it is not an uncommon sight in scrum atmosphere that Product Owner is mistaken for Project Manager and Scrum Master is mistaken for Team Lead, reflecting our same old mundane thought processing over enriched medium. This could very well be observed in daily stand up meetings if the updates are typically asked-for - like what is the progress of topic X?, what happened to the issue or ticket Y? or why was task Z not done? and so on - rather than provided-spontaneously - like voluntary provision of information by each scrum individual on the topics at hand with the status on Done, To-be-done and Show-stoppers, if any. 

It is very important that we clear this traditional mindset away to relish the true value additions that Scrum could bring in. Undoubtedly, there could be times when certain details are asked for if they are not readily made available and at the same time, very much required. Such instances are too perfectly fine.

Scrum is like a long car trip with everyone on board a driver. As everyone could drive (i.e., contribute to the cause), imagine how stress-free and pleasant that travel would be?

This precisely reflects what is expected in a typical scrum working environment. To conclude, what we need is a promising platform that promotes and helps scrum team members drive and organize self, collaborate and work collectively as a team towards common goals.

Manager in Retrospective meeting:

Scrum retrospective meeting is generally facilitated by Scrum Master after each Sprint and emphasizes on analysis of how we have performed in the process of achieving our project goals. This meeting is meant to be self-critical, by digging deep to find out what we have done very well, where we have flawed and what needs to be improved in future for better delivery.

This meeting engages the participants, typically scrum team members, to recognize the good work done and appreciate them with the right spirit, resulting in keeping the motivation level up among people to continue the solid work they have been doing. At the same time, it is also expected that we turn to be self-critical and identify our own problems and areas of improvement. But let's be cautious that being self-critical is like a walk on a glass bridge, so it has to be done politely, prudently and meticulously; Let us not make it a time and place for the game of blames, rather a heavenly way to trump ourselves.

It is better that we find our problems ourselves rather than they are spotlighted and critiqued by someone outside the team that might be embarrassing and become too political from management perspective. Such introspection is in our best interest. But, what if manager, who is the sole decision maker for much of the career related aspects such as performance review and appraisal, promotion, hike and etc., is present in such a meeting? Yes, you guessed it correct! People might tend to feel handcuffed and go muted or pretend as if everything has been going smooth and been done best so far, obstructing the scope for discussion on the obscure "ground reality" and invalidating the solitary purpose of the meeting.

With the presence of manager, people would end up feeling insecure and uncomfortable to open up, as doing so might be viewed as an unwelcome disruption and negative flow of energy within the team and result in causing more worse than good. All in all, this meeting must never be mistaken for a feedback session on people's performance. That is certainly not what it is meant for.

Having said that, it is quite so important to set up the the stage for retrospective meeting with the right set of audience and agenda that we avoid any rippled catastrophic effects and achieve fruitful results from the the meeting.

Scrum Master in dual role:

It is no unconventional to see today that many scrum teams could not afford to have a dedicated Scrum Master for several reasons. On the contrary, this role is carried out by a scrum team member – probably a senior or someone, who is experienced in the process followed in the current project, either from development or quality team.

In such cases, he or she is expected to perform a dual role that might meet demanding project needs, but certainly not scrum principles in practice. It might be true, at least on paper, that as long as the role and responsibility is clearly defined and followed, there would be no problems. Yet it would still be a myth, as such a dual role assignment could lead to complaints relating to conflict of interest, work load, and so on. Truly speaking, it might not be practically feasible to fulfill the needs of each role without having one influencing the another. Therefore, it is highly recommended to keep off such a dual role as much as possible.

Being followed up, not feeling responsible:

Lingering effects of conventional project management persuade people in scrum to expect others to follow up with them on everything they do, whereas they are actually expected to be so liberated and feel responsible on whatever they have committed to do. The more we expect to be followed up, the less we become self driven and self reliant, letting Scrum just walk away from us.

This is just more of a mindset problem, an inherited legacy from past; It can easily be taken off the track with minimal efforts - what you need to do is "Just feel responsible and deliver". That is all it takes.

Lengthy daily stand-up meetings:

Daily stand-up meeting is meant to stand for short period of time, not go on till our legs are paining. Otherwise it would have been sit-down meeting, not stand-up meeting. Jokes apart; But lengthy stand-up meeting is superfluous, since any extra time spent will eat up the actual development time. Typically this meeting is expected to last only up-to maximum of 15 minutes; When we go farther than this, we are actually exploiting the situation.

There could be various factors contributing to long running of stand-up meeting beyond the scheduled time. Detailed discussion on technical topic, big sized scrum team needing more time for complete round of updates are to name a few. Let us try fixing such core issues and start adhering to the agenda and time line of the meeting. That would definitely make the meeting short, crisp and interesting.

No Scrum Master, no daily stand-up:

Scrum Master is merely a facilitator for daily scrum meeting. Though the presence of Scrum Master could make a difference in the meeting, it is not compulsory that he or she needs to be present. Quite often it can be seen that when Scrum Master is not available, no daily stand-up meeting is conducted. That is not correct. As long as each scrum team member knows of and is trained to do what is expected out of daily scrum meeting, the meeting must go on. Of course, it is very important to bring out the issues to Scrum Master's attention if needed.

So what are your thoughts on common Scrum mistakes? Please share your views in the comment section below - it would be more interesting to learn. :)