Scrum is a very powerful framework, but almost anything in this world it has his own weaknesses. Same as in the bible the four horsemen of the apocalypse, I have isolated four cases that will lead to destroy scrum teams.
“Conquest” : An organization that doesn’t want adapt to Scrum
One of the roles of the scrum master is to ensure that the organization understands scrum by ensuring that management understands the new roles, new ceremonies and new way of doing things.
When the organizations don’t trust on their teams they tend to be very careful. That carefulness lead them to fear that ends adding a high level of control over the team, with more planning, more documentation, more reporting, … in general more un-agile.
When this happens the most common outcome would be a big Scrum failure. The management of the organization will proudly say: “We tried Scrum and it doesn’t work for us”. And it is true, it didn’t work because you never tried the proper way.
“War” : A client that doesn’t want to collaborate
“Customer collaboration over contract negotiation” – Agile manifesto
Indeed this is one of the pillars of the agile manifesto itself. One of the basic statements that agile seeks is cooperation among customers and development team.
When you have a customer that creates a very detailed SOW(scope of work) and makes you sign on each of the items and their scope. It is very likely that he’s not going to be willing to negotiate afterwards. If your customer cares more about what is written on the contract than the real value of the product that you’re building, then you should not use scrum.
One of my biggest failures with scrum was with a big web project, more than 1MM USD. Our customer was a big old company that wrote a very detail contract on what they wanted and how they wanted to build. Then they also added a line in that contract “We will do this following Scrum/Agile”. As the project was moving forward we where working with our customer to ensure that we delivered the highest value based on their updated requests (requirement updates to adapt to new market requests). But when the budget of the project was over and there where still items from the original scope not finished the customer forgot about the collaboration part and requested for the remaining items to be finished.
Scrum usually will fail with a fix scope contract. Instead of that try to arrange a fix price contract or dedicated team.
“Famine” : A team that doesn’t want to use Scrum
When your own team doesn’t understand the values of scrum they might be not engaged to use it. It might be that they used in the past and had bad results, and because of that they don’t want to use it anymore. Or just because they’re tired of any innovations and they just want to do their jobs with the minimum amount of though on it.
If your team doesn’t really engage with scrum values it will be very difficult that you manage them to self organize. They might assist to the ceremonies, but they will not be engaged, and the daily scrum would be more a place to perform the daily report than a moment to increase transparency.
I have faced teams that were skeptical about scrum in the past, I’ve been lucky that I have managed to present the benefits of scrum to the team and have them engaged. For this specific case I don’t have magic formula, as scrum master what I did was avoid being the master piece in their interactions and become just a facilitator.
“Death” : A team mission not suitable for Scrum
I think I should start by the basics. Scrum is very useful in a variety of situations, but can’t always be applied. So if your project doesn’t fit on Scrum try to use other agile methodology like Kanban, Lean or any other.
Scrum is used to achieve increments of potential shippable products through iterations ensuring that the team delivers value soon. But it is difficult to use when the pipeline of work is not stable or predictable or where the urgency to deliver to market can’t be fit into an scrum iteration.
Imagine for instance a team that is providing a quality support service. They might have times where the workload is close to none and other times when a lot of items with higher priority are jumping on the doors. In this situations it is not possible for the PO to predict in sprint planning what are going to be the most important items during the sprint as most of them haven’t been identified yet, therefore would be numerous changes that would make the original sprint goal to be totally obsolete.
Appreciate if you read until this point, any feedback?
So what do you think? do you agree with this post? would you like to add something more? leave it in our comments