<i></i> Welcome to "Winding Down with Product Managers! " Today we're going to discuss Scrum and Kanban. What each of them is, how to apply them in the workplace, the pros and cons of each, and what we use here at Crema.
So stay tuned and thanks for watching! Ok. Tuck.
Talk to me about Kanban. All right. So Kanban actually started as a manufacturing process.
A lean manufacturing process. So an engineer at Toyota. .
. They were trying to figure out how they make their manufacturing process a little bit better and he came up with this methodology or framework. Then, it kind of transitioned.
As software development kind of picked up, people sort of looking at that process and said, "Hey I think this can be applicable to software development. " And so it got picked up by software development and it is a way for you to weigh requests with capacity really easily without any time boxes or anything like that. It's really just an "always - on" board for people to choose tasks from and pick things up and then move them right along the process.
Every Kanban board looks a little bit different but generally the things that you need to get done are on the left. And the things that are done or are blocked from getting done are on the right. What's in-between really depends on the product, depends on your company, depends on what the process might look like.
So usually the most simple form is to do, in progress, done, and then you usually have a column for things that are blocked. And then, as each team member has capacity, they pick one of those to do items up, they work on it, it's done, and it's pretty simple. It's meant to be a pretty lean process.
It's really useful for some projects. Some software development products but it obviously has its cons which we'll get into later. But generally that's kind of how I would describe it.
So awesome. What about Scrum? Talk to us about that.
So what Scrum is, is a little bit more process heavy than what typically you would have for Kanban. Where Kanban isn't really time box, just kind of an ongoing flow of work, Scrum is time boxed. What from what we call sprints.
So sprints are usually time box of anywhere from two weeks to a month. It just depends on what you're trying to do. The team dedicates all of their work within that time box so that way they can be focused during that time.
And then at the end of the Sprint have something that they can show to the client or your team or kind of depends on your setup. But the idea is that you're going to walk away with something that's workable at the end. And so that just really helps kind of plan work out.
So when you use Scrum you use things like story points to track velocity. And what story points are is it's an arbitrary number that the team puts to any individual story or task within sprint. And that scale is very specific to the team.
Some teams use Fibonacci sequence. There is a Scrum sequence but it is very specific to that team. So you can't look at points from one team to the next and compare them because they're calibrated on a team basis.
And what happens is at the end of that sprint, after several sprints, you determine what your velocity is. And let's just use, for example, that your velocity is 40 or team velocity is 40. Well then, you know you can pull in 40 points worth of work every sprint.
And then what's great about that, is you can then project out what your future sprints will look like and then project out when you might be able to release something or a major release. And so Scrum is often more helpful in product development for that reason it allows for a lot more projections of team productivity. Ok very good.
So maybe that TL;DR version is that Kanban is kind of the easy flow of work that comes in and you track. . Maybe.
. . Different piece points of where you are.
Or progress points. And Scrum is a bit more structured allows, maybe, for a bit more forecasting and kind of ability to really time box and understand specific segments of a development process. Yeah you've got it.
Very good. Cool. So Alison, when somebody is trying to figure out what framework they're to use for their projects obviously as PMs we like to know our pros and cons of each thing that we're going to do.
And so can you maybe list out some pros and cons of the Kanban framework and why somebody might want to use it and maybe why they wouldn't want to use it? Yeah sure, absolutely! For a positive aspect of it really Kanban allows you and your team to pick up work as your capacity will allow.
Basically what that means is that if you've got you know, four or five members on your team and two of those members are finished with their work, they're not really boxed into not picking anything additional up. They can move on to the next task without having to have meetings or major discussions with anyone. Pretty much a simple and easy flow influx of work.
Another positive aspect of it is that it's really less process. It's a lot more flexible. So you'll notice that's really the major differentiator between Kanban and Scrum is process.
Let's process, Kanban. More process, Scrum. Another pro is it's really great for teams with many requests.
So what we mean by that is many requests from many different stakeholders, potentially. So you could have internal requests from your own organization or users of the product or maybe even requests that you have. And at times it can be really difficult to prioritize all the different requests that you have coming in.
So Kanban allows you to easily keep a backlog or a list of items that you can jump right into when capacity allows. Like any other system or or idea, there's always going to be parts and pieces that aren't the best. So let's go ahead and kind of dive into those.
It can be harder to plan out some of these larger release initiatives. What I mean by that is it doesn't really give you the ability to forecast like Scrum does. Scrum allows you to point like Tuck mentioned previously.
Kanban doesn't have that aspect tied to it by default. It also can cause poor productivity. So if you aren't necessarily time boxed in, if you don't have a list of tasks that you need to get done during a certain piece of time, it might mean that you feel a bit more lax or less motivated to dive in and knock out tasks.
I know that there are times when, if I don't have a time frame around me, I'm like I don't want to do it you know like seize the day right. So you always have to have that consideration in mind and specifically the team that's working on it as well. Last but not least is it can be difficult to manage the different priorities.
So we talked about how a positive aspect of this is that you have a lot of priorities coming in and it gives you an easy way to kind of nest those in and push them through your pipeline at work, but it doesn't necessarily give you the tools that you need to prioritize those items against one another. You have to have a very dedicated team or educated members of that team and educated on their feature requests or different requests that they have. in your incoming list to lean into that.
So again it's going to kind of fall back on the team to make sure that that's not a negative component that you have to experience with Kanban So Tuck. Talk to us about the pros and cons of Scrum now that we've gone through the Kanban aspects. Of course!
Obviously, there's pros and cons with each of these frameworks. Alison mentioned earlier with Scrum. Of course that's no exception.
So some of the pros with Scrum is that it creates accountability. When you set up a sprint your entire team is agreeing on to a sprint goal. They're saying by the end of the sprint this is what we're going to achieve and everybody's aligned with that goal.
That means that everybody on the team is going to do everything they can to make sure that we meet that goal. If we don't, it's kind of everybody's failure versus any individual person's failure. The next one is that there's a clear definition of what results are.
So Crema, being results based culture, that's very important to us because if what defines results isn't clear then it's hard to know when you can be taking off when you can be working remote when you can be you're taking off early any given day or coming in late in a given day. But it's clear that OK this is my sprint goal. These are what my results are that I need to meet.
It's much easier to do that. The next one is that it allows for a lot more accommodation when it comes to changing plans. So especially in our business priorities change all the time especially when you're building a product when those plans do change.
You need to be able to quickly pivot and go to that. And so what Scrum allows is that. You don't want to really have to break a sprint that you're in, but it does give you room that after that sprints over then you can pull in a whole new set of priorities that has a completely different Sprint goal than your last one.
And their team gets realigned around that really really quickly. So Scrum does allow for planning of larger initiatives especially when it comes to release planning. And so, since you are able to track what the velocity is for your team, it does allow for the forecasting out.
You know that if your team always is able to accomplish 40 story points every sprint, then you're able to say OK if our backlog is X amount points big then it's going to take us X amount of time to get through all those points. And so just allows for that a little better. And then another pro for Scrum honestly is that it uses, at least in our opinion, it allows for better use of time and money since you are able to kind of focus on those priorities.
You make sure that after each put you're delivering something of value to the business. You're not kind of spinning your wheels on these new requests that are coming in that have been really truly vetted in any way shape or form and just got kind of picked up on accident or something. Some cons, though, when it comes to Scrum is that it can lead to a scope creep if there's no kind of end date that the team is aligned on since priorities do shift.
That does mean all of a sudden some stakeholders thought you were going to do this huge release in a month and then along the way other priorities have crept in and kind of messed that up. Now it's up to the PMs, the product managers, to really be communicating that along the way so that there is no surprise to stakeholders. But it still happens.
It can happen if you don't keep a close eye on it. So if you are using Scrum you to make sure that your communication is top notch. Also another con of Scrum is that it can be harder to manage in larger teams.
So Kanban works really well if you don't have your team separated out into agile teams or Scrum teams because, you know, anybody from that team can be picking it up. When it comes to Scrum, you want to keep your team smaller because having that kind of goal on that team goal if it's spread out among 20 people there's not as much accountability. It leaves room for people to kind of be dropping the ball a lot more or kind of not providing their full amount of attention to the sprint.
Another con of Scrum is that any changes in your team structure can really mess up the velocity. So if you have a new developer come on board, another developer fall off the team, that can really change up the velocity that developer obviously needs to get ramped up on the project, or even if it's an additional developer it's going to change things a little bit. And so that can mess with your predictions.
You can make some pretty good assumptions on what the velocity will look like, but it changes based on what the team dynamic looks like. Any changes in that team can really mess up the Scrum process. One of the other cons is that it requires team buy in which in turn can cause frustrations if the full team is not aligned with that approach.
So if for whatever reason there's a team member that is just maybe not a good culture fit or they completely disagree with the work that you're doing, if they don't have that by meeting those team goals or those sprints, it's going to be really really hard and cause a lot of frustration amongst the team. And then another thing is that when it comes to Scrum, velocity can be easily skewed depending on other product variables that are out of your control. So that could be that maybe you're dependent on an API that is completely out of your control and you keep getting blocked by that can largely change and affect your velocity metric and really affect kind of your planning forward.
And so that's just something to keep an eye on and where you kind of see some of these combined processes we'll talk about that a little bit. So one of the great things about Scrum and Kanban is that they are frameworks. Frameworks are inherently flexible.
They are really meant to kind of mould to what your team needs are, what your client needs are, what your product needs are, and what's really great is you can find a combination of both. Both of the different frameworks we just talked about. And so Alison, what are some methods maybe that you've used in some of your projects that have been really helpful to your team?
Sure! This is probably my favorite topic of this whole discussion because I think that this is really the realistic implementation that a lot of us are doing these days. I feel like it's fairly rare for people to be strict Scrun or strict Kanban because it's so easy to kind of mesh and mold and a lot of times it's for the benefit.
So an example might be, that let's say that we're running a design sprint or prototyping a design engagement and we want to run it with Kanban because that's going to be the be in the best interests of the team and the product. But also, maybe our team needs daily stand ups. And that, inherently, is a Scrum meeting.
I don't think that, you know, for the sake of just staying in one, you know, Scrum versus Kanban it's worth excluding that really valuable meeting point for your team to engage and grow. So that could be a way that you're merging these two sort of implementations and agile and in which you're running Kanban. So you're pulling in aspects of Scrum to to make the process run better.
And then inevitably build a better product with your team. Yeah I agree. I think the big important thing to remember is that no matter what process you use, no matter what, what really matters at the end of the day is that your team has the best environment to really do their best work.
And so you shouldn't let any kind of process ever get in the way of that. There are some organizations that, you know, they're only doing it by the book but I would argue to say that. Those teams could probably be even more productive if they combined some kind of methods there.
I know at Crema, you know, every engagement that comes through our door our product management team analyzes and says "OK what do we think is the best process for this? " And oftentimes it is a combined solution. I think for the most part, from a product development standpoint, I lean more towards Scrum because of the framework and because of the different things that that provides our team.
But at the end of the day, you know, a lot of times -- not a lot of times but sometimes, we will run out of work in a sprint. We will maybe underestimate or overestimate some things. And when that happens the team knows that they can just go ahead and pull things into the Sprint that are at the top of the backlog right.
And that's kind of like a Kanban style anyway. I'm not I'm not going to be the gatekeeper of that and be like "No we're not going to do anything for three days. " That doesn't make any sense, right?
We still need to meet the goals. Maybe then don't get those tasks done by the end of the sprint, but at least we're utilizing the team to the fullest. I agree.
Another. Really good call out of like implementing or kind of merging methodologies is that it gives you a chance of teaching. So in the use case that you just described and that that's very applicable to, most PMs that I've met, you know, we ran across a situation where we finished all the items on our board.
And at that point if, you know, we need to pull something else in we should be able to. But we should also have that opportunity to educate the team on, "Hey, in true Scrum like this is what in theory we would typically do, I think, but you know, in this case it makes more sense to do this. " And I think it's a really important aspect of our job is to educate in the different circumstances where exceptions or merging can be made.
I find it as a really like inspiring and wonderful moment when we get to kind of merge and change our methods of implementation because not only does it help the product go smoother, it adheres and molds to what the team needs, but it gives you a chance to educate your team and grow together. And your client too. Yeah, I think that's an important aspect of this too is that it helps us grow our client relationships because they realize like "Oh you guys aren't just kind of sticking to doing it one way you're kind of doing it however we need to do it.
". Because it's not just how our team works. We consider our clients part of the team too.
So it kind of needs to also accommodate any of their needs. If their business requires us to tackle high priority bugs that come in and that's a priority for the business, then that's going to change the process a little bit. It means that a portion of our sprint every sprint will maybe be broken because we need to add new bugs and then that's going to prioritize the other work.
That wouldn't be what a normal recommendation I would make, but if that's what the client's business needs we're going to accommodate that. I mean it really just helps us that they meet the best results for both the client and their product. Absolutely.
Let us know what you think about all this. You know, Kanban, Scrum. The the middle ground option.
Like this, comment, let us know what you want us to dive into deeper, because this is really just scraping the top of the barrel.
