Marco Heine_

Blog

Scrum vs. Kanban

Edit this Post Opens in new tab

I know what you’re thinking: Oh, come on! Not another blog post about Scrum vs. Kanban. It’s 2023. Why are we still having this discussion?

The short answer is that this debate will never be settled. Because there is no clear winner, and because of the selfish reason that I wanted to write a blog post about my opinion and experience on this discussion.

A few days ago, I stumbled upon the article “You don’t need a scrum, you just need to do kanban right” Opens in new tab by Lucas F. Costa, which inspired me to re-think and reflect on this and made me want to express my feelings about it. I also looked into the hacker news discussion around it, and it was really interesting to read everyone’s opinions about this topic.

Developers love and hate both, and there seems to be no best framework. We must constantly remind ourselves that it’s just a framework we can use to improve our work processes. It’s not a guarantee for better work results. For a lot of people, Scrum works great. It helped them improve their output as a team. The same goes for Kanban. As I already said: there is no clear winner here.

Disclaimer: This is solemnly my opinion about it, and no scientifically supported report. You can love Scrum, and that is great. You can also use Kanban, and that is great. Or hate both.

Table of Contents

You just need to do Kanban right

As I already said at the beginning, this blog post is inspired by reading “You don’t need a scrum, you just need to do kanban right” by Lucas F. Coast. You should go check out his whole blog post and read it yourself! I won’t cite all the great points the author is making, but I’d like to highlight some of them.

Lucas F. Costa says teams can respond to feedback quicker when preferring Kanban over Scrum because they don’t have to wait for the 2-week sprint cycle to finish.

The focus is shifted to the task instead of to the sprint-sized batch. Developers need to go after the information they need next which increases responsibility, which leads to fewer back-and-forth discussions and fewer decisions necessary, making them more responsive.

Lucas is also saying that estimation meetings are wasted time because they should instead be used to code. I’m not sure I agree with that. Yes, estimation is often a random gamble, but I think it still helps to get a feel for the task and discuss the necessary steps.

What I like about his take on estimations is that instead of focusing on estimations, focusing on getting the task in the system and out is preferable.

He also states that making work visible is no sole advantage of Scrum. The Kanban board works very well for that.

My personal experience with Scrum

I’ve worked in many different teams where we used Scrum heavily. So I’ve had quite some experience with it. Thus please bear in mind that this is my personal experience and, therefore, nothing evidence-based or general opinion. Nevertheless, here are some things that I noticed over and over again when working with Scrum.

  • Scrum always felt like we did it for everyone outside our team but not for ourselves. The time the meetings and organization around Scrum took felt insane to me. I often felt exhausted and unable to think straight after our sprint meetings.
  • There usually were developer deadlocks where a person could not start to work on a new thing because we couldn’t pull it in the sprint. And because our planning didn’t allow it and wouldn’t be finished until our sprint ended with all the steps involved (review etc.).
  • I noticed later that there was no celebration after a sprint ended. We just started immediately again the next day. Maybe there was a quick patting on the back, if any, but then we just jumped into the next planning meeting, and the worry about meeting the next sprint goal started again.
  • Overall it felt stressful to me. We knew early on if the sprint goal was manageable or if we needed to ping our Product Owners to adjust the sprint goal. But this always felt like a loss.
  • Retros felt good, but if you’d zoom out a bit, you’d noticed that we talked about the same points every month again, and solutions were not implemented.
  • I often felt like I just wanted to put out the work, and all the planning and estimation was a hurdle. It wasn’t for me. It was for the stakeholders to sell our work and give others a deadline.

Why I think Scrum can help

I stated a lot of negative points above, but to be clear, I don’t dislike Scrum! On the contrary, I think it has excellent benefits and can help a team flourish.

I think Scrum can help teams who are not well organized. Where communication is not done at its best and where it’s unclear how long specific work takes or what people are working on. It can help these teams take a closer look at those things and work on them.

I’ve worked in several different teams where Scrum significantly boosted our performance and output. The main reason for that was that we had trouble identifying bottlenecks. The communication was not the best, and sometimes we waited too long to ask for help if we were stuck, and we had a hard time estimating how long things took.

Scrum put the magnifying glass on these issues and helped to resolve them. It literally made us more agile. We knew early on when trouble was ahead and could find quick solutions by switching out things and communicating clearly to our stakeholders. It felt like an ever-ongoing buzz, and so much was happening and changing constantly.

Why I prefer Kanban whenever I can

The exact same reasons stated above, which make Scrum helpful, in my opinion, contributed mainly to the fact that I prefer Kanban.

Whenever I was part of a team where we used Scrum, it was hard for me to get into the state of flow, in a state of uninterrupted focus. Scrum felt to me like something was going on all the time. I think that's the definition of agile, but there have to be boundaries. And to me, the boundary of protecting the developer's productivity was often overstepped.

I would say that I am a very good communicator. I let people know about my status, if I'm stuck on something, if I need help, or if something takes longer than expected. I've never had complaints from teammates that they don't know about what I'm up to or that they had to wait for critical information from me.

By being a good communicator and handling things the way I explained above, I gained a lot of trust from people. I appreciate that a lot. The final conclusion for me here is: I don't need a framework like Scrum to do my best work.

So it can feel hard and unnecessary to be put into a framework that doesn't benefit me personally. Don’t get me wrong: often we don't have a choice, and I don't have problems being part of a Scrum team in general. I can adapt and have fun being part of a team that loves to work with Scrum.

As a freelancer I’m used to come into existing team who flourish by using Scrum and I can easily integrate into that. But: If I have the choice and can pick what works best for me, I always pick Kanban.

Kanban works way better for me. The planning part is rougher. When things are done, I'm able to pick the next task, and so on. This suits my work style way better. Because I can focus on the output, delivering the work, and satisfying users and customers. I love to look at a Kanban board, see the progress, make it visible, and be able to publish new features when they’re done and not tied to a two-week cycle.

It gives me more freedom and also more responsibility. In the end, it doesn’t matter what framework we use. We need to know how we work best, what we need to achieve that, and follow the route it takes us. Delivering great web experiences where we help users accomplish their goals is what counts.

Sources

I hope you enjoyed this post and learned something new. If you have any questions, feel free to reach out to me via Email Opens in new tab.

If you want to support me, you can buy me a coffee. I would be very happy about it!

☕ Buy me a coffee ☕

I wish you a wonderful day! Marco