6.2 Organizational Structures and Agile Planning Part 2
6 hours 23 minutes
from a practical standpoint, we went ahead and we built a truly waterfall schedule. We looked at one for making a cup of coffee. We looked at one for our software project. Now I want to show you how that differs between a true waterfall in a true, agile. And there are numerous ways to,
schedule an agile project. There's scrum and combine and all kind of the different ones.
But just know that what we're focusing on is, rather than telling
the staff the work that they're going to do, we're providing them ACU, whereby they can work on what they think is going to be the best. And this is generally a better way to go for your mature, more mature developers and project teams and whatnot.
So if you'd like to download the software that I'm using its meister task dot com.
Otherwise you can feel free to use any agile scheduling software that you have, Whether it's Jura or something else, there's there's a lot of them out there, but I just want to show you the difference between your agile and your waterfall very briefly. So this is a con bon board
and you can also kind of use it for individual sprints. So what you've got is you've got your four swim lanes of things that are backlogged things that I need to work on over the next sprint, which is typically two week period of time
items that are currently in progress as and I'm working on them today and then items that are done. So in this fictitious project here we have course, the developing of the project charter is complete because we're doing sort of a hybrid were planning ahead, right? But now that we've planned ahead, we've got a list of features
and things that we want this software to do,
and they all start off in the backlog. So, for example, I can click this feature number four Go put it in the backlog. Okay, so now it's back.
So today I come into work. I see that I'm working on feature number two, adding it to my agile software delivery
feature. Number two gets complete. I built whatever widget that that needs to be, and I go and put it in the dung pile.
Now. I know next week during sprint number one, I have to work on futures number one and six.
next week comes along, we drag these over here, so let the developers know that those were the two that need to be worked on. And then we can change this to sprint number two and say OK for Sprint number two, which will be in weeks four and five.
This will be the next friend coming up. I decide that featured nine
and five are the best ones to work on. Actually, I'm gonna add future number seven because that when we don't think it's gonna take very long.
So in an agile environment, what you're doing is you're sort of learning as you go, you're figuring out what your capability of your team is to develop
and then adjusting accordingly. And you're keeping sort of a running back log of all of the things that
we definitely will not definitely All the things that we would like to have in this solution. You may I get them all. But you can, you know, ask for the moon and maybe you'll get atleast in a low orbit. So we're creating a very comprehensive backlog. All these features and this you say a Web shopping cart as an example.
All these features at my Web shopping cart needs to be able to do. It needs to be ableto, you know, track, user name and password, and you build at things to your card, adding to your wish list, the inventory, whatever those things are.
And then you decide how important some of those things are versus others. And that sort of determines the order that you drag things out of the backlog and put him into your spring.
And let's say that of these two features, I only got feature six Done.
Then I would potentially add feature number one back into this sprint number two that didn't get it done. And then it might have to demote feature number seven back into the backlog. So you see how this would happen,
say, every two weeks during every sprint, and we would slowly get better at both predicting and executing within this agile project. But the key thing about agile and course there's numerous course on Andros. I'm not gonna go too deep into it, but the key thing about agile is you want to deliver code to production
at the end of every sprint you want to deliver value to the customer things that the customer can see and touch so that first sprint may only be, say, the shopping cart and the
the items in the shopping cart or the items in the Web store that you're gonna order.
And then week three and four, you might get the user account information and then week number five, you might get inventory so you're you may not get it all right away, but the idea is at least I can deliver something that's usable to the customer at the end of every sprint.
So that's kind of a very brief, uh, demonstration of what an agile project looks like from a scheduling standpoint. And I just wanted to show you that compare and contrast to the different organizational structures because you could see that the based on the shape of your organization,
a more waterfall or um, or agile approach may make more sense for you
versus another. And then, of course, you have the hybrid, which some fall somewhere in the middle.
So in summary, we went over different organizational structures, and we talked about agile versus waterfall.
Thank you for your time. I look forward to seeing you in the next life