based

COMMON SCRUM MISTAKES AND HOW TO AVOID THEM [#Agile #Scrum #ScrumMistakes]

1. DAILY STAND-UP MEETING IS NOT A STATUS MEETING
2. IMPEDIMENTS NOT BEING REPORTED EARLY ENOUGH
3. PROCESSES AND TOOLS OVER INDIVIDUALS AND INTERACTIONS MINDSET
4. DO WE NEED A SCRUM MASTER?
5. COMMITMENT BASED ON ASSUMPTIONS
6. NO OUTPUT FROM THE RETROSPECTIVES
7. INAPT PHYSICAL ENVIRONMENT
8. MISSING DOR AND DOD
9. IS IT A TEAM OR A HORDE?
10. THINKING AGILE MEANS NO DOCUMENTATION

1. DAILY STAND-UP MEETING IS NOT A STATUS MEETING
From pre-scrum days, the delivery teams have been working in a mode where they are answerable either to their manager or the lead for their work. They are in this habit of working through the status meetings.

However, Daily Scrum or Daily Stand-up meetings are far different. These meetings are for the team as compared to the individual.

2. IMPEDIMENTS NOT BEING REPORTED EARLY ENOUGH
One of the best things about Scrum is early addressal of impediments so that the team commitment is not hampered as Sprints are time-boxed.

Most of the time, if a team member is blocked, they tend to wait or resolve issues on their own rather than raising a flag within the Scrum Team. This might work sometimes, but this is not the ideal approach. There could be cases where dependencies are involved.

Hence, raising the impediment upfront helps the teams and the team members adjust their workflow for minimal impact. The Scrum Master should maintain a log for impediments and track them to closure.

The delivery team should be provided with an environment to voice their issues without fear. Anything that is coming their way of delivery should be raised immediately.

3. PROCESSES AND TOOLS OVER INDIVIDUALS AND INTERACTIONS MINDSET
These days, we have efficient and effective web based tools to handle the backlog and the workflow, and the same goes for communication as well.

With such vast variety of tools, the delivery teams tend to rely more on these tools rather than individual interactions.

The Scrum Master can set some working agreements with the delivery teams to overcome such issues. The teams can define how they want to work, and they can set their own rules. The focus should be more on collaboration and interactions rather than processes or tools, but this does not mean they can get away with the tools, since the tools are still important!

4. DO WE NEED A SCRUM MASTER?
As prescribed by the Scrum Guide, the Scrum Team consists of a Product Owner, Development Team, and the Scrum Master. Each role has its own responsibilities and its own boundaries. This gets thinned out when the role of a Scrum Master is not taken seriously.

It is really critical to understand that if a team member with some other role plays the role of a Scrum Master, they are hindering the ability of the person to focus on helping the teams, following processes or removing impediments. It is a very crucial role which helps the ship to sail through along with shielding the team from external distractions.

5. COMMITMENT BASED ON ASSUMPTIONS
The delivery teams are hesitant to ask back. As per the Scrum framework, there is no proper Product Backlog grooming done to make it free of assumptions.

Most of the times, delivery teams are asked to commit just because the requirement is on priority. They are not given enough time to think through or brainstorm and they just commit. This not only leads to carryovers but also lowers the morale of the teams.

It is important to clarify questions with the Product Wwner, talk about the dependencies and constraints. Continuous communication should prevail between the Product Owner and the Development Team throughout the Sprint.

6. NO OUTPUT FROM THE RETROSPECTIVES
Retrospectives are the times when the Agile / Scrum Teams inspect themselves and think through their actions to make them better next time.

There are several ways of conducting the retrospectives, but the most important thing is tracking the action items discussed during the meeting. If the action items are not closed, the trust on the ceremony gets impacted and the teams will start considering them as not adding value to the time being spent.

Hence, it is the responsibility of the Scrum Team to make sure the actions items discussed during the retrospectives get closed. Here, the Scrum Master can help with facilitation and tracking. Every retrospective should include the status of the last retro action items. This gives confidence to the team that they are being heard and they feel empowered as well.

7. INAPT PHYSICAL ENVIRONMENT
Ideally, the Scrum teams should be sitting together. All the Development Team members, the Scrum Master, and the Product Owner should be in a single room or in a single bay. Focus should be more on the individual and interactions and face-to-face communication.

In cases where the teams are not collocated, it gets difficult to work with big distributed teams. This not only impacts their collaborative efforts, but also hampers productivity. Hence, efforts should be made to help the team sit together.

8. MISSING DOR AND DOD
Definition of Ready (DoR) contains few parameters as set by the delivery teams, to say when they are good to commit Product Backlog items to a sprint. Similarly, the teams should have Definition of Done, to say when the item committed in a sprint is ‘Done’.

Both DoR and DoD enhance the quality of the product being delivered. The Scrum Master should ensure that the creation of these agreements happens before the start of the sprint and they gets revisited at whatever frequency the teams are comfortable. If the teams have defined their DoR and DoD, the dependencies, risks, and unknowns are minimized.

9. IS IT A TEAM OR A HORDE?
It is always easy to work with smaller groups. Even the Scrum Guide talks about having a team size of 7 (+/- 2).

When you are working with a large Scrum team, communication becomes the biggest challenge. As the size gets bigger, the ceremonies would take a long time as well and with shorter sprints, these meetings become a pain for the team.

10. THINKING AGILE MEANS NO DOCUMENTATION
Nowhere in Agile Principles or Manifesto, we find No to documentation.

We should create documentation that delivers value and at the same time does not obstruct the progress of the Scrum Team.

ADAPTED FROM
The most common Scrum mistakes and how to avoid them:
GreyCampus