Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4

Video Transcription

00:01
hello and welcome to less than 5.6 our video lab on executing a con Bon project.
00:10
I'm your instructor, cane. And don't forget that I have a webcam in my face. So if you see me doing the old bob and weave, that means I'm trying to look around it at my monitor. So let's talk about executing a Con von Project.
00:25
Interestingly enough, I found out today I most today years old when I found out that one of the individuals that I went to dive school within the military
00:35
is now the director for sales for this Reich organization that does project management software. So it's a small world of the 15 of us that started, and he and I were the only two they graduated, which goes to show you out
00:50
small. That world actually is. So now we're both in the project management space, which is kind of cool.
00:57
Anyway,
00:58
let's talk about building an executing a conv on project,
01:02
so using this particular tool, it's pretty similar to Dev ops in the sense that you can add items to the backlog or the to do list, and we're using con bon boards because
01:14
We don't want to necessarily structure ourselves and have these formalized sprints and formalized project management processes because they want to be agile. The upside to using
01:26
combine boards Asking a project that way is you can also use sprints. Um,
01:33
and you can still use other agile methodologies while using the conv on board
01:41
tool and processes and actually really like this particular software tools, because for those of you that are more traditional project managers,
01:49
you can bounce from the conv onboard over to a normal Gant chart. And once you've put in the dates
01:57
that you're going to be working on thing than the various dependencies,
02:00
then you can still have a relatively traditional project schedule while being able to leverage agile, using convo on boards. So
02:10
we at times to our to do list
02:15
like you normally would
02:16
and then remember, because I'm using the pole system of work
02:22
as the execute er of the task.
02:25
I'm going to bring it to me, assign it to me
02:30
and then work on it, complete it and move it over. So,
02:35
um,
02:37
if
02:38
we're using pure Kon bon, what that means is, knows friends. We're not using scrum This is the only agile methodology that we're doing. I'm actually move all this stuff over here.
02:49
Um, okay, so say that's done.
02:53
Every day when I come into work during the execution phase, I'm going to look at the items that are in the statute
03:01
log
03:02
and it
03:04
I as the developer and going to decide
03:07
what I want to work on right now. We also can look at prioritization so we can have things be high priority. This one will be a low priority. I already mentioned that I would have to bob my head a lot for this.
03:21
Ah, that's normal. Okay, fine.
03:23
This one's also low. So if I came into work on a random Tuesday
03:30
and I was looking at my to do it, uh, swim lane in the convo on board, I would see that to do item number two is probably the one that I want to focus on
03:39
just because it's a high priority and the other ones or not.
03:43
So I would say, OK,
03:44
I'm going to go ahead and start working on that.
03:47
So I grab it and run or I'm the developer, not the product manager. Nobody's necessarily telling me what to do. I've been given strategic guidance by the project manager or the product owner.
03:59
There's different titles, but it's basically the same
04:01
function.
04:03
And
04:04
I'm going to didn't say Okay, I'm gonna go ahead and start working on this,
04:09
So I'm gonna go ahead and open it up.
04:12
It may not Let me is Yeah, I've been assigned to myself. I'm the only one in the project at this moment. So not really exciting, but I can also put in your comments things of that nature I can put in. You know, when I want o start working on it, I can set it due date for myself. Like, OK, I'm gonna have this done by Thursday
04:30
and then Good. And close that out. So now I've got my to do item that I'm going to be working and notice.
04:36
I'm not getting
04:39
mawr to do items because burn I using that sprint methodologies is pure Kon bon.
04:45
So I'm just gonna be working on one thing at a time until it's done, and then I'm going move onto the next thing.
04:50
So this is my new item. It's whatever. I'm gonna write my code in the development environment. I'm gonna work on it,
04:59
do my own individual testing at the developer, and I think it's good to go. So now I'm gonna move it to,
05:05
uh, the done pile
05:08
and this particular set up here, you could say that you're done pile is actually production, In which case I'd want to add additional swim lane, probably for the user acceptance testing or you leave it over here, and I Once I complete it, I notify somebody or I reassign it, which is another
05:25
techniques. So I've decided to myself,
05:28
I've built the thing.
05:30
Once I built it and put it into the test server, I can then assign it to somebody else, and they have them be notified via email that they're going to test it or that we I need them to test. There's either way. But the point is,
05:44
that work is flowing from that pool system, right? So Okay,
05:48
I've done that item, and now it's complete.
05:50
It could be
05:53
done early. Done late. Whatever. Doesn't really matter
05:57
what I don't wanna have as a developer, I don't wanna have a
06:01
empty swim lane for the things that I'm working on for obvious reasons, right? I'm not. Unless I go on vacation, I want to be productive
06:10
so that I'm gonna go back to the to do item, and I'm gonna look and see what other things here
06:15
are pressing. So these air low priority, I'm not gonna worry about them.
06:19
I'm gonna go ahead and grab one of these normal items, and then I'm gonna start working on it, so I'm gonna sign it to myself,
06:29
Take ownership of it again, put in whatever comments, questions or whatever I have.
06:34
And then that's my thing. I'm gonna be working on. So then I started working on it
06:39
and let's say that I'm working on it and
06:42
I get an email or some for notification from the product owner or the customer that whatever that thing was, we don't want that anymore. Right again. We want to be able to respond to change, even though I've got it. 99% complete about to write my last line of code and be done with it.
07:00
It is cancelled, is canceled.
07:02
You know, the customer says they don't want it anymore. Fine. Go ahead and throw it under the cancelled bucket and go back
07:09
thing grabbed whatever the next thing is going to be. So I'm gonna grab this send report.
07:14
The key element here is
07:15
as a developer,
07:17
nobody is telling me what to do.
07:20
I'm looking at the vision of the project. I'm looking at what's in the backlog or the to do list, and I'm making the terminations based on that,
07:30
that's the essence of the pool work system. So if you add in, say, scrum and you add in sprints,
07:40
then you're
07:42
taking items out of the backlog. And you're putting him into this particular sprint, right?
07:47
Not exactly a pull system, because you have a product owner that is pushing work to you based on what they think you need to be doing. So true. Kon Bon execution is
08:00
very little interfacing, although when you have meetings and stuff, but there's very little direction
08:07
being given to you
08:09
by your leadership on what you're gonna be working on the upside to this. As you can imagine. If I've got 10 15 developers working on a given project,
08:18
I don't have to manage their bottlenecks. I don't have to worry about the fact that Cane is sitting around
08:24
doing nothing because he's out of work for the Sprint. Any is not proactive enough to go and talk to one of the other developers and pick up work from them.
08:35
Um, so
08:37
it is a good way of looking at an agile project from almost a leader list standpoint. Leader set the vision. The leader sets the priority. The leader
08:50
gives information guidance over to the developers on what they should be working on. But it's actually the developers that determine
08:58
this friend velocity. They determine the
09:01
how much work they can get done.
09:05
And as research has indicated, this type of behavior actually does make many mature teams more productive because there's not that idea that why I've only got these five things to work on this this sprint.
09:20
So I'm gonna work on these five things I'm gonna take. My time is not gonna be that hard.
09:24
They're constantly pulling work. And there's a good chance that if you have
09:30
excuse me. Ah, big enough teen.
09:31
They're gonna pull work at a faster rate than what you would have signed work to them. So that's the essence of executing a con von project. So in this video, we had a video lab
09:46
executing a combine project. I got to play with the new piece of software for one of my friends. So that's always a winner. Um, so
09:54
thanks so much. And I look forward to seeing you at the next video, which is Module six. Our conclusion. Thank you.

Up Next

Agile Project Management

This course will introduce the history, applicability, and techniques used in various Agile project management methodologies. Agile has become one of the fastest growing and most popular project management methods throughout IT.

Instructed By

Instructor Profile Image
Kane Tomlin
Executive Consultant at FDOT, Professor
Instructor