AGILE versus WATERFALL Project Plans

so the difference between agile and waterfall comes up all the time and some people prefer waterfall and some people prefer agile really what we're trying to do is to get a project across the line

and so today I wanted to talk about the difference between waterfall and agile project plans and the different tools that we're going to be using in each of those project plans so the differences

but also how they are the same now the thing about this is we don't get a free pass on our project just because it's agile or just because it's waterfall we still have to go through and manage each

of these items from the scope the stakeholders the schedule the cost the quality all of these things we still have to manage as we're delivering a new product all right let's get into the

differences between agile and waterfall project management plans and we're going to start right at the top where we start in a normal project we usually do that with a business case where we come up with the business case to figure out the

pros and cons of starting this new product or delivering this new product we start with a project Charter as well so our project charter down here where we uh get the official kickoff of our

project from the project sponsor so we get resources and funding we might have a change control plan where we outline our Change Control approach usually that will have to go to a change control

board when we're making changes on our project so we outline all these things early on in a waterfall project the configuration management plan for Version Control so how are we keeping

versions of our system under control benefits management plan and ultimately the project management plan that we plan up front with our scope shedule and cost

quality and all of those things usually in our triple constraint of scope schedule cost and quality in the middle there so all of those things we have to manage and we plan that all the way up

front but what does that look like on an agile project well there's a few different ways that we can kick off an agile project and the really all of those documents are sort of replaced by

a team charter and a highlevel model so we have a highlevel model of the system and what it will look like or what it currently looks like uh that can be done with a sequence diagram or some sort of

architecture diagram usually um we can also use a walking skeleton which is just a Bare Bones version of the system that we already have in place that we can then add features to now there's a

few other ways in agile and it's a bit more light on so less of this big planning up front but we can also use a business model canvas or a lean canvas lean canvas business plan where we're

talking about what the customer what the problem is that we're trying to solve the solution that we're coming up with and how are we delivering value so who is our customer what's our unfair

Advantage uh what are the channels that we're delivering through so this is just a good way of planning out and making sure it's basically like a business case and we could use that to plan out

features that deliver value to our customer on on an agile project because it is more customer focused it's really about the customer in an agile project now once we've done that we still have

to gather stakeholders and we still have to do that whether it's agile or whether it's waterfall but waterfall is a little bit more involved we might get our stakeholder register and we outline all

of the stakeholders that we know who are going to be involved in our project we might uh classify them by their stakeholder influence on our project and the impact that we're going to have on

their area and we also might do things like stakeholder engagement so who is the most engaged are they currently unaware but and we desire them to be

supportive for example and here are our classifications for stakeholders do they have a high influence and a high impact then we're probably going to need to uh communicate quite a lot with those

particular stakeholders so there's a lot of planning up front we can still use that in agile but again in uh in more of your agile projects it's a little bit uh less documented so less documents that

we're going through again we might use our team charter which has our high level Vision or Mission the background of the project then the team roles and stakeholders that we're going to work

with and the team values and then how we deal with uh communication and conflict and decisionmaking on our project we just plan that out how do we want to

work together as a team and also we just collocate our team so we have a small team who has all of the skills that we need to get the job done usually around

nine no more than nine people sometimes up to 12 but the smaller the better a two Pizza team I think they used to call it um so around 3 to n people is ideal

and we collocate those people so we can all uh communicate and work together quickly so again a little bit lighter on an agile project but still very people

focused and we still have to plan that out and and say this is the way we're going to be managing the stakeholders so once we've got our stakeholders we want to gather the requirements from those stakeholders maybe it's our customer

maybe it's our project sponsor maybe it's a senior user but we still need to gather the requirements for what we're delivering and in a waterfall project what are we going to do we might use a a

requirements documentation it's like a big document so a big requirements document uh maybe it's got all of the details written out really detailed um we could also use the requirements

traceability Matrix which has all of the requirements uh that the customers want and then how they match up to the scope and the test cases and where they

currently what their current status is so it traces those requirements to their completion as we go through the project

uh now funnily enough with agile for elicit requirements there's more things that we can do so agile is more more focused on people but also customer

requirements so meeting the needs of our customers so we there's sort of more things that we can do here we can go back and use the business model Canvas OR the lean model canvas uh to come up

with new feature ideas to make sure that they're meeting our customer needs we can also use things like the net promoter score for customer satisfaction so are our customers satisfied are they

giving us feedback can we take that feedback and turn that into requirements and uh turn that into requirements that we can then deliver uh for improvements we can also start with the high level

model uh or the model of where we're trying to go with our system so how is it and again this is an architecture diagram a sequence diagram there are a few different ways to do this we could

actually use prototypes or mockups or storyboards to show how it's actually going to look and that's a really nice way to do it we can also uh with when we're eliciting requirements we might

just go straight into test cases and accept it criteria so as a particular user what are the actions that we want to get this particular goal that's use cases or given when then is our

behavior-driven development way of writing out test cases and we might put those on our requirements user stories so as you can see it's more focused on

real things so prototypes uh but also focused on quality and testing focused on people and ultimately focused on the customer from an agile point of view all right now we've got requirements but now

we want to turn those requirements into the scope and deliverables for our project so what do we do on a waterfall project well we're going to have our high level scope description just a

written scope statement usually a sentence or a paragraph and we bro break that down into a high level list of features and the exclusions what's out of scope then we prioritize those things

so we might prioritize them using different methods Moscow is one way uh cost benefit is another way uh the cost of delay is another way there's many different uh ways to prioritize things

and we're going to use a similar approach in agile work breakdown structure so we take those high level features and we break those down into smaller items until they're broken down

into the activities or tasks that we're going to complete uh in order to deliver those items that's our work breakdown structure we're breaking it down decomposing those items to their

smallest level the work breakdown structure dictionary or WBS dictionary adds more items to our work packages so

those small level items now we're adding resources the cost of those items the uh the uh any dependencies of those items and how long they might take the duration of those items so that fills

out all of that information again we're doing a lot of that planning up front and ultimately we've got a work packages list a work package is the smallest level on our work breakdown structure

that someone or a team or a person can work on and complete and deliver so all of that planning up front what have we got from an agile perspective well when

we're managing and creating scope we want to start with our product backlog and a product backlog over here could be a list of epics which is our high level

features or high level ideas that we then break down into user stories over here so we've got our epics or maybe the products or the features that we're delivering and it depends on how you

want to break this down that's usually the way that they fit epics will break down into a bunch of user stories maybe 10 or 20 or 30 user stories and those

are the user stories that we complete during a Sprint and so we we do that that's similar to our work breakdown structure where we're breaking down the deliverables into work packages that

someone can work on so very very similar stuff we're going to use mockups and storyboards uh for our scope to show people what it's going to look like user story mapping is another way of

decomposing the item so this is where we walk through the system from start to finish and what are the features that we're adding so if we're in a bank bank app for example checking the account

balance uh what do we want to do there then we break it down what are the steps logging in Access our accounts and what are the details of those steps so we enter a username enter a password press

the login button and those are the things that we want to be delivering in our user stories in the things that we can deliver during a Sprint we prior prze those items from the product

backlog and also in our user stories we can prioritize those by cost benefit value or effort and again many different ways to prioritize particular items at

the end of our scope we accept that scope once it's been completed with the Sprint review so at the end of the two weeks uh we showcase and demonstrate what we've created to the customer and

the customer says hey that's exactly what I wanted or uh maybe we missed something here or it's not quite what I had in mind and but that way we get that real feedback again more focused on

people and customer requirements okay now that we've got scope now we can put that to a schedule when can we deliver that scope in waterfall how do we do it

well we get that scope and we break it down into an activity list so we've got our scope deliverable what are the activities that we need to do to deliver that deliverable so we've got our

project activity list then we put those activities on a we sequence them so when do they need to be what order do they need to be completed in and ultimately

we estimate their durations so how long are they going to take many different ways to estimate bottomup estimating parametric estimating uh threo estimating that you will find in the

pach guide and lastly we create the schedule itself which often looks like a Gant chart so we've got our deliverables and here is when we're going to be delivering them now from an agile point

of view we have what we call the product road map which looks suspiciously like a project schedule so it's very much the same if not exactly the same can be a

Gant chart so here's our feature here's our next feature next feature when are we delivering those features now it doesn't have to be a schedule it could just be a list so the ordered list the

sequenced list but again very similar to our waterfall approach we're also going to do Sprint planning so how many of these uh user story cards can we fit in

a Sprint that's going to match with the amount of work that we can complete in that Sprint so that's our Sprint planning if we can complete 50 points in a Sprint then we can potentially put 50

points in the next Sprint maybe that's five points per card so we can put 10 cards or 10 user story cards that's our Sprint planning so we've got our sustainable Pace we're matching it to

the velocity how how fast we can do the work planning poker is how we do our estimation where everyone estimates uh and maybe we say someone says one story

point someone says three someone says five someone says eight this the lowest and the highest discuss their reasons for doing it then we all estimate again until we come to a consensus and maybe

we end up with a three or a five in the middle there somewhere burn up and burn down charts is how we track our schedule in agile we have let's say here we've

got to user story points over our Sprint and we're going to complete that on an Ideal Trend but here's how we're actually tracking so that's our burndown chart and maybe some bits get added and

then maybe at the end we complete them all or maybe we don't finish them by the end of the Sprint but that's our burndown chart to track our schedule now that we've got scope and schedule we can

start looking at the cost of our project and this is great because in waterfall we're going to estimate the work packages we've got our work packages over here the deliverables uh and and as

we said the things that people can actually work on and create and deliver how much are we going to how much are they going to cost we need to estimate those things contingency and management

reserves contingency reserves for our risks and management reserves for any unforeseen scope and ultimately that gives us our approved baselined budget that's approved and then if we make any

changes to that it needs to go through our Change Control process so the change management plan that we were talking about but on agile we just have a fixed cost so let's say it's a million do and

that's a a fixed stable small team of around nine people as we were saying keep it nice and small and they just work for as long as that million dollars lasts maybe it's 6 months maybe it's a

year uh and they deliver as many features as they can from the product backlog and that product backlog uh gets prioritized by the product owner and

they want to deliver the highest value items first so highest value highest value highest value until they run out of time and run out of money and then

the project ends but on agile it's a fixed cost so it keeps it nice and easy now that we've got scope schedule cost we can start looking at quality how do we manage quality on a waterfall project

we use our test and inspection plan we test our we've got our deliverables and what are the test criteria that we're going to test those deliverables so how are we going to make sure that they meet

the customer's quality requirements do they pass do they fail usually we do those tests right at the end once all of our scope has been delivered so sometimes we do all of that work and

then we do the testing and then we find something wrong and we have to go all the way back to the beginning and do more of that work to deliver that all over again but from an agile perspective

we're doing small increments so we're testing as we're going every single one testing and delivering testing and delivering so there's no no need to go back it's all encompassed in the one

little feature or the one little deliverable we also use for Quality things like code inspections so we're pair programming or pairing up or side by side programming or just shoulder

checking the code or checking the code before it is uh accepted and goes into one of the environments for us to test we can also use things like test driven

development where we write our tests before we start work so on our user store card which is the thing that we're going to create our little deliverable

just like our work package we can start out saying uh and this is behavior driven development or bdd as a uh consultant uh then I want a sales button

for example and uh so that I can make a sale or send an email or whatever that looks like so that's the requirement and that's what we're going to test uh against on that user story to make sure

that it is accurate and complete we're also going to to do things like um unit testing for each of our user story cards we're going to test each of them with test driven development usually release planning so we'll plan for our feature

releases uh and the Sprint review at the end of our two weeks we're going to review those increments and those things that we've delivered with our customer to Quality check them with our customer

and make sure that they are what they wanted now of course on any project we still have to manage the resources on our project and so we don't get a free pass

on agile we still have to manage it on waterfall we still have to manage the resources so we need to estimate the resources required again we can estimate those for the deliverables that we're

delivering up here the scope and we might use thre Point estimating analogous estimating which is something similar like a similar feature we might

use parametric estimating which is a parameter like $100 per hour for example or $50 per meter for example that's a par parameter many different ways to

estimate uh we've got our resource breakdown chart or structure this shows our the resources on our project where do they fit maybe we've got the uh testers over here maybe we've got

developers over here maybe we've got business analysts over here and here they all are in the team so that's our resource breakdown structure and then we've got our RI or our resource assignment Matrix that we're going to

use this shows us all of the different people and what are they responsible for what tasks or deliverables are they responsible for on the project what do they do what's their role and

responsibility the resource calendar shows us things so when are our days off and when are our holidays and all of these things that are going to impact the time on our project and of course

back to our classic team charter what's the way of working for our team how do we manage conflict how do we manage decisions who are the stakeholders that we're working with and what are our values so those are the things that

we're going to use and funnily enough we use that on our agile project as well so nice team charter great way to do it with our agile again it's more people

focused and people centered so we're going to use things like the whole team approach this means we bring everyone we need to complete the features we bring

them into our team and those people we want them to be t-shaped people uh or generalizing Specialists so they have many different skills and many different

ideas uh and and talents but then one deep specialty so maybe that's developing for example but they've also got a little bit of design maybe a little bit of testing maybe a little bit

of business Acumen so that's what we want on our people wide range of skills but one deep specialty we want to collocate that team so that everyone is

in the same area easy to talk to easy to get answers we want an information radiator which is visual management so everyone can see what we're working on

and where it's up to and also pair pair programming or side bys side programming pair programming from XP or side-by-side programming from Crystal similar ideas working together and that just sort of

helps people focus and there's various things behind that maybe one person is coding the other person is looking at the strategy behind it and looking at ways to improve while we're working together now on our project we might

have to manage vendors and procurements probably more to do with a waterfall project many different vendors on an agile project we want to bring everyone into the same team of course so we might

do a make or buy analysis is it better for us to make it or to buy it from a vendor and what's the ongoing cost of that as well we're going to use things like the uh Source selection criteria

for our vendors how do we choose our vendors the qualified sellers list so we might have existing sellers in our organization that we can choose from uh the statement of work is just the list

of the deliverables that we want them to deliver independent estimates from maybe commercial databases just to make sure that we're not that we're actually getting a good deal that it's the right

price for the marketplace to check that against and we can make our decision on the vendor that we choose with multicriteria decision analysis so what

is the criteria that we're choosing them against what are the vendors that we're choosing and which ones fit those that Materia the best many different ways to

do this many different tools procurements can make uh a lot more work on projects so just be aware of that but in an agile project we're going to do a few different things differently uh so

with with our contracts we could do pay per feature so our contract might just be it's x amount per feature and we deliver those features until our money

runs out on a fixed cost we can also use fixed cost variable scope so our scope might change for example this scope might come out uh and this scope might

come in and the contract Remains the Same amount of money maybe whatever that is a million doll $100,000 $10 million $100 million uh but we prioritize the

highest value scope uh to always be delivered until that money runs out so fixed cost variable scope just like a normal agile project now with all of

this we've got scope schedule the re the stakeholders the resources any vendors we're going to need to communicate with all of those people across the entirety

of our project and on a waterfall project we might use things like a communication Styles assessment and a communication management plan so this one we just send out an assessment how

do our stakeholders prefer to be communicated with do they prefer reports do they prefer emails do they prefer a working group meeting do they prefer daily standups maybe we want to work a

bit of agile what is that preference and we make sure that we try and meet that preference with our stakeholders now from an agile point of view it's more

involved here because agile is all about communication people communication and meeting those stakeholder needs customer needs so we want that open Team area so

we've got our open Team area with all of our uh project information on the walls visual management so we can see where we're up to just by walking through our

team area nice and easy but also these ceremonies so the daily standup the 15minute session so 15 minutes every day we catch up as a team how are you going

is anything blocking you what are we planning to deliver for the next standup the retrospective at the end of our two week Sprint we catch up as a team and we

say what's working well what's not working well uh what is uh what still puzzles us and what did we learn uh and so we look at all those things and we

take that and we improve our process as we're going along Sprint planning is how we plan our initial two we Sprint so remember we uh take the 50 story points

or however it is however much it is that we can deliver uh and we say okay we've got 50 story points worth of cards and we can put those into the next Sprint so

that it's a sustainable Pace we're not overloading our team but we're not underwhelming them either so it's sustainable and then lastly the Sprint review where we're catching up as a team

demonstrating the real product that we've delivered during those two weeks to the customer so they can see feel and touch it and make sure that it's on track all right now risk we still have

to manage risk whether it's waterfall or agile it's the same thing we on a waterfall project we're going to use a risk register brainstorming risks with our team we're going to uh use things

like risk categories which is our risk breakdown structure we might have technical risks management risks commercial risks external risks or any other category that you can come up with and then brainstorming risks within

those categories so it's a nice way to do it risk definitions is how do we Define the likelihood and the probability of those risks happening so

what does it mean to have a high probability well maybe it's a 70% chance of happening or maybe it's going to happen every uh 2 days uh so that's a

high probability how do we Define that uh and risks are also classified by probability and impact and the highest risks are obviously with the highest

risk highest probability and the highest impact if they do happen so we don't get a free pass for risk even if it's on an agile project we still need to do it

with our risk adjusted backlog all we do we still brainstorm those risks with our team but then we put them into our backlog and we prioritize those against

the other work that we're doing so if we've got these risks and something is really terrible that we need to get taken care of straight away we're going to put that into our Sprint uh when we

do our Sprint planning so now it's a risk adjusted backlog because we're tackling risk at the same time as we're delivering value pretty cool stuff I like that uh and lastly of course we

still need to transition it to operations uh and with waterfall once we've delivered everything uh and we're handing it off to business as usual we might use things like change management

organizational change management so what's the change what documentation do we need what training do we need or what communication do we need to transition

this back to the business that we're delivering for but on an agile team we don't really have documentation or or we try not to not a lot of it anyway so how

do we we get around that we we use small features that we're just delivering incrementally so people would get used to it as they're going along quite simply the customer is also already a part of the team and they can pass on

that information to the other customers or the other senior users or the other parts of the business and also we could use just use good user experience or good ux design where it's easy to use

and we don't need a high amount of documentation so little bit more work to design it well but ultimately that's going to be better because we won't have as much documentation and so all those

are all our 12 steps the PM success steps a wonderful way to do it and as you can see whether we're planning waterfall or whether we're planning agile we still need to use certain tools

some are more people focused and some are more documentation focused but either way we still have to manage all of these things as a project manager so I hope you've enjoyed this I've had an

absolute blast and I'll see you in the next video