Within Scrum and Agile teams, somethings are very toxic and will annihilate your Agile team if not addressed quickly. These things have more effect on the Agile teams than non-Agile teams. In this article, I will try to provide bit more clarity on why these are so devastating to Scrum and Agile teams.
Fear kills innovation. If you want your team to innovate and come up with shining new products, then fear will become a big blocker. Also, in an Agile environment, we expect the team to experiment regularly and try new things. We need to allow space for Scrum teams to fail and learn from it. If the team has fear, then they will not experiment and not innovate.
I am strongly against overtime in general, but when it is mandatory then it backfires more than it helps the organisation. When someone works extra hours one day then the following day the person will be more tired, and performance would be lacking. Research over and over again has shown that when an organisation force compulsory overtime then the performance of team goes down. Very quickly the performance goes so low that team would be delivering less with overtime then if they were doing no overtime. Overtime will not help the team go faster, in reality, it will slow them down so no point.
There is nothing wrong with having pride in our work, I say that we should always do our best and every piece of our work should be of such a high standard that it should be something we would stick on our fridge door. However, pride and ego are slightly different, and ego has no space for in the scrum team. When someone within a Scrum team has an ego, then they are not able to work as a team. They will not be able to accept the feedback from other team members. They will not be able to take the better ideas from others. The team members with ego will lead the team into major conflicts, and you might find that every Scrum ceremony becomes a battleground.
Bad Product owner:
Product Owners role is the most powerful role within the Scrum team. The Product Owner will provide direction to what needs to be built. Product Owner should represent the Business within the Scrum team and represent the Scrum Team to the business (and other stakeholders). For this role to be successful, the person doing this role need to know the product very well and have full faith in Scrum framework. They also need to listen to the Business and the Scrum team members. The business stakeholders will be providing input to the product from the market, and end-user point of view and the scrum team will be providing the technical input to help the PO to make better-educated discussions.
If the Product Owner doesn’t listen to the business and doesn’t respect the stakeholder, then the project is doomed, and it might fail in the market or get cancelled before delivery. If the Product Owner doesn’t listen to Scrum team then technically the product will not work properly and will come with significant technical debt. I have only seen one Agile project fail that was because of the product owner. The company brought in a traditional project manager who had just done is Scrum Alliance Product owner training. He didn’t know anything about the product or how the agile teams work. He didn’t trust his Scrum team and wasn’t transparent to stakeholder or the team. He agreed to deadline dates with the Business and senior management that he hadn’t shared with the team. He had also shared a roadmap with the senior management that he hadn’t shared with the team. The team was working on completely different features within the sprint then he had informed the business stakeholder. Also, he didn’t understand the product and was making the irresponsible decision about the product that would lead to its failure.
Weak Scrum Master:
The role of the Scrum master is new in the industry and one that requires lots of judgment. Scrum master does not have any formal authority on the team but needs to be someone who is powerful and resourceful. Someone who is respected by both the organisation and the Scrum team. When it comes to removing impediment then scrum master needs to be very careful, he doesn’t want to become a team’s mum that soon as anyone has any small issue that the coming running to the scrum master and he/she also shouldn’t be someone who doesn’t do anything to help the team. The Scrum master role is to coach the team into becoming self-organising and eventually make himself or herself redundant. Scrum master also needs to protect the Scrum team from external pressures including the pressure that might be imposed by PO.
Large Scrum Team:
The ideal size of a Scrum team is 7 +/- 2, and if the Scrum team get very large then teams performance starts to slow down. When many people are working on different things within the team will quickly lead to confusion and miscommunication. If the Scrum team is large, then you will have to introduce additional meetings to support the communication and planning within the team. You might also need to consider splitting the Scrum into multiple Scrum teams.
Individual performance bonus:
Individual performance bonuses can become an issue because it can sometimes lead to competition within the team. The team should be helping and supporting each other and not competing against each or trying to outshine each other.