The Anti Patterns in Scrum

There are certain practices that we do in scrum that are counter productive. These practices are called 'Anti Patterns'. Here in this blog, I have discussed some of those perils in Scrum teams.

Team Size: Scrum manifesto clearly states that the Scrum team size should not be more than 9. It is even better if it is of lesser than 9, but definitely not more than 9. Rightly said as the scrum team members should all know what every other person is doing. They need to work hand in glove! This is only possible when the team size is less. A team of size 'n' has n*(n-1)/2 communication channels. In the figure below we see that a 5 member team has 10 communication channels. 

• 1 talks to 2, 3, 4,5 and vice versa = 4 channels
• 2 talks to 3, 4, 5 and vice versa = 3 channels 
• 3 talks to 4, 5 and vice versa = 2 channels
• 4 and 5 talks = 1 channel.

If it were a 10 member team, imagine the chaos. we would have 45 channels of communication and it would be a herculean task to know what each team member is doing.

So keep the size to 5 to 7 members.

Changes within a sprint: Sprint is a short burst of work period. It has a well defined goal. The main essence of the scrum model is to analyze priority, ship it to customers quickly and get early feedback. Changing the scope or changing team members will have a negative impact on meeting the sprint goal. A clear anti pattern that you may want to avoid.

Ignoring the retrospective and its actions: The most important scrum ceremony in my opinion is the retrospective. This is because, we talk on the actual data. What actually worked and what let us down. It helps us as teams and as individuals to understand where we went wrong and self improve. It's an immediate feedback. Where else do we get it? Half yearly or yearly manager feedback? Really, do you want to wait a year to know what worked and what not? Conducted correctly in its spirit and working on its actions will see the teams only performing better and better. Participate, be vocal.

Lack of cross functional team: The scrum team should have developers, QAs, the availability of product owner, architects etc to perform their work seamlessly and independently. It is also very important to have every developer and QA backing up each other, so that on emergency situations, the other Dev/QA can pick up the work. That is precisely the reason why each team member should know what the other is doing and forms the basis for the team size.

Delayed testing, bug fixing: Testing, raising and bugs and fixing should be done within 24 to 48 hours of the code being sent to the QA for testing. Why is that so? The code logic is still afresh in the developers mind. Remember that in all probabilities, its a very complicated logic, where changing a single boolean value could wreak havoc. Strike while the iron is hot - give the bugs to the developers when the logic is very fresh in their minds and therefore rework/fix can be done very fast. 

There are many more - like the unavailability of the Product Owner, having a poor definition of done, having hierarchies in a team (note that scrum team has only 3 roles, the scrum master, product owner and the team) etc. We need to be aware of these anti patterns, educate the scrum teams about it to build a highly productive and collaborative team.