Detailed Notes
This is part two 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] so that's you know scrum and kanban so now let's as we've laid this out what are some of the talk about some of the pros for scrum like what are the reasons that we the strengths of it one of the ways and we're going to see this with a little bit both of them is it's flexible the way Sprints work is it allows you to sort of Zig and zag your way through a product a project or a product development so you can focus and it is feels more a little more Ziggy zaggy where it's like you're going to do a burst you're going to do this Sprint in a direction which that direction being whatever your scope is for that for that Sprint and you may so it may be like this Sprint we're going to focus on uh front end stuff and so you're going to do a lot of front end work for this Sprint and then you may zag back and say oh now this next Sprint we need to catch up but we've got to do a lot of middle tier stuff or we're going to do some back end stuff or we're going to focus on I don't know like user registration feature here but then this other Sprint we're going to focus on reports so if you think about it you're you're sort of you know taking these Sprints in a short period of time in a short Direction and you're really focused more or less because there's going to be a theme to each Sprint so as those themes are developed you're working your way towards the Complete product by shooting ahead on each of these themes until you get to completion one of the benefits of it is it allows you to take big projects and split it into smaller pieces so if it was going to take you a year to get the project done instead of just having a Year's worth of tasks and trying to figure out how we're going to get those done you have these smaller bite-sized Sprints where you can say oh okay well we've got you know a Year's worth of stuff but now we're going to sort of group some of these things and we're going to tackle groups of tasks Sprints are great for um like face-to-face time and uh the Sprint Cycles are they're awesome for feedback you have daily meetings I haven't mentioned before which you have these daily stand-ups where you you have a brief meeting every day which allows feedback amongst the team but also each Sprint cycle each complete Sprint you have times where you're getting you're really presenting in and eliciting feedback from your customers but then you also have stuff as a team where you're giving feedback to each other how did we do how can we do this better how can we make Improvement so there's a lot of feedback that is built into how Sprints work there's some clarity there too there's that makes it in a sense a very simple structure because you have the roles you're either you're a product owner you're a scrum Master you're part of the dev team and it's basically like you're either you know driving the product as product owner either coaching the team as a scrum master or you are getting things done if you're the development team and so that makes it you know pretty easy to know where you fit and scrum is is Sprints and scrums are very popular there is a lot of information and content out there in the forms of books and websites and podcasts and YouTube channels and all kinds however you consume content there is a lot of it out there to help you uh whether you're just getting started or whether you're you're wanting to take your you know scrum Sprint to a whole new level there's a lot of stuff out there so it's a really big community and they they tend to be pretty good about uh welcoming others in and trying to help everybody get better doing it so I after all that what are some of the cons you know what are some of the downsides to scrums and sprints well one all of that and go back and we talked about all of that feedback uh it also equates to there's a lot of meetings there's these stand-ups every day there's reviews there's retrospectives sometimes depending on how you you know how they're run and stuff like that they can just you like feel like you're spending your life in meetings um along those same lines it is not easy it is difficult to understand and really Embrace how scrum the scrum approach works because it's in some ways a very simple structure there is a lot that it puts back on the team members to be uh to own essentially their you know their role and what they want to do and to own the fact that they are part of this team and they they have a role in um making it successful and that could be difficult and it it can be especially if you're not a you know if you're not really a self-starter if you're somebody likes a lot of structure and a lot of Direction it can make very difficult for you to step into a scrum environment uh workflow because of the way Sprints are configured and the way you you Scope stuff in um the way you you do that zigging and zagging then sometimes that can be too rigid um particularly if you think of like if you're software support if you're dealing with bugs and stuff like that that you know customers report bugs if you have a one month Sprint cycle then the fastest they're going to get an answer back is a month and sometimes that's that's not going to work so sometimes with Sprints your workflow can be sometimes too rigid for what you really need to do to to make your customers happy it's not often mentioned that I've seen but a really good point is that there is burnout that can come because typically what happens with Sprints is you just go from one Sprint into the next Sprint into the next Sprint into the next Sprint and while companies have figured out that like they're doing a Sprint over uh you know the Christmas New Year holiday stuff that you know that December holiday period usually they're not even going to bother with a Sprint because so many people are out uh you may have that as well if you're you know maybe if you're in Europe or somewhere where they have you know like typically like in August where everybody's off for a week or two then you just sort of say okay we're gonna pause and we're not even going to be working on a Sprint during this time because we know most the people will be unavailable you may have uh annual conferences or something like that where most of people are not available in some cases that's perfect people love it but typically what happens is if you don't have some breaks in there you know maybe you go a couple Sprints hard and then you take a couple days off or something like that there are just other bits of work that don't get done because they're not the things that you typically would need to do but they're not part of a Sprint so it's it's sort of not on your radar until it becomes an issue and that can be a problem so having a little bit of time to say okay you know you're not working on Sprint work today you're just catching up on other job related stuff you know you just go that route and finally uh flexibility really along with that workflow is that sometimes Sprint Cycles can take too long and that zigging and zagging needs to be broken up even you know to a smaller level oops so the pros of kanban talked about Sprints and scrum so let's go back and talk about kanban boards so visibility is a huge Plus for that because you can look if you call the bacteria your kanban board you can see that and boom you know where you're at you have at a you know visually very quickly you can understand where you're at and what the work is now within those now sometimes those notes are very you know those Post-its uh have very little information on them but the idea is that you know typically what you need to know you can put on one posted or one card and then you're off and running it's flex flexible uh because you can you know choose your item you're working on and then you know work it through to completion or flip it back to the backlog and because you're not in a time frame where you're you know with that Sprint structure then it's just like you come in you work on something you get it done and if you do it you know the best ways to get those things done or where you come in you work on it if you're not you know if you're going home for the day or off for a week and you're not able to work on it you put it back into the backlog and have it in a situation where somebody else can pick it up and and run with it as needed so you don't have those you know those time frames so it makes it much more flexible uh it's much more granular to do kanban which is the next point it's easier to allocate work without overloading a member everybody's working on something at a given time ideally and they're not you know they're working on an item that's that's in progress they're not working on 10 items they don't have a whole bunch of stuff sitting in their queue that says here's all this stuff you're doing it's you're doing whatever it is you're doing today versus Sprints sometimes there's this there's a tendency even though it's not recommended where people will go into a Sprint they'll assign a lot of the stuff of the workout at the beginning of the Sprint and so you may have somebody that's it gets all their work done early and they're basically sitting there twiddling their fingers while you know somebody else is overloaded and is working you know 80 hour weeks to crank their way through that Sprint kanban boards are going to require less meetings because it's basically just look at the board yeah you don't you don't have to spend a lot of time meeting about it you can you know you may talk about tasks and stuff like that but definitely the meetings disappear or you know you have far fewer because you're not doing that regular all of those pieces that are part of each Sprint you may still do some of those things so you may do reviews you may do retrospectives and things like that but they are not um they're not doing they're not done maybe necessarily as often and definitely not tied to time frames like uh Sprints are and if there's a the ability to focus if you don't have 10 things on your to-do list particularly if you don't have multiple things that you're somewhat working on and instead you're working on an item and take it to completion and then move on to your next task that allows you to focus so you're not stuck in something where you're you know having to bounce back and forth between a couple of different things or different environments things like that it's just like go work on it get it done you're off and running much like as we've talked about in the past what do you think about the Pomodoro approach as you you know Focus for a you know you're in in this case it's not for you know that time period but it's Focus until you get it done and then when you come back to it when you're ready to do some more work pick up your next task and and do that and so that also allows you you know instead of that zigging and zagging and sort of being a little bit locked in a direction for a while it allows you to go to work for a while get something done if you have something else to take care of take care of that and then you can come back and you can work on whatever the next ticket is so the cons to that the downsides to combine it lacks structure because you have this very minimal structure it there's it's going to be lacking you know you basically you've got your your backlog you're doing it and you're done and sometimes that can be now you can add more steps but typically it is it's just you go grab something to work on you work on it till you're done and then you move on to the next one so you you have to be much more intentional to make sure that you include pieces like reviews and retrospectives there are um The Specialist approach to software that is sort of a legacy approach in a sense um is kanban is not as useful for teams where they've got uh like diverse silos so if you've got like a like a front-end person you've got a middle tier person you've got a back-end person you've got a testing person you've got a design person you've got a user experience person when you have people that really only have certain you know if you think of that backlog if really there's only you know one or a very limited number of people that can do any of those tasks then it's it's not as useful because those people are going to have to pick the tasks that they can do if you've got a team that has a broader set of skills then you're going to be able to you know where each member has a broader set of skills then you can have any member can take any ticket essentially and that would be that's the ideal approach to kanban is that any one of your development team can pick up one of those things to be done and do it that is where kanban really uh is Gonna Shine and if you don't have that the further you get away from that the further cross training and cross-skill set you have in your team the less useful combat is going to be updating can be a pain as I said one of the ideas is that you can go work on something and then pause essentially and put it back into the backlog for whatever reason and doing so and making sure that that documentation or that your situation is frozen properly that somebody else can pick it up can be challenging it really does have to be like a habit of the members of the team to make sure that they properly you know like commit stuff they use good comments they do updates if there's you know changes to the the scope or the requirements on a card that they get those things documented um it doesn't have to be like complex and you know full requirements documents each time but you do have to keep stuff up to date otherwise it comes really confusing really fast there is a a limited size as well to what a a single kanban board is useful for if you think about it and go back to this example you know if you go here you know there's I don't know 15 maybe 20 items in your to-do and you know about the same in your work and you're done done doesn't really matter but you're to do if it gets huge um you know if you've got if like I mentioned before like if you lay out all of your kanban tasks for the next year and particularly if you think about like a combine card typically you probably you know it varies but you typically you're going to be able to knock out on average you know maybe you know one to four tickets a day you got a team of 10 people that's you know 10 to 40 tickets a day and you do that over a year that pretty quickly runs up to you know a thousand cards sitting there which is just overwhelming uh now a lot of times what happens even if it's digital even it's electronic it could get overwhelming and a lot of times where Sprints will sort of will sort of group that stuff during a time period whatever Sprint is sometimes you'll have different kanban boards to have multiple boards that will be uh you know maybe breaking out feature sets within the application or there's a lot of different ways that they can that those can be done to sort of shrink that down you know it's one of those it's just it can be daunting to see a thousand items out there and then to find the right one you know to go say okay what am I going to do maybe you just pick at random but maybe there's certain things that you're better at and it takes a while to sort through or to review what's out there to pick what you're going to work on next [Music]
Transcript Segments
thank you
[Music]
so that's you know scrum and kanban so
now let's as we've laid this out what
are some of the talk about some of the
pros for scrum like what are the reasons
that we the strengths of it
one of the ways and we're going to see
this with a little bit both of them is
it's flexible
the way Sprints work is it allows you to
sort of Zig and zag your way through a
product a project or a product
development so you can
focus and it is feels more a little more
Ziggy zaggy where it's like you're going
to do a burst you're going to do this
Sprint in a direction which that
direction being whatever your scope is
for that for that Sprint
and you may so it may be like this
Sprint we're going to focus on
uh front end stuff and so you're going
to do a lot of front end work for this
Sprint and then you may zag back and say
oh now this next Sprint we need to catch
up but we've got to do a lot of middle
tier stuff or we're going to do some
back end stuff or we're going to focus
on I don't know like user registration
feature here but then this other Sprint
we're going to focus on reports so if
you think about it you're you're sort of
you know taking these
Sprints in a short period of time in a
short Direction and you're really
focused more or less because there's
going to be a theme to each Sprint so as
those themes are developed you're
working your way towards the Complete
product by
shooting ahead on each of these themes
until you get to completion
one of the benefits of it is it allows
you to take big projects and split it
into smaller pieces so if it was going
to take you a year to get the project
done instead of just
having a Year's worth of tasks and
trying to figure out how we're going to
get those done
you have these smaller bite-sized
Sprints where you can say oh okay well
we've got you know a Year's worth of
stuff but now we're going to sort of
group some of these things and we're
going to tackle groups of tasks
Sprints are great for
um
like face-to-face time and uh the Sprint
Cycles are they're awesome for feedback
you have daily meetings I haven't
mentioned before which you have these
daily stand-ups where you you have a
brief meeting every day which allows
feedback amongst the team
but also each Sprint cycle each complete
Sprint
you have times where you're getting
you're really
presenting in and eliciting feedback
from your customers but then you also
have stuff as a team where you're giving
feedback to each other how did we do how
can we do this better how can we make
Improvement so there's a lot of feedback
that is built into how Sprints work
there's some clarity there too there's
that makes it
in a sense a very simple structure
because you have the roles you're either
you're a product owner you're a scrum
Master you're part of the dev team and
it's basically like you're either
you know driving the product as product
owner either coaching the team as a
scrum master or you are getting things
done if you're the development team
and so that makes it you know pretty
easy to know where you fit
and scrum is is Sprints and scrums are
very popular there is a lot of
information and content out there in the
forms of books and websites and podcasts
and YouTube channels and all kinds
however you consume content there is a
lot of it out there to help you uh
whether you're just getting started or
whether you're you're wanting to take
your you know scrum Sprint to a whole
new level there's a lot of stuff out
there so it's a really big community and
they they tend to be pretty good about
uh welcoming others in and trying to
help everybody get better doing it
so I after all that what are some of the
cons you know what are some of the
downsides to scrums and sprints
well one all of that and go back and we
talked about all of that feedback uh it
also equates to there's a lot of
meetings there's these stand-ups every
day there's reviews there's
retrospectives sometimes depending on
how you you know how they're run and
stuff like that they can just you like
feel like you're spending your life in
meetings
um
along those same lines it is not easy it
is difficult
to understand and really Embrace how
scrum the scrum approach works
because it's in some ways a very simple
structure there is a lot that it puts
back on the team members to be uh to own
essentially their you know their role
and what they want to do and to own the
fact that they are part of this team and
they they have a role in
um making it successful
and that could be difficult and it it
can be especially if you're not a you
know if you're not really a self-starter
if you're somebody likes a lot of
structure and a lot of Direction
it can make very difficult for you to
step into a scrum environment
uh workflow because of the way Sprints
are configured and the way you you Scope
stuff in
um the way you you do that zigging and
zagging then sometimes that can be too
rigid
um particularly if you think of like if
you're software support if you're
dealing with bugs and stuff like that
that you know customers report bugs if
you have a one month Sprint cycle then
the fastest they're going to get an
answer back is a month and sometimes
that's that's not going to work so
sometimes with Sprints your workflow can
be sometimes too rigid for what you
really need to do to to make your
customers happy
it's not often mentioned that I've seen
but a really good point is that there is
burnout that can come because typically
what happens with Sprints is you just go
from one Sprint into the next Sprint
into the next Sprint into the next
Sprint
and while companies have figured out
that like they're doing a Sprint over uh
you know the Christmas New Year holiday
stuff that you know that December
holiday period usually they're not even
going to bother with a Sprint because so
many people are out uh you may have that
as well if you're you know maybe if
you're in Europe or somewhere where they
have you know like typically like in
August where everybody's off for a week
or two then you just sort of say okay
we're gonna pause and we're not even
going to be working on a Sprint during
this time because we know most the
people will be unavailable
you may have uh annual conferences or
something like that where most of people
are not available
in some cases
that's perfect people love it but
typically what happens is if you don't
have some breaks in there you know maybe
you go a couple Sprints hard and then
you take a couple days off or something
like that there are
just other bits of work that don't get
done because they're not the things that
you typically would need to do but
they're not part of a Sprint so it's
it's sort of not on your radar until it
becomes an issue
and
that can be a problem so having a little
bit of time to say okay you know you're
not working on Sprint work today you're
just catching up on
other job related stuff you know you
just go that route
and finally uh flexibility really along
with that workflow is that sometimes
Sprint Cycles can take too long and that
zigging and zagging needs to be broken
up even you know to a smaller level
oops so the pros of kanban
talked about Sprints and scrum so let's
go back and talk about kanban boards so
visibility is a huge Plus for that
because you can look if you call the
bacteria your kanban board you can see
that and boom you know where you're at
you have at a you know visually very
quickly you can understand where you're
at and what the work is now within those
now sometimes those notes are very you
know those Post-its uh have very little
information on them but the idea is that
you know typically what you need to know
you can put on one posted or one card
and then you're off and running
it's flex flexible uh because you can
you know choose your item you're working
on and then you know work it through to
completion or flip it back to the
backlog and because you're not in a time
frame where you're you know with that
Sprint structure then it's just like you
come in you work on something you get it
done
and if you do it you know the best ways
to get those things done or where you
come in you work on it if you're not you
know if you're going home for the day or
off for a week and you're not able to
work on it you put it back into the
backlog and have it in a situation where
somebody else can pick it up and and run
with it as needed so you don't have
those you know those time frames so it
makes it much more flexible uh it's much
more granular to do kanban
which is the next point it's easier to
allocate work without overloading a
member everybody's working on something
at a given time ideally and they're not
you know they're working on an item
that's that's in progress they're not
working on 10 items they don't have a
whole bunch of stuff sitting in their
queue that says here's all this stuff
you're doing
it's you're doing whatever it is you're
doing today versus Sprints sometimes
there's this there's a tendency even
though it's not recommended where people
will go into a Sprint they'll assign a
lot of the stuff of the workout at the
beginning of the Sprint and so you may
have somebody that's
it gets all their work done early and
they're basically sitting there
twiddling their fingers while
you know somebody else is overloaded and
is working you know 80 hour weeks to
crank their way through that Sprint
kanban boards are going to require less
meetings because it's basically just
look at the board yeah you don't you
don't have to spend a lot of time
meeting about it you can you know you
may talk about tasks and stuff like that
but definitely the meetings disappear or
you know you have far fewer because
you're not doing that regular all of
those pieces that are part of each
Sprint you may still do some of those
things so you may do reviews you may do
retrospectives and things like that but
they are not
um they're not doing they're not done
maybe necessarily as often and
definitely not tied to time frames like
uh Sprints are
and if there's a the ability to focus if
you don't have 10 things on your to-do
list particularly if you don't have
multiple things that you're somewhat
working on and instead you're working on
an item and take it to completion and
then move on to your next task that
allows you to focus so you're not stuck
in something where you're you know
having to bounce back and forth between
a couple of different things or
different environments things like that
it's just like go work on it get it done
you're off and running much like as
we've talked about in the past
what do you think about the Pomodoro
approach
as you you know Focus
for a you know you're in in this case
it's not for you know that time period
but it's Focus until you get it done and
then when you come back to it when
you're ready to do some more work pick
up your next task and and do that and so
that also allows you you know instead of
that zigging and zagging and sort of
being a little bit locked in a direction
for a while it allows you to go to work
for a while get something done if you
have something else to take care of take
care of that and then you can come back
and you can work on whatever the next
ticket is
so the cons to that the downsides to
combine
it lacks structure because you have this
very minimal structure it there's it's
going to be lacking you know you
basically you've got your your backlog
you're doing it and you're done
and sometimes that can be now you can
add more steps but typically it is it's
just you go grab something to work on
you work on it till you're done and then
you move on to the next one so you
you have to be much more intentional to
make sure that you include pieces like
reviews and retrospectives
there are
um
The Specialist approach to software that
is sort of a legacy approach in a sense
um
is
kanban is not as useful for teams where
they've got uh like diverse silos so if
you've got like a like a front-end
person you've got a middle tier person
you've got a back-end person you've got
a testing person you've got a design
person you've got a user experience
person
when you have people that really only
have certain you know if you think of
that backlog
if really there's only you know one or a
very limited number of people that can
do any of those tasks then it's it's not
as useful because those people are going
to have to pick the tasks that they can
do if you've got a team that has a
broader set of skills
then you're going to be able to you know
where each member has a broader set of
skills then you can have any member can
take any ticket essentially and that
would be that's the ideal approach to
kanban is that any one of your
development team can pick up one of
those things to be done and do it that
is where kanban really uh is Gonna Shine
and if you don't have that the further
you get away from that
the further cross training and
cross-skill
set you have in your team the less
useful combat is going to be
updating can be a pain as I said one of
the ideas is that you can go work on
something and then
pause essentially and put it back into
the backlog for whatever reason and
doing so and making sure that that
documentation or that your situation is
frozen properly that somebody else can
pick it up
can be challenging it really does have
to be like a habit of the members of the
team to make sure that they properly you
know like commit stuff they use good
comments they do updates if there's you
know changes to the the scope or the
requirements on a card that they get
those things documented
um it doesn't have to be like complex
and you know full requirements documents
each time but you do have to keep stuff
up to date
otherwise it comes really confusing
really fast
there is a a limited size as well to
what a
a single kanban board is useful for if
you think about it and go back to this
example you know if you go here you know
there's I don't know 15 maybe 20 items
in your to-do and you know about the
same in your work and you're done done
doesn't really matter but you're to do
if it gets huge
um you know if you've got if like I
mentioned before like if you lay out all
of your kanban tasks for the next year
and particularly if you think about like
a combine card typically you probably
you know it varies but you typically
you're going to be able to knock out on
average you know maybe
you know one to four tickets a day
you got a team of 10 people that's you
know 10 to 40 tickets a day
and you do that over a year that pretty
quickly runs up to you know a thousand
cards sitting there which is just
overwhelming uh now a lot of times what
happens even if it's digital even it's
electronic it could get overwhelming and
a lot of times where Sprints will sort
of
will
sort of group that stuff during a time
period whatever Sprint is sometimes
you'll have different kanban boards to
have multiple boards that will be uh you
know maybe breaking out feature sets
within the application or there's a lot
of different ways that they can that
those can be done to sort of shrink that
down you know it's one of those it's
just it can be daunting to see a
thousand items out there and then to
find the right one you know to go say
okay what am I going to do
maybe you just pick at random but maybe
there's certain things that you're
better at and it takes a while to sort
through or to review what's out there to
pick what you're going to work on next
[Music]