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.