Detailed Notes
This is the final part 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] and then it can lead to churn where I mentioned where you can like push stuff into progress but then you push it back in the to-do list um you know some of that kind some of that can lead into sort of like a thrashing on tasks where you you can move it forward just a little bit but then you're blocked and then you have to push it back and then you have to document everything and then you go push it forward a little bit and then it's back uh a lot of times that has to do with improperly sized tasks but there are other things that can lead to that as well so we've talked about some pros we've talked about some cons so some of the things to think about when you are choosing your approach you know do I should I do Sprints should I do scrum you know should I do Sprint scrum or should I do maybe kanban one of the things I've mentioned now a couple times uh and is this a new product or is this more like a maintenance enhancements kind of approach or team if it's a new product then your your backlog is a little more static I guess it really isn't but it's like it it feels more static because with a new product what the way that thing is growing is it's because you've got designers and uh product owner and stuff like that and even feedback from your customers that you're using to to get to uh whatever that end product goal is and along the way you're you're having these Sprints so you're you know with each Sprint you just sort of you know push some stuff in you go work on it and the things that are in the backlog while you're working on a Sprint are things to continue moving forward and enhance that product so they are in effect uh while there are priorities they technically could sit there until product completion it could be you know those could be what like you could early on put in a task that ends up being the absolute last task that you complete before you say okay the product's done if you're doing maintenance and enhancements I'm sorry if you yeah if you're doing especially more maintenance I guess and Bug fixes but also enhancements where you're getting that regular stream from your customers then you're going to get stuff on a regular basis that maybe are are going to want to bump priority uh bug you know defect and bugs and defects are famous for that where you get into something where it's like oh we put a release out and we're looking ahead for the next month of development and somebody comes in with something it's like oh this is critical this has to be dealt with now uh this is you know we've got half our users can't use our application if it's a Sprint or something like that then yeah you could always like step outside of your Sprint and that's usually what happens but if it's you know that that's going to be more suitable to combine because you say okay who we got available today let's work on the tasks to get that critical fix uh in place the next thing is think about your T is your team skilled or novice in particular with the world uh within the world of agile because as I said it's not simple it may seem simple on the surface of it but actually being comfortable with doing development in this either of these environments is can be a bit of a challenge kanban tends to be a little easier to step into because you don't have to think through Sprints and and all of the different things around those instead it's basically like oh I just go to a board and I grab a task I'm going to work on so you don't have to understand the process really at all all you need to know is go to the board find something to do pick it move it to the end progress and then when you're done move it to in to the done column and that's it yeah you don't have to get much more complicated than that and then just say like and when you're done you go pick another task so depending on your uh your team's experience in the agile world uh it may you know that will maybe shift you towards hey we can do Sprints or we can do we just need to do kanbans for now what's the backlog size if you're building out something that's you know huge it may not combine may not be a good fit as I mentioned that's one of those weaknesses where it could be you know at the Sprint with that Sprint scrum approach you can have a huge incredible backlog of stories and epics and all that kind of stuff and it never really becomes as much a problem because when you move into a Sprint you're basically taking you know like an epic or a story or some theme of tickets and you sort of move those in and that's really the you know the product owner really the scrum Master is doing those pieces of work and so the development team has a it's just picking from the Sprint work as opposed to having to Sprint you know sort through the entire backlog um Team availability is something now there's tools now that make it easier to do like daily stand-ups even if you've got a team that's all the way around the globe however it's hard to do that because it ends up being that certain you know team members have to adjust their schedule they have to you know it's it's really hard to find the right time to do that if you're you know if you've got developers essentially running you know 24 7 or even five days a week but you know roughly 24 hours a day while they're doing that is getting the the benefit out of a stand-up so your Sprint because of the you know Sprints drive you to have a lot of that communication and interaction if that's difficult to do then it may be that it's easier to use kanban and to keep it much more granular so you don't have to have as much communication uh within your team sort of similar to the the new product versus maintenance and enhancements and defects is the priorities if you know that the tasks you're working on or the tasks that you're going to want to be working on for the next couple of weeks you know during that whatever that Sprint length is then you're great but if you have to worry whether your priorities are going to change daily uh and there are some organizations that's how it works then you're probably going to be better off doing you know kanban because you could actually come in and you could have everything planned out and say okay this is what I'm working on today this is what the team's working on we've got everything in progress halfway through the day priorities change and everybody said okay we're going to push everything back to the backlog and we have this new set of tasks we're doing and you're off and running so you can be very flexible in adjusting priorities and people talk about you know pivots and stuff like that if you pivot every day or you pivot on a regular basis while it can be frustrating at least kanban will allow you to adapt to that better and then there is a way there are some ways that you can look at stuff and sort of choose both of them so you know maybe you have like a essentially a kanban board each Sprint it sort of gets reset and you filter in initially you know some some of your tasks that you're going to do during that Sprint but then you have the ability to just throw tasks into that at any given time so maybe you have like that Sprint backlog as opposed to the you know and then you've got the full product backlog you've got your Sprint backlog and maybe within a Sprint you know you treat it as a as more of a kanban approach where it's just like just grab something work on it and in that situation you may not have as tight a um scope or theme or story for a given Sprint but that's also basically you just go into it saying hey we all agree that this is we can't stay uh heads down for whatever the Sprint link that you know for two weeks for four weeks we have to be able to adapt and pull in new tasks very quickly and so you may have to look at doing some sort of a blended approach all right questions and comments so Rob in this particular approach when you're dealing with um like new teams or essentially established teams that then add new people if you're in a typical Sprint mode this does sometimes switching to a cabana mode for the new people I I've had mixed on this because one of the problems we've run into with the Sprint approach is the new people pick up tickets initially may take them a couple of Sprints to get you know brought up to speed um complete the tickets but then once you get uh once you get up to speed then all of a sudden maybe the tickets are being completed way too soon so we have to pull additional tickets in from the backlog which for a while is fine and eventually it balances out but uh what's your take on that that's a uh that's actually something I didn't mention but it's a good point is part of the challenge of Sprints is if you bring on new resources then you really it's it's configured in a way that people need to join and leave the team within the Sprint uh structure so it's it is very helpful where people's like first day on the team would be coincide with the start of a Sprint at their last day would coincide with the end of a Sprint and I've worked with organizations where that's my start date was was strictly tied to you know a Sprint and so if something happens and you missed that first day then you know maybe somewhere like okay well we'll just wait to the next Sprint to to add a resource and it has to be uh prefaced with that as well so the people that are planning out the Sprint can you know understand what kind of resources they have now the idea of having like a a kanban board that would be uh uh this would be like a combo approach is that maybe you have sprints and you pull stuff into a Sprint but you separately have um a kanban team or a kanban board that is just like hey this is outside of a Sprint and it is a way to tackle things that are uh adjusting priorities so you may have something where we're zigging and zagging our way through on a product but we also have this separate maybe kanban backlog of things we're going to get to it when we can get to it and you can use that sometimes if uh you know if somebody's going to take a Sprint off you know maybe you have like somebody that's normally a Sprint uh part of that Sprint approach that Sprint team that maybe say okay you're going to set out for this next one and you're going to do more like the you know the uh enhancements or bug fixing or or things like that and sometimes it's it's things like um documentation tasks or research or catching up uh tests you know building out some some additional regression or unit tests that we've we've missed along the way those things may be the things that you know and just technical debt in general sometimes it doesn't hurt to say okay here's our Sprints and our primary backlog and our primary work we're doing but as we generate technical debt we're going to have this kanban board and as we bring new people in it may be perfect for you know them to pick up some of those tasks if we have somebody that's you know Gonna Miss like because for example like if you've got a two-week Sprint and somebody's got a week vacation in there maybe it doesn't make sense for them to have any part of the Sprint and instead you can shift them over and they do kanban work for that week that they're there um it doesn't allow you to and it's I think if you use that as part of rolling on um new you know new individuals you can actually throw stuff out into that kanban board that are um tasks that are like orientation and introductory tasks now I've done it where we've we had Sprints sort of um that we were focused on with a team that I'm working with and what we would do is just there was this really it was closer to like a kanban board approach where it's like here's a list of tasks that you need to do and just start working your way through those and they were separate from you know they were part of onboarding and separate from the Sprint and then once we got them to a point where they were comfortable then we could roll them into a Sprint and before that they you know stuff where it's like there was always that core those core tasks were like well we need you to understand these things to to read this or to review that or to set this account up but you know all of those must-haves for onboarding and then we would have other stuff where it's like hey if you've gotten this far then take a look you know maybe here's some tasks that you can do that would help us out and so having a uh like a kanban feed in or feed out approach to Sprints may be a really good way to go is it's you take that stuff that's lower priority that's nice to haves or stuff that's just never seems to make its way into a regular Sprint like technical debt push that into a compound board and then bring people in and say here you go you can help us out with that and particularly because like documentation and testing and some of that that sometimes are the technical debt kinds of things that are sitting around um sometimes those are perfect for people that are new to come in and it forces them to really get to know the product a little bit better because they've gotta uh you know a clear objective something they need to learn something they need to to do or whatever some sort of deliverable uh that really helps pull them into the team all right so that I I like that now here's a second scenario so if you were to take an existing like monolith application that continues to need support but then you need to break it out into a new application or at least start breaking up the core components would you keep that in Sprint or kind of break it into both or just switch to a cabana model I have seen um typically what I've seen and what I think works pretty well is that you have a you really that's where you do split it so you're uh your new we'll call it new development but you're you know creating that new version of the product lives in a Sprint but then and particularly like if you're going from like 1 0 to 2.0 as you put all the 2.0 stuff into Sprints and you're really focusing on that so the people that are in the Sprints are not distracted by bugs and fixes for version 1.0 and patches and then separately now you can do I've seen it done where you also have like uh you have like nude product Sprints and you have maintenance Sprints which you can do that but it's sometimes it's a lot easier to have the new product Sprints and then the maintenance kanban because then it's just because you're not always sure what the the level of work is that you're going to have for some of that maintenance and enhancement and Bug fixes sometimes it's easier to do it in a kanban approach where you just say okay we're going to just like keep working until we have enough stuff in the development in the done q that we're going to say okay we're going to do a you know a point release and we can always release stuff like individually we may do like a you know ticket here ticket there because it's so high priority but generally speaking we're just gonna like we're not going to bother with a release an update or a point release until we get a certain number of features that are in that that done and sometimes that works yeah sometimes it's not because your customers are pushing to get those things done but particularly if you're doing like sun setting a product or end of life um it may be one of those where you're saying hey we're if it's something that we really want to push into the new software then maybe it's something we say hey we're not even going to do it here we'll just take this and it's not going to be in our kanban approach it's going to be over in our um in our Sprint approach so that's another good place where you you know sometimes you'll see that diversion so maybe as you go through version 1.0 it's all Sprints but then once you you know complete or release version 1.0 you have a kanban approach to track all of the bugs and Bug fixes and point releases and your new development ends up you know living in Sprints and it does really help the Sprint team because Sprint teams can get really frustrated if they constantly have these new things that are you know punted into their Sprint and now they've got to drop stuff they've got different set of priorities and they're not able to think in that Sprint mode they're instead really forced to you know scramble a little bit and constantly make adjustments and so that's a it's a great way to do it is have two because it's two different needs as software development is to take the two different approaches cool thanks Rob other questions or comments um my other question is like isn't it so hard uh to hold I mean everybody accountable in the kanban uh Sprints because since they don't have like uh index who are like okay maybe we did Sprint one because kanban just keeps continuing and I've seen whereby we just take continue uh taking tasks to you and you you can see days on them whereby that that we have had them on board for a long time isn't it so hard running kanban yeah when you have a bigger team um I don't think so because if you do it if you track who has done who has worked on tasks yeah then kanban works really well because you can look at I mean because you and you'll probably periodically you know clean out the done so you can sort of do it from a like maybe every week you do everything for a week and stuff gets moved into done yeah and then after that you can if you're a manager you look at it and say okay well let's just I'm going to sort of look and see what who did what this week or and if something sits in progress for a long period of time then that becomes its own little you know red flag where you look to it and say Hey you know hey Michael you've been sitting on this task for a week we didn't think it was going to take that long what's going on what can you know is it are you blocked is there something that you need you know some help you need what is it that we can do to get that thing you know moving forward and if it is somebody that's just you know grabs it and sits on it then at least there's that you know you do have that accountability where it's like hey you've been on that for a couple days that should be done so get off your butt and get the work done yes it's it is I think it's more flexible for the manager to be able to manage that as they can they can either look to see that people are constantly you know have something that to do they can look to see if things are taking too long they can look to see if people are just not getting things done as fast as they expect them to and it allows people as well because there may be tickets that are difficult they're complex and other ones that are very easy um and that's another thing is you can sort of watch it see is it somebody always cherry picking like the easy stuff is it you know is there somebody that's not pushing themselves or you say Hey you know you're picking a lot of easy tasks I've seen you're completing all these things that I think are beneath you I think you need to stretch yourself a little bit more you know there's things like that that you can you can do within that uh that I think it gives you compound I think gives you a lot of flexibility as a manager to drive your team the way you want to good question though okay so so what would be your password preference I mean this is the first time I've worked on the kanban project so I'm I've always been either strictly scrum agile so any preference when it comes to I really don't I think there's there's a value in both of them um personally I have like I do personal Sprints and have for years and years now that I have I mean it's like it's not really scrum because it doesn't really focus you know I don't have a big enough team it's just me but I do within that have the idea of I sort of look at I sort of do a quick review and sort of a retrospective uh maybe not every Sprint but probably you know every couple of Sprints and it allows me and I could do that with kanban um but just with the Sprint it gives me a little it's just easier for me in that case it's easier for you to manage how fast am I getting stuff done how much should I expect that I'm going to get done in the next you know Sprint period which I do like two weeks so what is it that I should expect based on history to be able to get done in the next couple weeks um I could do that with kanban it's just Sprints for me are much more it reminds me you know regularly it's like hey you've got a new Sprint so take a look at what you got done take a look at what you're you know you need to load your backlog up and you need to adjust priorities um but I've been in a lot of situations where kanban is much much easier to deal with and uh the overhead that is involved with Sprint just doesn't work because the team is not that kind of a team so it really does come down to what what the project is and what the team's like as far as which is uh for me which I prefer okay well thank you any other questions or comments hearing none so what do we learn um hopefully or maybe we already knew this kanban and scrum are both options for an agile approach to software development as you would expect there are strengths and weaknesses to each of these the uh the right or the best approach really is going to vary by team and project and and what are your goals what are your priorities and more importantly uh which is I think one of the keys to Agile in general is it it's flexible it is agile and you can combine them uh we've talked especially in the even in the Q a session we've talked about a couple different ways here that you can combine these that you can you know find the strengths and the weaknesses uh and use the strengths of both were their best and avoid them where they're you know weak use the other approach and that brings us to the end of this so I want to thank you again for your time as always appreciate the time that you spend working on becoming a better developer there are plenty of plenty of ways you can get a hold of us uh info developmentor.com for email we have a contact us format on the developreneur.com we have a YouTube channel we've got uh the developer or Vimeo channel uh YouTube If you go search for developreneur d-e-v-e-l-p-r-e-n-e-u-r you will be able to see where our channel is and our you know we've got now I think probably we're well over a hundred different um uh YouTube uh typically 15 to 30 minute type uh videos that are out there multiple I think we've got about a dozen different channels sort of like focused topics uh and those crank out much like the podcast when it's live you know twice a week Vimeo you can see some of the longer form stuff including some of these Mentor sessions you have a Facebook page developreneur and uh developer out on twitter.com you know definitely follow us there and we do regular multiple times a day we've got uh both links to some of our content but also various new sites that we follow and and some cool information that's out there as always we're just doing this because our goal is to make every developer better and appreciate the time that you invest in yourself to make yourself better with these kinds of presentations thank you and have a good day [Music]
Transcript Segments
thank you
[Music]
and then it can lead to churn where I
mentioned where you can like push stuff
into progress but then you push it back
in the to-do list
um you know some of that kind some of
that can lead into sort of like a
thrashing on tasks where you you can
move it forward just a little bit but
then you're blocked and then you have to
push it back and then you have to
document everything and then you go push
it forward a little bit and then it's
back uh a lot of times that has to do
with improperly sized tasks but there
are other things that can lead to that
as well
so we've talked about some pros we've
talked about some cons
so some of the things to think about
when you are choosing your approach you
know do I should I do Sprints should I
do scrum you know should I do Sprint
scrum or should I do maybe kanban
one of the things I've mentioned now a
couple times uh and is this a new
product or is this more like a
maintenance enhancements kind of
approach or team if it's a new product
then your your backlog is a little more
static I guess it really isn't but it's
like it it feels more static because
with a new product what the way that
thing is growing is it's because
you've got designers and
uh product owner and stuff like that and
even feedback from your customers that
you're using to
to get to uh whatever that end product
goal is and along the way you're you're
having these Sprints so you're you know
with each Sprint you just sort of you
know push some stuff in you go work on
it and the things that are in the
backlog while you're working on a Sprint
are things to continue moving forward
and enhance that product so they are in
effect
uh while there are priorities they
technically could sit there until
product completion it could be you know
those could be
what like you could early on put in a
task that ends up being the absolute
last task that you complete before you
say okay the product's done
if you're doing maintenance and
enhancements I'm sorry if you yeah if
you're doing especially more maintenance
I guess and Bug fixes but also
enhancements where you're getting that
regular stream from your customers then
you're going to get stuff on a regular
basis that maybe are are going to want
to bump priority uh bug you know defect
and bugs and defects are famous for that
where you get into something where it's
like oh we put a release out
and we're looking ahead for the next
month of development and somebody comes
in with something it's like oh this is
critical this has to be dealt with now
uh this is you know we've got half our
users can't use our application
if it's a Sprint or something like that
then yeah you could always like step
outside of your Sprint and that's
usually what happens
but if it's you know that that's going
to be more suitable to combine because
you say okay who we got available today
let's work on the tasks to get that
critical fix uh in place
the next thing is think about your T is
your team
skilled or novice in particular with the
world uh within the world of agile
because as I said it's not
simple it may seem simple on the surface
of it but actually
being comfortable with doing development
in this either of these environments is
can be a bit of a challenge kanban tends
to be a little easier to step into
because you don't have to think through
Sprints and and all of the different
things around those instead it's
basically like oh I just go to a board
and I grab a task I'm going to work on
so you don't have to understand the
process really at all
all you need to know is go to the board
find something to do
pick it move it to the end progress and
then when you're done move it to in to
the done column and that's it yeah you
don't have to get much more complicated
than that and then just say like and
when you're done you go pick another
task
so depending on your
uh your team's experience in the agile
world uh it may you know that will maybe
shift you towards hey we can do Sprints
or we can do we just need to do kanbans
for now
what's the backlog size if you're
building out something that's you know
huge
it may not combine may not be a good fit
as I mentioned that's one of those
weaknesses where it could be you know at
the Sprint with that Sprint scrum
approach you can have a huge incredible
backlog of stories and epics and all
that kind of stuff and it never really
becomes
as much a problem because when you move
into a Sprint you're basically taking
you know like an epic or a story or some
theme of tickets and you sort of move
those in
and that's really the you know the
product owner really the scrum Master is
doing those pieces of work and so the
development team has a it's just picking
from the Sprint work as opposed to
having to Sprint you know sort through
the entire backlog
um Team availability is something now
there's tools now that make it easier to
do like daily stand-ups even if you've
got a team that's all the way around the
globe
however
it's hard to do that because it ends up
being that certain you know team members
have to adjust their schedule they have
to you know it's it's really hard to
find the right time
to do that if you're you know if you've
got developers essentially running you
know 24 7 or even
five days a week but you know roughly 24
hours a day while they're doing that
is getting the the benefit out of a
stand-up so your Sprint because of the
you know Sprints drive you to have a lot
of that communication and interaction if
that's difficult to do then it may be
that it's easier to use kanban and to
keep it much more granular so you don't
have to have as much communication uh
within your team
sort of similar to the the new product
versus maintenance and enhancements and
defects is the priorities
if you know that
the tasks you're working on or the tasks
that you're going to want to be working
on for the next couple of weeks you know
during that whatever that Sprint length
is then you're great but if you have to
worry whether your priorities are going
to change daily uh and there are some
organizations that's how it works then
you're probably going to be better off
doing you know kanban because you could
actually come in and you could have
everything planned out and say okay this
is what I'm working on today this is
what the team's working on we've got
everything in progress halfway through
the day priorities change and everybody
said okay we're going to push everything
back to the backlog and we have this new
set of tasks we're doing and you're off
and running so you can be very flexible
in adjusting priorities and people talk
about you know pivots and stuff like
that if you pivot every day or you pivot
on a regular basis while it can be
frustrating at least kanban will allow
you to adapt to that better
and then there is a way there are some
ways that you can look at stuff and sort
of choose both of them so you know maybe
you have like a essentially a kanban
board
each Sprint it sort of gets reset
and you filter in initially you know
some some of your tasks that you're
going to do during that Sprint
but then you have the ability to just
throw tasks into that at any given time
so maybe you have like that Sprint
backlog
as opposed to the you know and then
you've got the full product backlog
you've got your Sprint backlog
and maybe within a Sprint you know you
treat it as a as more of a kanban
approach where it's just like just grab
something work on it
and
in that situation you may not have as
tight a
um scope or theme or story for a given
Sprint but that's also basically you
just go into it saying hey we all agree
that this is
we can't stay
uh heads down for whatever the Sprint
link that you know for two weeks for
four weeks we have to be able to adapt
and pull in new tasks very quickly
and so you may have to look at doing
some sort of a blended approach
all right questions and comments
so Rob in this particular approach when
you're dealing with
um
like new teams or essentially
established teams that then add new
people
if you're in a typical Sprint mode
this does sometimes switching to a
cabana mode for the new people
I I've had mixed on this because one of
the problems we've run into with the
Sprint
approach is the new people pick up
tickets initially may take them a couple
of Sprints to get you know
brought up to speed
um complete the tickets but then once
you get uh once you get up to speed then
all of a sudden maybe the tickets are
being completed way too soon so we have
to pull additional tickets in from the
backlog which for a while is fine and
eventually it balances out but uh what's
your take on that
that's a uh that's actually something I
didn't mention but it's a good point is
part of the challenge of Sprints is if
you bring on new resources then you
really it's it's configured in a way
that people need to join and leave the
team
within the Sprint
uh structure so it's it is very helpful
where people's like first day on the
team would be coincide with the start of
a Sprint
at their last day would coincide with
the end of a Sprint and I've worked with
organizations where that's my start date
was was strictly tied to you know a
Sprint and so if something happens and
you missed that first day then you know
maybe somewhere like okay well we'll
just wait to the next Sprint to to add a
resource
and
it has to be
uh prefaced with that as well so the
people that are planning out the Sprint
can you know understand what kind of
resources they have
now the idea of having like a a kanban
board that would be uh
uh this would be like a combo approach
is that maybe you have sprints
and you pull stuff into a Sprint
but you separately have
um a kanban team or a kanban board that
is just like hey this is outside of a
Sprint and it is a way to tackle things
that are uh adjusting priorities
so you may have something where we're
zigging and zagging our way through on a
product but we also have this separate
maybe kanban backlog of things we're
going to get to it when we can get to it
and you can use that sometimes if uh you
know if somebody's going to take a
Sprint off you know maybe you have like
somebody that's normally a Sprint uh
part of that Sprint approach that Sprint
team that maybe say okay you're going to
set out for this next one and you're
going to do more like the you know the
uh enhancements or bug fixing or or
things like that and sometimes it's it's
things like
um
documentation tasks or research or
catching up uh tests you know building
out some some additional regression or
unit tests that we've we've missed along
the way
those things may be the things that you
know and just technical debt in general
sometimes it doesn't hurt to say okay
here's our Sprints and our primary
backlog and our primary work we're doing
but as we generate technical debt we're
going to have this kanban board and as
we bring new people in it may be perfect
for you know them to pick up some of
those tasks if we have somebody that's
you know Gonna Miss like because for
example like if you've got a two-week
Sprint and somebody's got a week
vacation in there maybe it doesn't make
sense for them to have any part of the
Sprint
and instead you can shift them over and
they do kanban work for that week that
they're there
um it doesn't allow you to and it's
I think if you use that as part of
rolling on
um new you know new individuals you can
actually throw stuff out into that
kanban board that are
um tasks that are like orientation and
introductory tasks now I've done it
where we've we had Sprints sort of
um that we were focused on with a team
that I'm working with
and what we would do is just there was
this really it was closer to like a
kanban board approach where it's like
here's a list of tasks that you need to
do and just start working your way
through those and they were separate
from you know they were part of
onboarding and separate from the Sprint
and then once we got them to a point
where
they were comfortable then we could roll
them into a Sprint and before that they
you know stuff where it's like there was
always that core those core tasks were
like well we need you to understand
these things to to read this or to
review that or to set this account up
but you know all of those
must-haves for onboarding and then we
would have other stuff where it's like
hey if you've gotten this far then take
a look you know maybe here's some tasks
that you can do that would help us out
and so having a
uh like a kanban feed in or feed out
approach to Sprints may be a really good
way to go is it's you take that stuff
that's lower priority that's nice to
haves or stuff that's just never seems
to make its way into a regular Sprint
like technical debt
push that into a compound board and then
bring people in and say here you go you
can help us out with that and
particularly because like documentation
and testing and some of that that
sometimes are the technical debt kinds
of things that are sitting around
um sometimes those are perfect for
people that are new to come in and it
forces them to really get to know the
product a little bit better because
they've gotta uh you know a clear
objective something they need to learn
something they need to to do or whatever
some sort of deliverable uh that really
helps pull them into the team
all right so that I I like that now
here's a second scenario so if you were
to take an existing like monolith
application that continues to need
support but then you need to break it
out into a new application or at least
start breaking up the core components
would you
keep that in Sprint or kind of break it
into both or just switch to a cabana
model
I have seen
um
typically what I've seen and what I
think works pretty well is that you have
a
you really that's where you do split it
so you're uh your new we'll call it new
development but you're you know creating
that new version of the product lives in
a Sprint
but then and particularly like if you're
going from like 1 0 to 2.0 as you put
all the 2.0 stuff into Sprints and
you're really focusing on that so the
people that are in the Sprints are not
distracted by bugs and fixes for version
1.0 and patches
and then separately now you can do I've
seen it done where you also have like uh
you have like nude product Sprints and
you have maintenance Sprints which you
can do that but it's sometimes it's a
lot easier to have the new product
Sprints and then the maintenance kanban
because then it's just because you're
not always sure what the the level of
work is that you're going to have for
some of that maintenance and enhancement
and Bug fixes
sometimes it's easier to do it in a
kanban approach where you just say okay
we're going to just like keep working
until we have enough stuff in the
development in the done
q that we're going to say okay we're
going to do a you know a point release
and we can always release stuff like
individually we may do like a you know
ticket here ticket there because it's so
high priority but generally speaking
we're just gonna like
we're not going to bother with a release
an update or a point release until we
get a certain number of features that
are in that that done and sometimes that
works yeah sometimes it's not because
your customers are pushing to get those
things done but
particularly if you're doing like sun
setting a product or end of life
um it may be one of those where you're
saying hey we're if it's something that
we really want to push into the new
software then maybe it's something we
say hey we're not even going to do it
here we'll just take this and it's not
going to be in our kanban approach it's
going to be over in our
um in our Sprint approach so that's
another good place where you you know
sometimes you'll see that diversion so
maybe as you go through version 1.0 it's
all Sprints but then once you you know
complete or release version 1.0
you have a kanban approach to track all
of the bugs and Bug fixes and point
releases and your new development ends
up you know living in Sprints and it
does really help
the Sprint team because Sprint teams can
get really frustrated if they constantly
have these new things that are you know
punted into their Sprint and now they've
got to drop stuff they've got different
set of priorities and they're not able
to think in that Sprint mode they're
instead really forced to you know
scramble a little bit and constantly
make adjustments and so that's a it's a
great way to do it is have two because
it's two different
needs as software development is to take
the two different approaches
cool thanks Rob
other questions or comments
um my other question is like isn't it so
hard uh to hold I mean everybody
accountable in the kanban uh Sprints
because since they don't have like uh
index who are like okay maybe we did
Sprint one because kanban just keeps
continuing and I've seen whereby we just
take continue
uh taking tasks to you and you you can
see days on them whereby that
that we have had them on board for a
long time isn't it so hard running
kanban yeah when you have a bigger team
um I don't think so because if you do it
if you track who has done who has worked
on tasks yeah then kanban works really
well because you can look at I mean
because you and you'll probably
periodically you know clean out the done
so you can sort of do it from a like
maybe every week you do everything for a
week and stuff gets moved into done yeah
and then after that you can if you're a
manager you look at it and say okay well
let's just I'm going to sort of look and
see what who did what this week or and
if something sits in progress for a long
period of time then that becomes its own
little you know red flag where you look
to it and say Hey you know hey Michael
you've been sitting on this task for a
week we didn't think it was going to
take that long what's going on what can
you know is it are you blocked is there
something that you need you know some
help you need what is it that we can do
to get that thing you know moving
forward and if it is somebody that's
just you know grabs it and sits on it
then at least there's that you know you
do have that accountability where it's
like hey you've been on that for a
couple days that should be done so get
off your butt and get the work done yes
it's
it is I think it's more flexible for the
manager to be able to manage that as
they can
they can either look to see that people
are constantly you know have something
that to do they can look to see if
things are taking too long they can look
to see if people are just not getting
things done as fast as they expect them
to
and it allows people as well because
there may be tickets that are
difficult they're complex and other ones
that are very easy
um and that's another thing is you can
sort of watch it see is it somebody
always cherry picking like the easy
stuff is it you know is there somebody
that's not pushing themselves or you say
Hey you know you're picking a lot of
easy tasks I've seen you're completing
all these things that I think are
beneath you I think you need to stretch
yourself a little bit more you know
there's things like that that you can
you can do within that uh that I think
it gives you compound I think gives you
a lot of flexibility as a manager to
drive your team the way you want to
good question though okay so so what
would be your password preference I mean
this is the first time I've worked on
the kanban project so I'm I've always
been either strictly scrum agile so
any preference when it comes to I really
don't I think there's there's a value in
both of them
um personally I have like I do personal
Sprints and have for years and years now
that I have I mean it's like it's not
really scrum because
it doesn't really focus you know I don't
have a big enough team it's just me but
I do within that have the idea of I sort
of look at I sort of do a quick review
and sort of a retrospective uh maybe not
every Sprint but probably you know every
couple of Sprints
and it allows me and I could do that
with kanban
um but just with the Sprint it gives me
a little it's just easier for me in that
case it's easier for you to manage how
fast am I getting stuff done how much
should I expect that I'm going to get
done in the next you know Sprint period
which I do like two weeks so what is it
that I should expect based on history to
be able to get done in the next couple
weeks
um I could do that with kanban it's just
Sprints for me are much more it reminds
me you know regularly it's like hey
you've got a new Sprint so take a look
at what you got done take a look at what
you're you know you need to load your
backlog up and you need to adjust
priorities
um but I've been in a lot of situations
where kanban is much much easier to deal
with and uh the overhead that is
involved with Sprint just doesn't work
because the team is not that kind of a
team so it really does come down to what
what the project is and what the team's
like as far as which is uh for me which
I prefer
okay
well thank you
any other questions or comments
hearing none
so what do we learn
um hopefully
or maybe we already knew this kanban and
scrum are both options for an agile
approach to software development
as you would expect there are strengths
and weaknesses to each of these
the uh the right or the best approach
really is going to vary by team and
project and and what are your goals what
are your priorities
and more importantly uh which is I think
one of the keys to Agile in general is
it it's flexible it is agile and you can
combine them uh we've talked especially
in the even in the Q a session we've
talked about a couple different ways
here that you can combine these that you
can you know find the strengths and the
weaknesses uh and use the strengths of
both were their best and avoid them
where they're you know weak use the
other approach
and that brings us to the end of this so
I want to thank you again for your time
as always appreciate the time that you
spend working on becoming a better
developer there are plenty of plenty of
ways you can get a hold of us uh info
developmentor.com for email we have a
contact us format on the
developreneur.com we have a YouTube
channel we've got uh the developer or
Vimeo channel uh YouTube If you go
search for developreneur
d-e-v-e-l-p-r-e-n-e-u-r you will be able
to see where our channel is and our you
know we've got now I think probably
we're well over a hundred different
um
uh YouTube
uh typically 15 to 30 minute type uh
videos that are out there multiple I
think we've got about a dozen different
channels sort of like focused topics uh
and those crank out much like the
podcast when it's live you know twice a
week
Vimeo you can see some of the longer
form stuff including some of these
Mentor sessions
you have a Facebook page developreneur
and uh developer out on twitter.com you
know definitely follow us there and we
do regular multiple times a day we've
got uh both links to some of our content
but also various new sites that we
follow and and some cool information
that's out there
as always
we're just doing this because our goal
is to make every developer better and
appreciate the time that you invest in
yourself to make yourself better with
these kinds of presentations
thank you and have a good day
[Music]