Detailed Notes
This is part one of a short series where we compare Kanban and Scrum. These popular approaches to Agile development have their own strengths and weakneses. While you can combine these two approaches, there is reasons to focus on one or the other. We discuss all of these ideas in this presentation.
This comes from the Develpreneur.com mentor series of presentations.
Transcript Text
thank you [Music] okay so we mentioned way back uh I think it was last year we were looking at some of the topics we wanted to cover in the you know months and and year ahead and one of them that we had somehow glossed over somewhere along the way was talk about Sprint versus Sprints versus kanban and you know in the overarching OR overall agile World there are these different approaches and sometimes people don't realize that recognize that there are differences that they are two different things because the um basically the Sprint Bond combo approach is is definitely not uncommon but even if you look at like a jira or something like that that is a you know that has a an agile Focus to it you can do uh Sprints versus uh kanban boards you can change stuff around a little bit and so you can you can have those two approaches separate even though you know maybe to the uh the uninitiated they may look roughly the same but there are definitely some some differences to the two I wanted to get into that a little bit and talk about it that there are some differences to the approaches and they may one may be much more suitable to what you're doing than others uh particularly because it deals with the you know some of the differences are the types of projects that you're working with the types of uh changes and such you may expect so I'm going to just step back take a step back first and talk a little bit about agile just to you know reset the table there and we'll talk about scrums and Sprints really uh the scrum approach the kanban approach pros and cons for those scrums and Sprints uh pros and cons for kanbans and then you know sort of wrap up and where does it make sense to use one or the other so first off let's talk about some agile or agile it depends on where you're coming from so the agile the agile approach to Software is really starts with the agile Manifesto which is out at agilemanifesto.org and they've got a half or a dozen points of uh how to build software and this is based uh now almost 25 years ago some really uh experienced veteran software uh creators got together and said okay let's take a look at what we've done what have we learned in the last you know a lot of them you know 15 20 30 years of building software and they laid out the it created the agile Manifesto which is really worth looking at if you want to improve your software development in general is just look at some of the things that they recognize that they recommend and I think you'll find you know maybe where there may be some weaknesses or some areas where you can strengthen your approaches and it's I think most people it gets misunderstood because a lot of people outside of or that don't really understand agile are just like oh well agile is just software without we don't document we just like start coding which is a complete wrong way to do stuff and is not at all what the agile Manifesto is about it's not all what agile software development is about the key to Agile is really that first point that they have the highest priority is satisfy the customer and then they say we're going to do that through early and continuous delivery of valuable software which is really the key to Agile is getting something in front of a user that is useful to allow them to get you know make sure you get some feedback it doesn't have to be fully functional but you do want to work towards that so that you can get feedback sooner rather than later and this is something that we could spend an entire you know actually probably do several presentations just on how to do Agile software and how to tackle these dozen points we're not going to do that um just focus on you know certain things you want to keep in mind as we're moving forward talking about uh kanbans and Sprints and scrums is that agile is about is focused on customer and delivery that make sure the customer is happy that they're satisfied and make sure that you deliver software because it doesn't matter how much they like your software if you never give it to them then they're not going to be as happy about it that's like you know if you go order food and like wow this is the best food ever and they never bring it to you then your experience is not going to be pleasant these both agile often it focuses on or one of the key attributes is that we will iterate over as we move towards software development and we will make adjustments as we go we're not going to sit there and try to like get something a hundred percent before we move on we're going to build it out to a certain level and then maybe you know maybe revisit it but uh you know and most importantly if the customer comes back and has feedback we're going to be able to adopt that change in and we will make you know we'll iterate on it or refactor as needed and then agile tends to be more focused on team flexibility and getting things done rather than worrying about um like titles and and Specialties in that and it's it's tends to be more bandwidth Focus it's like who is available on the team that can maybe work on this so that we can keep things moving forward as opposed to having a you know the whatever you know like the QA specialist that sits there and twiddles their thumbs for a month while everybody else is writing code before there's actually something available for the QA specialist to test or a designer that you know designs a bunch of stuff and then just sits around and does nothing for a while because they're they're really their designing is done so those are just some of the highlights of agile to keep in mind as we talk through these so let's talk about scrum first we'll get into that an overview of scrum so what is it well there are really three uh three roles in a in a scrum team there's the product owner the scrum master and the development team the product owner is the one that really drives the features and the priorities they're the one that says hey this needs to do these three things and these are the features that are most important these are the need to halves uh we must have these for this to be a useful product these are the things that'd be nice to have or you know that we want and then these are things like yeah it'd be a bonus it's like icing on the cake nice to haves the scrum Master is sort of like the coach for the team they are uh that person and it's typically a single person an individual is really more focused on helping the team work better and removing obstacles so the team can get their job done the product owner and the development team so they're not really as much a doer as a facilitator or a you know maybe even a little bit of a manager but coach is probably the best term for it because they're they're really helping the team be better do better as a team and then you have the development team that they're the ones that do it they are the implementers they create the software they're the ones that get the things done that the product owner says needs to get done no scrum you have these defined periods of work called Sprints and then there's a certain amount of scope of work that goes into each of those periods so if you've got a you know a two-week Sprint then part of how Sprint definition works is that you say we're going to get these items done and we're going to Target to get these items done during the Sprint and then as you wrap up as you get to end of a Sprint each Sprint you're going to have a review to see how we do you're going to have retrospectives to see how can we do this better and then ideally and it does vary a little bit but more often than not there's some sort of product delivery after each of those Cycles so that's that continuous delivery putting something in front of a customer and saying hey we've got some new features give us your feedback while we keep moving forward that's a sort of how scrum works and again these are uh not again but I guess that mentioned it these are not hard and fast rules overall so you may find situations where teams you know tweak you know whether it's scrum or combo whatever they do they tweak it a little bit and do it a little differently but if you go back to the the three roles and uh some of these things that are a part of scrum you need to have them if you're going to do it right you don't you know it just says hey you need to do like a review but it doesn't really tell you specifically what a review looks like or how it needs to be done it's no kanban which kanban boards have become very uh iconic I guess in software in recent years and so the way kanban works is it is much more about what we see here the you know your workboard and there are stages it's typically just uh like a backlog or to do what are we working on what's you know in progress and then done and it's typically it's you know it's done via these task cards or you know in this case it's just a Post-It note but it could be uh note cards it could be a an electronic or digital form of uh displaying and tracking the data and it's it's really just a way to say here's the things that we need to do and are we working on them are they still to be done are they done and part of the the strength or the key to kanban is that there is a limit to the number of items that you have in the uh that working column the stuff that we are working on there are limits to that you don't just say okay I wrote you know a line I couldn't just throw everything in ideally you're going to have one thing per person you know per team member that you're working on at a time and then you either work it through to completion or if something comes up you basically would back that into the backlog have it in a you know like a paused state so it could be picked up by yourself or someone later and then you you know work on whatever it is that you're working on currently so part of the key to kanban is like we don't shove everything into the in progress we we ideally we pick it up we work on it you know this unit of work we work on it get it done and then we go pick up our next thing and move it from uh backlog to in progress to done there is uh within combine there is a it doesn't use Sprints but there is a an idea of sort of like a lead time or a time to completion where you're looking at how you know how quickly or How likely are we moving through our uh our backlog and if you think of it from a uh like a software support kind of uh metric or aspect it makes a lot of sense where it's stuff that says hey as you know we're getting you know called bug or enhancement reports that come into the queue then basically we're sort of grading ourselves our metric is how fast do we move stuff from in the backlog through to complete but it doesn't have the since it doesn't have the Sprint kind of approach that says okay you know how much do we get done every two weeks instead kanban is much more about how fast do we move items from backlog to complete on an average basis on a regular basis and it's a little different because with Sprints we talk about scrums and this is where we'll talk about differences as we get in these later things but uh in that case I'd mention that you scope out each Sprint kanban you don't have a you don't have that commitment of hey we're going to try to get these things done during the Sprint you just get to the point where it's like hey this thing is ready for us to work on it and then once work starts then that's our commitment it's like hey we're going to work on this thing at this time and whatever else is a backlog you know it may be the next item it may be 10 items down the road you're really more focused on the here and now in kanban as opposed to with scrum you focus in bigger chunks you know whatever that Sprint length is whether it's a week or six weeks you're you're chunking along in scrum versus kanban is much more uh task by task by task and so if you think about it in like inversion control and tagging stuff kanban is going to be more like tagging it per task because you like you know you go create a task and then you can once you're done then you're gonna you know basically merge it back into the code base and you're off and running it's ready to go versus scrum you're gonna have a release where you're piling stuff into a release and then the release gets merged in and then you can move forward typically with kanban it's very straightforward you go left to right you go you know backlog or to do in progress or you know work and then done or complete however you can move stuff uh back to the left so you may move stuff into progress and then kick it back to um to the the backlog you may have like another maybe you have like ready for testing and so maybe moving into ready for testing I've seen this a lot actually it's where it's you know backlog in progress test and then done and it's not uncommon for something moving to test and then there's some feedback on it and then it gets pushed back either to the backlog or to the in progress depending on you know technically I guess it goes to the backlog and then that person may very quickly pick it back up and and work on it [Music]
Transcript Segments
thank you
[Music]
okay so we mentioned way back uh I think
it was last year we were looking at some
of the topics we wanted to cover in the
you know months and and year ahead and
one of them that we had somehow glossed
over somewhere along the way was talk
about Sprint versus Sprints versus
kanban and you know in the overarching
OR overall agile World there are these
different approaches and sometimes
people don't realize that recognize that
there are differences that they are two
different things because the um
basically the Sprint Bond combo approach
is is definitely not uncommon
but even if you look at like a jira or
something like that that is a you know
that has a an agile Focus to it you can
do uh Sprints versus uh kanban boards
you can change stuff around a little bit
and so you can you can have those two
approaches separate even though you know
maybe to the uh the uninitiated they may
look roughly the same but there are
definitely some some differences to the
two
I wanted to get into that a little bit
and talk about it that there are some
differences to the approaches and they
may one may be much more suitable to
what you're doing than others uh
particularly because it deals with the
you know some of the differences are the
types of projects that you're working
with the types of uh changes and such
you may expect
so I'm going to just step back take a
step back first and talk a little bit
about agile just to you know reset the
table there and we'll talk about scrums
and Sprints really uh the scrum approach
the kanban approach pros and cons for
those scrums and Sprints uh pros and
cons for kanbans and then you know sort
of wrap up and where does it make sense
to use one or the other
so first off let's talk about some agile
or agile it depends on where you're
coming from so the agile the agile
approach to Software
is really starts with the agile
Manifesto which is out at
agilemanifesto.org
and they've got a half or a dozen points
of
uh how to build software
and this is based uh now almost 25 years
ago
some really uh experienced veteran
software
uh creators got together and said okay
let's take a look at what we've done
what have we learned in the last you
know a lot of them you know 15 20 30
years of building software
and they laid out the it created the
agile Manifesto
which is really worth looking at if you
want to improve your software
development in general is just look at
some of the things that they recognize
that they recommend and I think you'll
find you know maybe where there may be
some weaknesses or some areas where you
can strengthen your approaches and it's
I think most people it gets
misunderstood
because a lot of people outside of or
that don't really understand agile are
just like oh well agile is just software
without we don't document we just like
start coding
which is a complete wrong way to do
stuff and is not at all what the agile
Manifesto is about it's not all what
agile software development is about
the key to Agile is really
that first point that they have the
highest priority is satisfy the customer
and then they say we're going to do that
through early and continuous delivery of
valuable software which is really the
key to Agile is getting something in
front of a user that is useful to allow
them to get you know make sure you get
some feedback
it doesn't have to be fully functional
but you do want to work towards that so
that you can get feedback sooner rather
than later and this is something that we
could spend an entire you know actually
probably do several presentations just
on
how to do Agile software and how to
tackle these dozen points
we're not going to do that
um just focus on you know certain things
you want to keep in mind as we're moving
forward talking about uh kanbans and
Sprints and scrums is
that
agile is about is focused on customer
and delivery that make sure the customer
is happy that they're satisfied and make
sure that you deliver software because
it doesn't matter how much they like
your software if you never give it to
them then they're not going to be as
happy about it that's like you know if
you go order food and like wow this is
the best food ever and they never bring
it to you then your experience is not
going to be pleasant
these both agile often it focuses on or
one of the key attributes is that we
will iterate over as we move towards
software development and we will make
adjustments as we go we're not going to
sit there and try to like get something
a hundred percent before we move on
we're going to build it out to a certain
level and then maybe you know maybe
revisit it
but uh you know and most importantly if
the customer comes back and has feedback
we're going to be able to adopt that
change in and we will make you know
we'll iterate on it or refactor as
needed
and then
agile tends to be more focused on team
flexibility and getting things done
rather than worrying about
um like titles and and Specialties in
that and it's it's tends to be more
bandwidth Focus it's like who is
available on the team that can maybe
work on this so that we can keep things
moving forward
as opposed to having a you know the
whatever you know like the QA specialist
that sits there and twiddles their
thumbs for a month while everybody else
is writing code before there's actually
something available for the QA
specialist to test or a designer that
you know designs a bunch of stuff and
then just sits around and does nothing
for a while because they're they're
really their designing is done
so those are just some of the highlights
of agile to keep in mind as we talk
through these
so let's talk about scrum first we'll
get into that
an overview of scrum so what is it well
there are really three
uh three roles in a in a scrum team
there's the product owner the scrum
master and the development team
the product owner is the one that really
drives the features and the priorities
they're the one that says hey this needs
to do
these three things and these are the
features that are most important these
are the need to halves uh we must have
these for this to be a useful product
these are the things that'd be nice to
have or you know that we want and then
these are things like yeah it'd be a
bonus it's like icing on the cake nice
to haves
the scrum Master is sort of like the
coach for the team they are uh that
person and it's typically a single
person an individual is really more
focused on helping the team work better
and removing obstacles so the team can
get their job done the product owner and
the development team
so they're not really as much a doer as
a facilitator or a you know maybe even a
little bit of a manager but coach is
probably the best
term for it because they're they're
really helping the team be better do
better as a team
and then you have the development team
that they're the ones that do it they
are the implementers they create the
software they're the ones that get the
things done that the product owner says
needs to get done
no scrum you have these defined periods
of work called Sprints and then there's
a certain amount of scope of work that
goes into each of those periods so if
you've got a you know a two-week Sprint
then part of how
Sprint definition works is that you say
we're going to get these items done and
we're going to Target to get these items
done during the Sprint
and then as you wrap up as you get to
end of a Sprint each Sprint you're going
to have a review to see how we do you're
going to have retrospectives to see how
can we do this better and then ideally
and it does vary a little bit but more
often than not there's some sort of
product delivery after each of those
Cycles so that's that continuous
delivery putting something in front of a
customer and saying hey we've got some
new features give us your feedback while
we keep moving forward
that's a
sort of how scrum works
and again these are uh not again but I
guess that mentioned it these are not
hard and fast rules overall
so you may find situations where teams
you know tweak you know whether it's
scrum or combo whatever they do they
tweak it a little bit and do it a little
differently but if you go back to the
the three roles and uh some of these
things that are a part of scrum you need
to have them if you're going to do it
right you don't you know it just says
hey you need to do like a review but it
doesn't really tell you specifically
what a review looks like or how it needs
to be done
it's no kanban
which kanban boards have become very
uh iconic I guess in software in recent
years
and so the way kanban works is it is
much more about
what we see here the you know your
workboard
and there are stages it's typically just
uh like a backlog or to do
what are we working on what's you know
in progress and then done
and it's typically it's you know it's
done via these task cards or you know in
this case it's just a Post-It note but
it could be uh note cards it could be a
an electronic or digital form of uh
displaying and tracking the data
and it's it's really just a way to say
here's the things that we need to do
and are we working on them are they
still to be done are they done
and
part of the the
strength or the key to kanban is that
there is a limit to the number of items
that you have in the uh that working
column the stuff that we are working on
there are limits to that you don't just
say okay I wrote you know a line I
couldn't just throw everything in
ideally you're going to have one thing
per person you know per team member that
you're working on at a time and then you
either work it through to completion or
if something comes up you basically
would back that into the backlog have it
in a you know like a paused state so it
could be picked up by yourself or
someone later
and then you you know work on whatever
it is that you're working on currently
so part of the key to kanban is like we
don't shove everything into the in
progress we we ideally we pick it up we
work on it you know this unit of work we
work on it get it done and then we go
pick up our next thing and move it from
uh backlog to in progress to done
there is uh within combine there is a
it doesn't use Sprints but there is a an
idea of sort of like a lead time or a
time to completion where
you're looking at how you know how
quickly or How likely are we moving
through our uh our backlog
and if you think of it from
a uh like a software support kind of
uh metric or aspect it makes a lot of
sense where it's stuff that says hey as
you know we're getting you know called
bug or enhancement reports that come
into the queue
then basically we're sort of grading
ourselves our metric is how fast do we
move stuff from in the backlog through
to complete
but it doesn't have the since it doesn't
have the Sprint kind of approach that
says okay you know how much do we get
done every two weeks instead kanban is
much more about how fast do we move
items from backlog to complete on an
average basis on a regular basis
and
it's a little different because with
Sprints we talk about scrums and this is
where we'll talk about differences as we
get in these later things but
uh in that case I'd mention that you
scope out each Sprint kanban you don't
have a you don't have that commitment of
hey we're going to try to get these
things done during the Sprint you just
get to the point where it's like hey
this thing is ready for us to work on it
and then once work starts then that's
our commitment it's like hey we're going
to work on this thing at this time and
whatever else is a backlog you know it
may be the next item it may be 10 items
down the road
you're really more focused on the here
and now in kanban as opposed to with
scrum you focus in bigger chunks you
know whatever that Sprint length is
whether it's a week or six weeks you're
you're chunking along in scrum versus
kanban is much more uh task by task by
task
and so if you think about it in like
inversion control and tagging stuff
kanban is going to be more like tagging
it per task because you like you know
you go create a task and then you can
once you're done then you're gonna you
know basically merge it back into the
code base and you're off and running
it's ready to go versus scrum you're
gonna have a release where you're piling
stuff into a release and then the
release gets merged in and then you can
move forward
typically with kanban it's very
straightforward you go left to right you
go you know backlog or to do in progress
or you know work and then done or
complete however you can move stuff uh
back to the left so you may move stuff
into progress and then kick it back to
um to the the backlog you may have like
another maybe you have like ready for
testing
and so maybe moving into ready for
testing I've seen this a lot actually
it's where it's you know backlog in
progress test
and then done and it's not uncommon for
something moving to test and then
there's some feedback on it and then it
gets pushed back either to the backlog
or to the in progress depending on you
know technically I guess it goes to the
backlog and then that person may very
quickly pick it back up and and work on
it
[Music]