Over the past 10 years I have worked with many organisations and helped them to use Scrum to create innovative and sometimes market leading Products. I have seen a lot of Scrum during this time, much of it done well, but some of it done badly. Here are the 5 common anti patterns that I see with teams learning to use Scrum and improve what they do. If your team is exhibiting these characteristics beware! Take action or you may soon be visited by the "fail whale".
A key part of Scrum is developing the discipline to create a truly "done" increment by the end of each Sprint. By "done" we mean some potentially releasable software with valuable new features for your users or customers. Many teams introduce Scrum, but retain their waterfall mindset and defer important activities, such as testing for later Sprints. The result is that quality suffers immediately, undone work accumulates and we queue up mounting problems for later.
Eventually the Product becomes full of partially complete features, all of which need to be revisited and fixed and completed at a later time. Transparency suffers and you fail to build trust with your stakeholders and predictability for your project. The likely outcome is that you will miss any deadline that has been set and there will be a death march to fix a mountain of issues before your first release.
Many teams I have worked with initially struggled to successfully complete Sprint Planning. They would plan the work for the current Sprint but then be unable to complete it by the end of the time box for the Sprint. There are many reasons this can occur, but the most common (and easily resolved) is a lack of definition in their Product Backlog.
Product Backlog items were not clearly defined (or "ready") coming into the Sprint, with the result that the Development Team did not know enough about them to be able to effectively plan how to deliver them and how much time would be required to do so.
The answer to this is to spend additional time on Product Backlog Refinement to add enough detail to upcoming high priority Product Backlog Items. Although the Product Owner is responsible for the Product Backlog, this should be an activity for the whole Scrum team in every Sprint. The entire Scrum Team must collaborate to solve this issue which will often be vital to allow further progress to be made.
The Scrum Master may be new to the role and retain their command and control management style. The Development Team may be uncomfortable or unfamiliar with the concept of self organisation and so look to the Scrum Master as a manager who will provide answers and make decisions for them. Either way the team fails to self organise.
The result is that the Development Team loses the potential to benefit from their collective wisdom. The solutions they come up with only be as good as the abilities, knowledge and experience of the Scrum Master. Motivation usually remains low, coordination of work is driven by the Scrum Master and productivity will be severely restricted. The Scrum Master will be a bottleneck to the performance and success of the Development Team.
The organisation puts together a team, introduces Scrum and starts a project. However the Development Team only contains the people available to the organisation at that time. There are vital skills missing from the team. Yes, the team can learn and develop these skills but where there are fundamental gaps right from the start they will be faced with an uphill challenge.
Progress is still expected immediately and the team do their best, but usually the result will be significant amounts of undone work and technical debt which must be repaid at some time in the future, and before the Product can launch. Expect delays, big delays!
The organisation wants to be Agile and introduces Scrum as a step along the path, but still launches projects with fixed scope, budget and timelines. Yes, Scrum can still help in this environment, but the potential for agility will be low.
Valuable improvements to the Product will be identified in Sprint Reviews but will have to deferred in favour of completing the originally agreed scope. Much of this initial scope will be lower value, but the plan and expectations are in place and cannot be changed.
The Development Team learns that initial estimates were not perfect (surprise, surprise - this is difficult to predict complex software development after all) but no scope reduction is possible and no additional or resources or time can be added. The team is pressured to complete the work as initially planned. They will do their best, but what will happen is that quality will be compromised and the target date will still inevitably be missed. Pressure and stress will increase as time goes on and actually the team will end up far less productive over all. The project will complete late and result in a lower value, lower quality Product being created.
These types of scenarios will occur on many projects. The secret to solving them is to use the inspection, adaptation and transparency that comes with Scrum to highlight and fix these dysfunctions as they are identified. If the organisation is serious and committed to becoming Agile, then this is the only way to be more successful. Scrum challenges us to change the things we have always done (that did not work well). This is often difficult, but is essential if we are to improve, which is what it is ultimately all about.
The alternative is to use Scrum, ignore the problems it highlights and then for projects to continue to struggle as they always did. Scrum brings no easy answers, but does show us the difficult problems we face and challenge us to address them.
Not Producing A "Done" Increment By The End Of A Sprint
A key part of Scrum is developing the discipline to create a truly "done" increment by the end of each Sprint. By "done" we mean some potentially releasable software with valuable new features for your users or customers. Many teams introduce Scrum, but retain their waterfall mindset and defer important activities, such as testing for later Sprints. The result is that quality suffers immediately, undone work accumulates and we queue up mounting problems for later.
Eventually the Product becomes full of partially complete features, all of which need to be revisited and fixed and completed at a later time. Transparency suffers and you fail to build trust with your stakeholders and predictability for your project. The likely outcome is that you will miss any deadline that has been set and there will be a death march to fix a mountain of issues before your first release.
Lack of Product Backlog Refinement
Many teams I have worked with initially struggled to successfully complete Sprint Planning. They would plan the work for the current Sprint but then be unable to complete it by the end of the time box for the Sprint. There are many reasons this can occur, but the most common (and easily resolved) is a lack of definition in their Product Backlog.
Product Backlog items were not clearly defined (or "ready") coming into the Sprint, with the result that the Development Team did not know enough about them to be able to effectively plan how to deliver them and how much time would be required to do so.
The answer to this is to spend additional time on Product Backlog Refinement to add enough detail to upcoming high priority Product Backlog Items. Although the Product Owner is responsible for the Product Backlog, this should be an activity for the whole Scrum team in every Sprint. The entire Scrum Team must collaborate to solve this issue which will often be vital to allow further progress to be made.
Scrum Master As The Development Team Manager
The Scrum Master may be new to the role and retain their command and control management style. The Development Team may be uncomfortable or unfamiliar with the concept of self organisation and so look to the Scrum Master as a manager who will provide answers and make decisions for them. Either way the team fails to self organise.
The result is that the Development Team loses the potential to benefit from their collective wisdom. The solutions they come up with only be as good as the abilities, knowledge and experience of the Scrum Master. Motivation usually remains low, coordination of work is driven by the Scrum Master and productivity will be severely restricted. The Scrum Master will be a bottleneck to the performance and success of the Development Team.
No Cross Functional Teams
The organisation puts together a team, introduces Scrum and starts a project. However the Development Team only contains the people available to the organisation at that time. There are vital skills missing from the team. Yes, the team can learn and develop these skills but where there are fundamental gaps right from the start they will be faced with an uphill challenge.
Progress is still expected immediately and the team do their best, but usually the result will be significant amounts of undone work and technical debt which must be repaid at some time in the future, and before the Product can launch. Expect delays, big delays!
Lack Of Agility From Fixing Scope, Budget And Timeline
The organisation wants to be Agile and introduces Scrum as a step along the path, but still launches projects with fixed scope, budget and timelines. Yes, Scrum can still help in this environment, but the potential for agility will be low.
Valuable improvements to the Product will be identified in Sprint Reviews but will have to deferred in favour of completing the originally agreed scope. Much of this initial scope will be lower value, but the plan and expectations are in place and cannot be changed.
The Development Team learns that initial estimates were not perfect (surprise, surprise - this is difficult to predict complex software development after all) but no scope reduction is possible and no additional or resources or time can be added. The team is pressured to complete the work as initially planned. They will do their best, but what will happen is that quality will be compromised and the target date will still inevitably be missed. Pressure and stress will increase as time goes on and actually the team will end up far less productive over all. The project will complete late and result in a lower value, lower quality Product being created.
How Not To Fail
These types of scenarios will occur on many projects. The secret to solving them is to use the inspection, adaptation and transparency that comes with Scrum to highlight and fix these dysfunctions as they are identified. If the organisation is serious and committed to becoming Agile, then this is the only way to be more successful. Scrum challenges us to change the things we have always done (that did not work well). This is often difficult, but is essential if we are to improve, which is what it is ultimately all about.
The alternative is to use Scrum, ignore the problems it highlights and then for projects to continue to struggle as they always did. Scrum brings no easy answers, but does show us the difficult problems we face and challenge us to address them.