<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.
