The term anti pattern as used in the software world is an expression of what are initially attractive, easy to implement solutions. But actually, far from solving the problem, they end up causing bigger ones.
Scrum as stated in the Scrum Guide “is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is
- simple to understand,
- difficult to master.”
In less than an hour, you can explain all the elements of Scrum to someone.
Since it is easy to understand beginners can take it easy and misuse the framework. They may use some of the practices out of the whole and repeat them in a mechanistic way without understanding the principles underlying them. Without changing anything and challenging yourself can you expect an increase in your productivity?
Let us keep in mind that Scrum will not turn everything into a miracle overnight. When people are accustomed to new forms of work that time is needed, especially for cultural transformation. Be patient, do not hurry to show up too early, just start by applying it as it is coached by an Agile Coach, challenge yourself, change your way of working and understand the principles.
I will now talk about the most common "anti patterns" to give you an idea. This may help you to inspect yourself and your team. I have observed some of these during agile team assessments to companies who were struggling to find out why they were not improving although they started to apply Scrum.
- The team waits for a task to be assigned to it or asks for the Product Owner to assign the tasks, thus destroying its development of self-organizing and decision-making capabilities.
- The "Master" part of the ScrumMaster's name is perceived as technical or domain expertise, and as such, this person is identified as being the most experienced software developer on the team. This negatively affects the team’s development capacity.
- The Product Owner and team meet only at sprint planning and review. This usually means that the Product Owner is not spending time with the team and the customer during a sprint, so the decision-making and learning process is slow.
- At the sprint planning meeting, all tasks are assigned from person to person, and everyone is solely responsible for their own task, so they are not functioning as a team by, working individually, without collaborating with each other throughout the sprint.
- If they work in the manner which is described in the upper item it is not surprising to hear that the Daily Scrum, which allows collaboration and the ability to make daily decisions as a team give up doing Daily Stand up.
- The team and the Product Owner are focusing on completing tasks rather than delivering value.
- They don’t do retrospectives and they don’t actually challenge themselves to change for better.
- There is no sprint review, or when there is the team shows what was completed in the sprint rather than inspecting on the value that was delivered and reflecting on the sprint goal.
- Meetings do not respect the ‘timeboxes’.
- As the sprint continues, the sprint backlog changes a great deal.
- The team carries the user stories from Sprint to sprint and works on the same story for several Sprints showing the indication that there is a problem with splitting them or they don’t understand the iterative and incremental way of working.
- In the sprint planning the team only discusses the 'what' part and forgets to discuss how the pulled items are going to be developed.
- The sprint planning meetings are long (i.e. they exceed the timebox) because of lack of backlog refinement meetings.
- Team performance is compared on ‘velocity’.
If you see your team as having these anti-patterns, all is not lost. There are ways of recovering from them such as helping the structured coaching approach and ask help from an experienced Agile Coach.