Some time ago, I have attended a course and became a certified scrum master. It wasn’t a huge deal. I was already a scrum master for my team. I moved on. In time, I have gone through different experiences and the way I saw the agile frameworks changed. I have started applying slimmer approaches. At the same time, I started evaluating agile frameworks and I realized there were some downsides. In this post, I’d like to list some of the problems with agile frameworks.
- Estimates!!! How do we even define it? In days, hours, complexity and some other weird measurement type. Estimates are just controversial. From my own experience, I know that estimates never work. It’s impossible to estimate something that is being built for the first time. We never build the same feature twice. Even if you build software twice, it still won’t be the same because you learned the unknowns. Also, even if you are good at estimates, there can be distractions and blockers.
- Standups! Often times, you might realize you don’t really care about the other person’s project. On the contrary, if you care about someone’s project, you might already know the status since you are interested in that project. So, having standups might be a total loss of time. This becomes a bigger burden when you have a remote team in different time zones.
- Product owners hinder engineers contribution to the product because they decide on most of the critical parts and leave little room for engineers. Note that some of the great products we use today are actually engineering
– driven products. - For each sprint, engineers are asked to deliver certain tasks and business people keep asking more and more from engineers. Constant pressure restricts freedom of engineers and doesn’t give any room to any innovation. Nevertheless, some of the good projects are done when the engineers are free and have time to do some side projects.
- Timeboxing everything creates technical debt in the long term. It isn’t just one task but one after another. Each creating a new technical debt because there’s no time to do a refactor since we need to deliver fast.
- Agile frameworks are management focused. The management gets some sort of predictability, they learn about their engineers and they get a better opportunity about micro-managing.
- Frameworks assume every engineer work the same way. Teams do the planning together and assign an estimate to a task as a team. Nevertheless, the person who gets the task might struggle to do on time. Maybe, he’s a new member in the team, or, perhaps he doesn’t have the experience in that particular area. Since he’s supposed to deliver on time, he’ll be under pressure and stress.
- There’s literally bureaucracy in agile software development. In order to get anything done, you create a task, you add it to the sprint backlog, then you evaluate it and decide whether you should do it or not. Some teams even go far beyond and ask for a ticket for changing a label on a button.
- Frameworks bring unnecessary complexity. Although developers might not see, the frameworks are actually complex. We don’t see the complexity because we actually learned it. Think about it. On one hand, you have roles like scrum master, product owner, even facilitator. On the other hand, you have new processes, new terminology and etc. If this was so simple, why do we have a ton of courses or training on the subject?
- One of the biggest shortcomings of agile frameworks is about dealing with dependencies. Imagine you depend on another team to build a feature and they don’t even apply the agile framework, how do you even estimate against that. Or, you expected the database to be set up for your team and it wasn’t delivered on time.
- Frameworks reject catastrophes. Imagine everything was awesome for the week and you got paged for a catastrophic error. How do you prepare against that, how do you take such problems into account? How do you log it?
- Some of the methodologies work great in theory but there’s no way to actually tell that this is the best way to do it. Although you can measure, the measurements you have are compatible with the agile frameworks. So, the outcome will be somewhat expected. Well, you can argue about teams that successfully adopted it but there are a ton of people who failed to do so as well. If you google it, you’ll be surprised how many articles you would see to prevent failing.
- A great team may not need agile frameworks. Would it really matter what sort of methodology you use when you follow agile principles? Maybe, all success cases for agile frameworks were successful because the team was expected to be successful anyway?
All in all, I think there are many reasons, why agile frameworks aren’t good enough. They create a new level of complexity with a limited benefit. We, as engineers, have been through some of these problems and maybe suffered from agile frameworks. Perhaps, it’s time for a change!