DEV Community

Cover image for Where is ok not to use SCRUM?

Posted on

Where is ok not to use SCRUM?

The Scrum methodology is one of the most widespread of the agile project management methods. More and more companies decide to try this approach (especially in my country Colombia), here seems like scrum and agile are the exact same thing. However, what many may do not know is that scrum doesn't always work for every team in every project, and the cases of poor results and failed expectations are more common than you might think, and that is why I want to give my two cents about this topic, and give 3 cases in which in my experience and opinion scrum isn't the best solution.

1. Not everyone in the team is at the same level of expertise

Sure, scrum sounds great with the precision in the designation of the task and the specification of the completion times in each of them, but if everyone isn't at the same level of seniority is really hard that everyone finishes their assignments in time and could cause the firefighter phenomenon, that is when everyone in the team goes to one or two experienced developers, to get some help because they don't have the experience to solve their assignments, and those poor souls that help everyone but themselves at the end, have to work more hours to finish their work. for these kinds of teams is necessary to establish different roles to give support to those members who need help and need to establish their work time by themselves according to their skills.

2. When the project have necessities that can't wait for a whole sprint

I know that sounds crazy but not every project starts as a brand new one, with new code and no needs from the client, some of them are projects where the team needs to give maintenance and new functionalities to the software, and when something is needed by the client with urgency, you can't tell him that he needs to be patient and wait for two weeks to their needs been taken and other two weeks for the release of the functionality, in those cases is necessary to work with another approach or at least that some of the work team is available to respond.

3. When the client isn't in the same scrum boat

I think that this is the hardest to deal with because is completely outside of our control and is hard to identify because many companies lie about how "agile" and "flexible" they are, the reality is that in the agile world you need a client that is available because at the end that's the appeal of scrum, have a product that the client can help to create tailor-made for their necessities, and you don't need the client just for requirements doubts, sometimes you need the collaboration in terms of resources and when they have long and bureaucratic processes to help the scrum team, that can impact in a really huge and negative way to the times established for the tasks.

At the end, I just want to invite everyone to analyze what is the best solution for their projects, and don't use one methodology or technology just because is "the lastest and best new way to do things", sometimes in mixing and examining what serves better your very unique necessities, is where you can find the key of success.

Thank you for reading!

Top comments (0)