Hello and welcome to lessen 3.5 Kon Bon
in the course, the faces of agile I'm your instructor cane,
and let's go ahead and get started. This will be the last lesson of module three.
So Khan Bon is interesting because it is both a technique and a specific tool set.
There are various vendors that's tell different types of software to do conv on boarding,
but you don't necessarily need to excuse me. You don't necessarily need to buy software. You can even do it with Post it notes, as the picture behind the text indicates. So
it's a tool. It's a technique it doesn't have necessarily an overarching philosophy like some of the other flavors of agile, but it's been pretty widely accepted across, ah, a lot of software development teams. It's also in Microsoft Dev office, which is one of the more popular,
uh, development areas
It is a pull method of work as opposed to a traditional
waterfall command and control type of pushing system. So what I mean by that is, traditionally you come into work and your boss would tell you you're going to do this thing for the next few weeks. Or here's your assignments for the week or whatever the case might be,
and you still see a little bit of that with Conven. But one of the advantages is it allows the developer
for the software programmers to pull work as they need it as they're running out of work on Japanese. And it translates into visual signal on the idea behind that is
in the 19 eighties and 19 nineties, when a little bit of seventies, I guess, to when the Japanese car manufacturing really started to compete
and in some cases surpassed the American automotive manufacturing. One of the things that we did when we studied how they were able to be so efficient
was they had these small little bins and what they would do instead of ordering, you know, hundreds of thousands of parts or a whole year's worth of supplies there. In some cases, they were having multiple deliveries to the Manu to the to the factory floor
every single day by the vendor's,
and what it allowed him to do is one and tie up a lot of money and inventory on and to they would be able to change their manufacturing processes faster in the event that they found a defect or something, had it had to be shifted. And so what the workers would do is they would be
get items out of the small, little been little combine been.
And when that been started to get low, another worker would replace it and then go back to the back of the house if you will, and actually reload the bins. And so they were able to use what what's called just in time inventory, and it's a lot more common now than it was
back in those days. But it was the way it was, a way to design and build cars
the same way that supermarkets stock shelves. So if you think about it,
regardless of the quantity discount that I can get what I'm going as a grocery store, I'm gonna go buy bananas if the bananas go bad in the store that I've just wasted that inventory of wasted that money. So my goal is to have exactly or is close to exactly the number of bananas that are going to be purchased that day
in my grocery store and then get resupplied
later on. And by applying those principles to an agile development project, it helps eliminate bottlenecks. Because
human nature is one of those things that's not
well understood. But there's certain elements that we do understand. And one of the things that and why they studied it and reported on is basically workers.
If they're given a time to complete a task, it will take exactly how long that you gave them
when I mean by that is, if you assign a student a paper that's due in two weeks, it's gonna take him two weeks to do it. If you assign a programmer, a feature to build in two weeks is gonna take them two weeks to do it.
Eso we just does How kind of our procrastination nature so by allowing the workers to pull the work,
what it allows me to do as a developer is Aiken. Build something, test it, make sure things working right and then say, OK, we'll have now. I've got some dead time.
Rather than do something unproductive, I can look and see I all these other items that I could be doing and that I can pull those items out of the backlog and put it into my current sprint. Or and again, you can cross moved in e
agile with other types of
project management and all product management.
in essence, what we're able to do is
continue to push new backlogged requests and new features as management and stakeholders or product owners or whatever. You basically just keep throwing these things in there, and
as developers, when you completed your work for the day or for whatever and you have nothing left in your to do been, then you can go into the backlog and start pulling Mawr items in. So I'll show you a little bit here using Dev ops.
And this is just a little sample
where it shows that, you know, these are the items that have been approved for development. So I want to work on that. Say, I want to work on this one today. I could drag it over here and start working on it.
you put it into production, which would go over here now. My test bucket is empty again, and I can go grab some or and by Vice a versa. Under the evaluation column here, you can have the project manager or the project owner continually load new items in there,
and you'll notice that they have these little numbers. And these were just kind of estimated effort points, and we talked about that earlier in the course.
It doesn't correlate necessarily into anything in particular. What it is is just a way of
estimating on a scale of whatever the team chooses. 1 to 10 125 how hard they think this is going to be. And if you're using convo on boards and I'm pulling the work and let's say that I think I can do 10 units of work per week and I'm actually doing 15 units of work because I'm able to
gather MAWR work on my own without waiting for someone to give it to me.
Then the forecasting process actually gets better, because then I could go back during my sprint or my quarterly build cycle. If I'm doing the STM and I can say OK, on average, Kane is doing 15 units of work a week,
so let's have our project schedule reflect the fact that I'm able to produce more stuff,
so that's kind of a quick example of how combine board works. But the more important thing about it is again that there's a principle of it,
as well as the fact that is not necessarily technology dependant, but it's very often thought of as a tool. So you can down there freeware software that you can use. There's cloud based software that you can use most project management software. It will have some form of
conv on boards. And it's just one of those things that allows the work structure to not be dependent on the manager toe. Actually go in and assign the work
which the Mander can still do. But it just allows you to actually meet
well. Usually, a team doing combine will try to meet once a week or once a day in the morning, but they're usually very short meaning, so it's more if you're doing him daily, For example, you get the team together and basically would say, What do you want to do today? You grab your little post it note item, stick it on the to do or the in progress lane,
and then go ahead and get it done, and then you could go back and get Maura and so on and so on. So it's just
much more organic than a traditional waterfall, and it also avoids a planning that's required to build a complete work breakdown structure with combine. You don't have to do that. You can basically just as a as the business owner or the project manager. You could just throw these things over the fence.
And as long as you do a good job of describing the user story
or the use case or whatever you wanna call it, then the developers should be able to build it
and and keep moving forward.
So in today's video, we completed Module three with the lesson on Kon Bon.
Thank you very much. Help! Everybody has a great day.