A Simple-mantra to identify Scrum Anti-patterns

Most of the organizations are looking towards Scrum to deliver their products and projects. However, I observed that many of those Organizations are using some “Intellectual Gymnastics” (AKA anti-patterns) to customise Scrum with an assumption that it helps to improve their performance and productivity. In fact, these anti-patterns impact the organizations’ Productivity, Creativity and Flexibility in a negative way which Organizations do not realise.

Based on my experience, working with Agile Transformations, I have created a quick “Mantra” to identify the anti-patterns and to avoid them in the first place. This needs Courage, Humility and Discipline for the leaders at Organizations to take care of these anti-patterns. Especially the Scrum Masters have to be empowered to allow them to implement Scrum as it is defined.

What is the Mantra?

COCOCOSTT

CO: Collaboration: In a Scrum environment, there should be very High collaboration so the decision making will be effective and it also helps teams to perform well by developing teamwork.

CO: Complexity: Scrum is used in a Complex environment (which means unknown is more than known). So the practices that are being used must reduce the Complexity.

CO: Communication: Scrum teams should have high communication (especially face-to-face as much as possible, Agile Principle #6) so the to-and-fro loops of communication can be avoided.

S: Self-organization: Scrum teams should be self-organized in order to make the decentralised decision making.

T: Trust: Scrum teams must demonstrate Trust within themselves which leads to Transparency.

T: Transparency: The foundation for Scrum is Empiricism which means “Knowledge comes from experience and the decisions are made based on what is known“. The three legs of Empiricism are: Transparency, Inspection and Adaptation. Without the Transparency you cannot have the other two legs implemented effectively. So Transparency of Artifacts and the practices used have to be very high within the Scrum teams.

So What?

Now, in an ideal situation of Scrum implementation, you need to use practices that help manage the above properties in the following manner.

Collaboration should be high, Complexity should be reduced, Communication should be high, Self-organization should be high, Trust and Transparency should also be high.

Now What?

When you work in a Scrum environment, and when you get into a situation where you are not clear whether the current practice that you use is suitable or not, you can check that using the COCOCOTT mantra. Below are some examples for your reference.

Scenario-1: Product Owner and Scrum Master are the same Person.

Now, let us check this scenario against the COCOCOSTT parameters. In this situation, Collaboration will decrease (due to role conflict), Complexity will increase (Development team will get into confusion due the same person playing both roles and also there is none to protect them), Communication will lead to conflicts, Trust will be low, Transparency will be low. That means all the parameters are behaving negatively in this scenario. So this is not a good practice to implement.

Scenario-2: In a multi-team Scrum implementation, teams do not have mutually agreed DoD

When you apply this scenario to the above parameters, it increases the complexity (due to delayed integration issues, lack of understanding on “done” by all teams), decreases the transparency. So the teams should have a shared Definition of Done which is a minimum criteria and on top of it, each team can have their own stringent Definition of Done.

Scenario-3: Forcing Development team members to work on more than one team at a time

I found this gymnastic at various organizations. Leadership teams think that making people work on multiple projects at a time is a kind of optimization, but it is not! It increases the Complexity (due to task switching and dependencies) and reduces Transparency, reduces Trust and Collaboration and Communication will be negatively impacted. Self-organization becomes difficult in this scenario due to dependencies.

Scenario-4: Assign a Project Manager on top of the Scrum Team to micromanage the team

This clearly indicates that the Collaboration decreases within the team due to the involvement of controlling and micromanaging factors, team’s self-organization will deteriorate due to which their communication gets impacted, Trust will be reduced thereby complexity increases.

Similar to the above scenarios, you can take any scenario in your organization and apply the COCOCOSTT, and see how these parameters behave for the given scenario. If any of these parameters behave opposite to their expected behaviour, that means it is an anti-pattern and the Scrum Master should find a practice to address that scenario.

Scrum is SIMPLE, but not EASY. I hope that the COCOCOSTT Mantra can help make it easy to identify the Scrum anti-patterns and address them before they impact organizational growth.

Please share your thoughts and suggestions on the COCOCOSTT Mantra.