Kanban
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:01
>> Hello and welcome to lesson 3.5,
00:01
Kanban in the course the phases of Agile.
00:01
I'm your instructor Cain,
00:01
and let's go ahead and get started.
00:01
This will be the last lesson of Module 3.
00:01
Kanban is interesting because it is
00:01
both a technique, and a specific toolset.
00:01
There are various vendors that sell
00:01
different types of software to do Kanban boarding,
00:01
but you don't necessarily need to [NOISE] buy software.
00:01
You can even do it with posted notes,
00:01
as the picture behind the text indicates.
00:01
It's a tool, it's a technique.
00:01
It doesn't have necessarily
00:01
an overarching philosophy like
00:01
some of the other flavors of Agile,
00:01
but it's been pretty widely accepted
00:01
across a lot of software development teams.
00:01
It's also in Microsoft DevOps,
00:01
which is one of the more popular
00:01
development areas in use today.
00:01
What is Kanban?
00:01
It is a pull method of work as opposed to
00:01
a traditional waterfall command,
00:01
and control type of pushing system.
00:01
What I mean by that is, traditionally,
00:01
you'd come into work, and your boss would tell
00:01
you you're going to do
00:01
this thing for the next few weeks,
00:01
or here's your assignments for the week,
00:01
or whatever the case might be.
00:01
You still see a little bit of that with Kanban,
00:01
but one of the advantages is it allows the developer or
00:01
the software programmers to pull work as they need it,
00:01
as they're running out of work.
00:01
In Japanese, it translates into visual signal,
00:01
and the idea behind that is in the 1880s and 1990s,
00:01
a little bit of 70s I guess too,
00:01
when the Japanese car manufacturing really started to
00:01
compete and in some cases
00:01
surpass the American automotive manufacturing,
00:01
one of the things that we did
00:01
when we studied how they were able to
00:01
be so efficient was they had these small little bins,
00:01
and what they would do instead of
00:01
ordering hundreds of thousands of parts,
00:01
or a whole year's worth of supplies,
00:01
in some cases, they were having multiple deliveries to
00:01
the factory floor every single day by the vendors.
00:01
What it allowed them to do is, one,
00:01
they didn't tie up a lot of money in inventory,
00:01
>> and two,
00:01
>> they would be able to change
00:01
their manufacturing processes faster in
00:01
the event that they found
00:01
a defect or something had to be shifted.
00:01
What the workers would do is they would get
00:01
items out of the small little bin, little Kanban bin,
00:01
and when that bin started to get low,
00:01
another worker would replace it,
00:01
and then go back to the back of the house,
00:01
if you will, and actually reload the bins.
00:01
They were able to use
00:01
what's called just-in-time inventory,
00:01
and it's a lot more common
00:01
now than it was back in those days.
00:01
But, it was a way to design and build
00:01
cars the same way that supermarket stock shelves.
00:01
If you think about it,
00:01
regardless of the quantity discount that I can get,
00:01
as a grocery store,
00:01
I'm going to go buy bananas,
00:01
if the bananas go bad in the store,
00:01
then I've just wasted
00:01
that inventory or wasted that money.
00:01
My goal is to have
00:01
exactly or as close to exactly the
00:01
>> number of bananas that
00:01
>> are going to be purchased that day in
00:01
my grocery store, and then get resupplied later on.
00:01
By applying those principles
00:01
to an agile development project,
00:01
it helps eliminate bottlenecks because
00:01
human nature is one of those things
00:01
that's not well understood,
00:01
but there are certain elements that we do understand.
00:01
One of the things that has been
00:01
widely studied and reported on is,
00:01
basically, workers,
00:01
if they're given a time to complete a task,
00:01
it will take exactly how long that you gave
00:01
them to complete it or later.
00:01
What I mean by that is if you
00:01
assign a student a paper that's due in two weeks,
00:01
it's going to take them two weeks to do it.
00:01
If you assign a program,
00:01
or a feature to build in two weeks,
00:01
it's going to take them two weeks to do it.
00:01
That's how our procrastination nature.
00:01
By allowing the workers to pull the work,
00:01
what it allows me to do as
00:01
a developer is I can build something,
00:01
test it, make sure everything's
00:01
working right and then say,
00:01
"Well, I've now got some dead time.
00:01
Rather than do something unproductive,
00:01
I can look and see all of
00:01
these other items that I can be doing,
00:01
and then I can pull those items out of
00:01
the backlog, and put it into my current sprint."
00:01
Or again, you can cross merge innate
00:01
agile with other types
00:01
of project management and/or product management.
00:01
In essence, what we're able to do is continue to
00:01
push new backlog requests
00:01
and new features as management,
00:01
and stakeholders, or product owners,
00:01
or whatever, you basically just
00:01
keep throwing these things in there.
00:01
As developers, when you completed
00:01
your work for the day or for whatever,
00:01
and you have nothing left in your to-do bin,
00:01
then you can go into the backlog and
00:01
start pulling more items in.
00:01
I'll show you a little bit here using DevOps,
00:01
and this is just a little sample where it
00:01
shows that these are
00:01
the items that have been approved for development.
00:01
Let's say I want to work on this one today,
00:01
I can drag it over here and start working on it.
00:01
Once it's done, I
00:01
put it into production, which would go over here.
00:01
Now, my test bucket is empty again,
00:01
and I can go grab some more.
00:01
Vice versa, under the evaluation column here,
00:01
you can have the project manager or
00:01
the project owner continually load new items in there.
00:01
You'll notice that they have these little numbers
00:01
and these are just estimated effort points,
00:01
and we've talked about that earlier in the course.
00:01
It doesn't correlate necessarily
00:01
into anything in particular.
00:01
What it is is just a way of
00:01
estimating on a scale of whatever
00:01
>> the team chooses 1-10,
00:01
>> 1-5, how hard they think this is going to be.
00:01
If you're using Kanban boards,
00:01
and I'm pulling the work,
00:01
and let's say that I think I can do
00:01
10 units of work per week,
00:01
and I'm actually doing 15 units of
00:01
>> work because I'm able
00:01
>> to gather more work on my
00:01
own without waiting for someone to give it to me,
00:01
then the forecasting process
00:01
actually gets better because then I can go back
00:01
during my sprint or
00:01
my quarterly build cycle if I'm doing DSTM
00:01
>> and I can say,
00:01
>> "Okay, on average,
00:01
Cain is doing 15 units of work a week,
00:01
so let's have our project schedule
00:01
reflect the fact that I'm able to produce more stuff."
00:01
That's a quick example of how a Kanban board works,
00:01
but the more important thing about it is, again,
00:01
it's a principle of it,
00:01
as well as the fact that it's
00:01
not necessarily technology dependent,
00:01
but it's very often thought of as a tool.
00:01
There's freeware software that you can use,
00:01
there's cloud-based software that you can use.
00:01
Most project management software,
00:01
it will have some form of Kanban boards,
00:01
and it's just one of those things that allows
00:01
the work structure to not be dependent
00:01
on the manager to actually
00:01
go in and assign the work which
00:01
the manager can still do but it
00:01
just allows you to actually meet.
00:01
Well, usually,
00:01
a team doing a Kanban model will try to meet
00:01
once a week or once a day in the morning,
00:01
but they're usually very short meetings.
00:01
If you're doing them daily, for example,
00:01
you get the team together and basically would say,
00:01
hey, what do you want to do today?
00:01
You'd grab your little post-it note item,
00:01
stick it on the to-do or the in-progress lane,
00:01
and then go ahead and get it done and then you can
00:01
go back and get more and so on and so on.
00:01
It's much more organic than a traditional waterfall,
00:01
and it also avoids a planning that's
00:01
required to build a complete work breakdown structure.
00:01
With Kanban, you don't have to do that.
00:01
You can basically just,
00:01
as the business owner or the project manager,
00:01
you can just throw these things over the fence.
00:01
As long as you do a good job of
00:01
describing the user story, or the use case,
00:01
or wherever you want to call it, then
00:01
the developer should be
00:01
able to build it and keep moving forward.
00:01
In today's video, we completed
00:01
Module 3 with the lesson on Kanban.
00:01
Thank you very much,
00:01
>> and hope everybody has a great day.
Up Next
Similar Content
