Scrum vs. Kanban

Welcome everyone to another episode of the Product Bakery. Today I'm streaming here from my office. Beautiful day in Berlin. And yeah, it's just me and Christian today. Hi, Christian. Hey, Alex. A lot of sun that you have ordered to Berlin. Yeah, only for us. Luckily, I can enjoy it while sitting on my desk and talking to you. Same here, Alex. I've prepared a topic today, as many of you reached out in some emails asking for it. But before we jump to it, I just want to, as usual, highlight that you can find all the episodes with some episode minutes on our website, product-bakery.com slash episodes, as well as some additional information on our social media channels. So make sure to follow us on whatever channel you prefer. And if you have any questions, if you want us to talk about a specific topic, if you have some good speakers in your network, feel free to drop us a message or use the comment function on our website. And with that, Christian, how's your day? Sunny as yours. And one thing I want to add is that you can also share the episode with your friends and your network. But only if you want. Only if you want. But if you have listened to at least five episodes, you have to. Yes, that's our pricing. And the conditions for it. Cool. So Christian, the topic that I prepared today or that I wanted to discuss with you is something where you can probably talk more about it than myself. So I would be the one trying to represent the questions of the audience. But just like to share a little bit more right up front, it will be a lot around Scrum and Kanban. And I think those two words or those two frameworks, we can start with this. What is it? What is Scrum and what is Kanban, actually? These are Agile frameworks. Perfect. And you already mentioned. Hashtag Agile. Exactly. You're bringing in the main keyword, Agile, right? So whenever we talk about Agile, it's impossible to not talk about Scrum and Kanban. And I think sometimes there's also a little bit like the misperception of what is Agile? Is Scrum Agile? Is Kanban Agile? What's more to it than just those frameworks to be Agile? So that's what I will leave you with for the start. I would say Agile is the mindset and the Agile frameworks help you to execute and structure your mindset and get to what you want. Very good. Let's talk maybe about the main differences also between the two frameworks, right? When would I use which one? Yeah. So the number one thing we should talk about is first of all, that there is no silver bullet, right? Because many people say, okay, I want to be Agile, so I have to do Scrum. Or I want to be fast and I don't want to plan, so I do Kanban. And this is not the way it works. So we need to, first of all, understand that you need to ask yourself, what do you want to achieve? Before we talk about being Agile, because there are also other frameworks, right? There is like safe, there is less, there is that. I don't know what exists out there these days. A lot of hipster stuff maybe and newly invented things. But overall, you need to ask yourself, what is the best working style that I can approach and how do I plan? And this is how it started. And if you are going to change your roadmap every two days, you're not Agile at all. And no framework on this planet can help you. So what should I be doing to be Agile? First of all, don't change the plan all the time. But isn't that the age, like, isn't it lean to actually have the freedom to change a couple of times? Yes, the freedom to change is definitely, it's definitely sensible, but you also need to understand what you're doing and why you're doing things. Especially you as product discovery expert, you know how important it is to regularly plan upfront. And first of all, understand what problems you want to solve. And if you have that in place, you very likely don't need to change that often the plan. For sure, when you realize we have built something and it doesn't work out, we need to go into a new direction. But that doesn't mean that once you have started a sprint, two days after you're going to completely change the sprint goal. It sounds very, it sounds very basic. And I can imagine that many people might say, yeah, that's what you read in books, but look around and see how often people are not following it. Either you are strict with it and you say, okay, I commit, or we as a team commit to a two week cycle and promise to ship something by the end of this two weeks to production or to master, however you work. That depends on your definition of done, then go for it. If you feel like you have everyday new challenges, you should ask yourself, does the domain that you have defined work out? Is the team set up correctly? And more questions that should be looked at first before you think about the framework. Yeah. And I'm coming back also to what you mentioned earlier. If I have a problem defined and if it's, there is a solution that doesn't work, I'm not going to change the problem that I'm trying to solve. It also comes down to this. So it depends a little bit like on, on how you plan and what you plan for. Well said, absolutely. And then when we talk about the difference between Scrum and Kanban, we should look at what the purposes of those frameworks are. So Scrum is about commitment. It's about working in iteration and committing to little pieces of things that you want to chip within this cycles, which are mainly two weeks, but people also work with one week or three weeks prints. But I made my best experiences with a two week cycles. And then there's Kanban. And Kanban is more made for continuous delivery. So it's the notion of continuous improvement. You as a team, you sit down regularly and try to unblock yourself, improve processes, make your life easier and guarantee a continued flow of things. So what you want to have is a throughput, continuous throughput. With Scrum, you want to have a continuous velocity and the velocity is based on a certain timeframe. While the endless way of working in Kanban is throughput. And at the end, after a certain period where you look at it, you will see the output that teams have produced in both frameworks. And that's something where people sometimes also mix up the terminology. And is there, when we talk about like throughput and velocity, what's better to look at? That depends on how you work. Let's say we want to build a feature and you can build a feature with Scrum and you can build a feature with Kanban. But what you need to understand is, and that's something that many times people assume wrong is once you have a velocity, that doesn't mean that you have an ETA. So a velocity gives you an understanding of what a team can achieve. But the biggest problem is that then leaders come around and try to put a date on something. And that doesn't work like that. So that's number one. And number two is in Scrum, you estimate tickets based on four factors, which is work effort, overall complexity, risk, and deployment. So you look at these four things, and this will be then breaking down into certain story points based on the simplified Fibonacci scale. When you do Kanban, you usually don't estimate, which means you are more looking on the ticket throughput. So how many tickets have we finished? You look at the issue count instead. There are complete two different types of working. However, an HR framework or the way of measuring performance and team collaboration is not made to put a stamp on it and say, that's the ETA, because there's always a certain level of risk. What we want to do is we want to break down the work and continuously move toward the finish line until we have built the product. The idea is not to say, okay, we do Scrum and now we have an ETA and now we have an ETA because we can estimate. But now that's probably a stupid question, but if I think about throughputs, right, and if you look at Kanban specifically, and we would say, okay, how much or how many tickets can we actually put through or can we actually work on or can we actually deliver? It's the right word. How many tickets can we actually deliver? It also comes down to the ticket size, right? I could have a feature or tickets where I need multiple weeks and this would massively affect the throughput that I have. And at the same time, I could optimize purely for throughput in terms of scoping or slicing my tickets in a way that I can ship five a day, maybe. Exactly. And that's why you need to spend some time on breaking them down. And that's also agility versus waterfall. In waterfall, you have, let's say, one big epic, one huge user story where you say, build it. And in Agile or in Agile frameworks, you sit down and you think, okay, how can we slice that in certain pieces that make sense from a technical point of view, but mainly also from a user perspective. And for sure, you cannot always in very complex environments focus only on the user, but then you can focus on system users, for example. So making sure that you break it down. And that's actually the main difference that people underestimate. Sometimes people just blindly start picking one of those and say, okay, it's easier to get started with Scrum or it's easier to start with Kanban. And what I'm always saying, and that's also something that my coaches taught me back then when I was working as a product manager is they are both super hard to learn and to do. Both require a lot of discipline. But maybe one thing that could be very helpful for everyone to listen to is like, how do I actually pick if I should go for Scrum or if I should go for Kanban? That's not an easy to answer question, but I would say, generally, if you are working on features or on a product that you want to build and you want to slowly break it down and you want to break it down into smaller pieces and ship regularly, I would recommend starting with Scrum. The good thing with Scrum is also that you can plan in iterations, in releases. So you have a more guided technique or framework with certain ceremonies, et cetera, that help you to be a little bit more streamlined at the beginning. So Kanban for sure has also its benefits, but I think it's usually more for more senior people, also for engineers who can organize themselves better and make sure they have a good communication going on, limit work in progress, et cetera. So that requires also a little bit of maturity. So Scrum is always a good start if you follow the rules. And following the rules doesn't mean that you do it exactly like it's written in the books, but a backlog grooming should, even with Kanban, regularly happen. Sitting down with your team and discussing what's coming up next and what the value behind is. Sprint planning is important to have a good understanding of what you want to build in the next iteration, right? A retrospective also for Kanban is super crucial to take a look at what you have done in the last weeks on the last period and what you can improve next time. So what you're saying is generally for especially not so experienced people, we would recommend them to start out with Scrum, really get also a good understanding of how the two different frameworks work. And additionally, like really get also familiar with all the different steps, practicing them. But then again, like if we follow the age of manifesto, people over processes, right? We should not just like blindly follow them. Exactly. And one important thing that I believe is very helpful for both frameworks is sit down as a team and define your definition of ready and your definition of done. So what needs to be in place that you can say as a team, Hey, this ticket is ready for development. So we want to pull it because we have answered all questions except criteria in place, test plan is in place, design is in place. So that's important to have. And then also knowing when is the feature done? So at which stage do we say it's done? Who needs to approve it? How many tests should have been added to the ticket, et cetera. So these are questions I recommend taking a look at. Perfect. Then I think that's at least like a good starting point and a good overview for everyone who needs to decide which framework to pick or who want to know more about what Agile and Scrum and Kanban is. If you have more questions, feel free to drop them in the comments or send us an email. We're happy to deep dive on the topics a little bit more. And other than that, Christian, thanks a lot. Thanks, Alex.