For Kim Woods * CMGT 555 Week 2 WeLoveVideo Waterfall & Agile Project Flow
BrenReynolds80
Week1SDLCs.pptxSoftware Development Life Cycles
Presented by Brenda Reynolds
In association with
Matt Henwood and the University of Phoenix Systems Analysis & Development Department
September 13, 2019
We Love Video, Inc.
Welcome to the presentation guys, have a seat anywhere you’d like and help yourselves to some coffee and pastries. This is my bribe to you so you like me and pay close attention to the details I’m about to give you. Your fabulous company has decided to put a CRM in place for you guys, does anyone know what that is?
Kelsey: A What?
C.R.M. it’s one of many acronyms people in IT use.
Robin: Something about Customer Management?
Yes, can anyone elaborate?
Jesse: Customer Relationship Management, I used Salesforce at my last job. I have to tell you guys if this is what they’re doing for us, you’re going to notice a huge difference in how easy it is to find what you need on any customer.
Me: Well thank you for making my job a little easier.
<Audience Laughter>
I’ve done this a whole lot, so I already have a CRM in mind, and yes it will be Salesforce. I love that software for many many amazing reasons. What I want to educate you guys on today is the Software Development Life Cycle and of course there are multiples of those too. I’m going to fill you in on two SDLC’s, how they work, and why we will be using the one that we’ll be using. This is important because it involves you and how you’re going to help us integrate the new CRM into your every day processes.
1
Waterfall SDLC
See how this water looks like it’s on a mission to rush down those steps? Keep this in mind while I describe the Waterfall SDLC, more acronyms, I know. With the waterfall model we have some typical phases that comprise an entire systems project. Makes it easy, right? Just follow the waterfall down and you’ll get to the completed CRM. The reason I say ‘rushing’ is because the waterfall model is focused on getting the project done, get the requirements, get it done and get outta there.
On the next slide we’re gonna see what these steps look like, but does anyone want to take a stab at the first step?
Alyssa: Get the band back together and write down a plan. I can’t imagine computer nerds do this stuff without first knowing what the finished product is supposed to look like.
Me: YES! First and foremost we have to Plan. If we don’t have a plan, what are we building? Not even the best of the best “computer nerds” should start working on something like this for a company without a plan.
2
The typical phases that comprise an entire systems project
Agile
SDLC
Who can tell me what these guys are doing?
Robert: PARKOUR!!
Me: Wow, you must like the thrill of being able to do this stuff. What word would you use to describe someone who has the ability to do this?
Robert: Adventurous, thrill seeker, well trained
Alyssa: Dare devil
Me: This is awesome! What about flexibility?
Audience: yes, that works, of course, yeah…
<Click>
Remember we’re talking about software and the life cycle of something we’re building for you guys. So while we’re building the CRM for you guys, if something changes in the way the company is run, or if someone thinks of different requirements that need to be incorporated within the software back from close to the beginning of the whole system; don’t you want us to be able to go in and change how we’re developing it?
Audience: Well yeah, that only makes sense, can’t that be done at the end?
Me: So we don’t want to do something like that at the end because then we may have to change so much more than say just adding a wish list for specific customers, or adding a field to describe what this particular customer tends to gravitate toward as far as genre, or actor/actress.
The waterfall model leaves no room for changes, it focuses on getting the plan together, then doing what it takes to get to the implementation phase with the finished product. This method is called Agile for a reason. It’s very flexible in nature, changes are accepted throughout the coding process and the CRM will be designed in segments to make this easier for the programmers and also for you guys to be able to see what we’re looking at. If you can see where the design is going, then you can visualize what you would do next, or what information you know your customers either want to know, or what information would help you to help your customers in the future.
3
Waterfall & Agile
Lets summarize the Waterfall vs. the Agile Software Development Life Cycles with this visual.
Here is the waterfall method. You see the 4 steps in development, it’s pretty straight forward. First we discover what we need and why we need it. Then we plan all the details of how we put the what and why in to place so it can be used logically. Now that we have the plan, we build. Its like a bridge, get some measurements, buy the material and get to work. Essentially. After the build, we review and practice using it so we know for sure that it does what we built it to do, and we get it out to you guys to start using it.
“Waterfall project methodology is a model in which every stage of a product’s life cycle takes place in sequence. The progress flows steadily downwards through these phases like a waterfall” (Kukhnavets. 2016).
Remember how many little circles you see here, just 4 right?
<CLICK>
Now, see the 4 circles again and again and again? With the Agile methodology, we go through all the same steps, get to work and complete the phases as we do with the waterfall method. The difference is that we do this in chunks, present what we have built and see what needs to be changed, added, removed or anything else you can come up with. We do this several times making this methodology flexible, like our parkour guys.
“Agile software development methodology is the model that proposes a sequential, linear and iterative approach (Kukhnavets. 2016).
4
The differences in documentation produced, with an explanation as to why it would or would not be used
Documentation!
You’ve all heard that no matter what your job is, document, document, document! There is no better backup to your story, or your customers claims/wishes/plans etc. than proper documentation. Code is the same way. What you’re looking at here is real code written in Java. I imagine Java was named this because it took a whole lot of it to stay awake to create it.
<Audience Laughing>
See the part at the top with the slash star star? You can see that the short paragraph is written in English all the way down to the last star and slash. This is the documentation for the block of code to follow. You know it’s code when you can no longer actually read it.
<More audience laughter>
No matter what you always want to document your work as though you’ve won the lottery and moved to Spain for an early retirement, and someone new has to be able to come in and take over your job as if you’ve never left.
Now that you know why documentation is so important, and what it typically looks like when written for the benefit of the next programmer, lets see if agile and/or waterfall would or wouldn’t document.
5
To Document or not to Document?
That is the ?
With the Agile methodology, the documentation is going to look something like what I showed you on the previous slide. It’ll either be in the code, or maybe it’s written as a separate document, but still done in the moment that block of code is written to keep things simple. “Documenting in parallel with development makes it easier for engineers to answer questions. They are still in the thick of development, so they can explain their work without going into the archives” (Thompson. N.d.) Ugur Akinci states that ”technical writers learn how to write in short modular topics rather than long chapters” this is because “unlike the waterfall model [agile model] does not require the traditional thick A-to-Z PDF volumes but short descriptions” instead.
We’ve already decided that documenting is necessary, no matter what you’re doing especially if someone may one day take over your job unexpectedly. Unless long term care of your pet rock is the only thing you have going on in life, someone somewhere is taking over for you in some aspect. <audience laughter>
I know we’ve touched on this already, so let me ask you this; when you have a customer on the phone, or in front of you, and you’re in their account, when do you document? Do you wait until that customer has called, inquired, waited to make a decision, called back, asked more questions and eventually made their purchase and out of their return window? Probably not. I imagine you note their account when they call in every time, when they make any type of purchase, you not their wish list at the time they tell you and you document everything you can because it helps you help the customer. Even if they’ve changed their mind later, you still want that documentation that shows where their thought process came from.
6
Stakeholders
Who are they,
& how do we handle them?
It’s all about ME!
First, who are the stakeholders that we have to answer to? What will their concerns be and how do we get around this before they become concerns.
Well first we define stakeholders as anyone that has a “stake” in the production of the software. So yes, you are stakeholders for the CRM we’re creating for you. If you have any concerns, lets talk after this short-ish presentation.
<audience laughter>
As you can see from the glowing text here, stakeholders know this phrase well “It’s all about ME” If you remember this, notice that the word ME is in caps, which means it means something special. ME stands for Managing Expectations. “The job of Project Manager, then, is to SET and MANAGE stakeholder expectations throughout the project. This translates to defining and defending scope, identifying, analyzing, planning responses and monitoring and controlling risks, proactively planning and delivering Quality, etc.” (Baker. 2006). Managing expectation with stakeholders is key, if they don’t know what’s going on, or if they don’t have their vision validated, then the project gets dumped.
Rob: So if we’re stakeholders in this project just because we use it, does that mean that we have a say in the types of information we collect? Or how the whole process should be implemented and used as a team vs. individual sales associates?
Me: Yes, yes you do. You see, to us, you’re not “sales people” per say. You’re the main customer for us because if you don’t use and love our product, then we’ve failed.
You need to tell us when the project should be done, or at least collaborate with us on that since you don’t really know what all goes into the build. You tell us what the CRM needs to provide to you. Not necessarily what information it needs to collect, but if you know what the outcome is that you’re looking for, we can get to the nitty gritty of how to achieve that.
Kelly: But what if we don’t know anything about writing programs?
Me: That’s actually better than knowing just enough to be dangerous. For us, if you think you know what the back end needs to look like, or which applications to run, you’re probably a YouTube fan and you don’t know enough about enough to keep this project running smoothly. To be fair, the team we have building this has a lot of combined experience. A whole team with multiple years of experience in various platforms and backgrounds is a lot better at deciding how to reach your desired results. The part about keeping your expectations high and keeping you satisfied is about checking in and ensuring that all your needs are being met, even the ones you think of later. For example; you know this is for a Customer Relationship Management system, you know we need to keep a lot of data and you may even know some of the reports that can be run with this data. If you think of another report, or another marketing idea that can be beneficial to your sales team, but you’re missing one small detail… well too bad because we’re already in the middle of the build, right?
Cassie: Way to get our hopes up, Mrs. Bren!
Me: Actually, with the Agile methodology once we meet for the scrum sessions, you just let us know what you need and we’ll adapt to you. Sometimes the things we do, give you other fresh ideas. We know that and we’re here to accommodate.
So you expect us to get our deliverables to you in a timely manner; which we’ll basically give to you so you’re not expecting miracles. <audience laughter>
You also want us to document the software, it’s features, functions and uses. You’ve got to know what you’re getting and how to use it correctly. On the flip side of this, we also have to make sure that we’re implementing change control. What that means is that changes that you guys bring to the table are still okay, we just have to adjust for varying conditions and add additional time or make other changes so we can ensure we’ve done everything we’re supposed to do, while keeping a clear straightforward expectation to you for our deliverables.
7
The pros and cons associated with each waterfall and Agile SDLC
“Advantages of waterfall model: This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. ... Waterfall model works well for smaller projects where requirements are clearly defined and very well understood” (TryQA.com. N.d.)
Pros for waterfall method are plentiful as long as the project is small, concise and can be planned out with 100% details from the beginning. The waterfall methodology is great as long as the project is small enough, but this CRM for We Love Video is going to be a pretty big deal.
As you can see the waterfall on the left has a few precise steps, Requirements, Design, Implementation, Verification and Maintenance. No matter which waterfall design you find online, the steps are all pretty much the same, and they’re all fairly set in stone. Once you finish one step, just like the water, you drop down to the next step.
The agile methodology is an incredible loop as you see here. From the bottom up, we start with analyzing and planning, then over to design, testing and deployment, and finally the best part of the tiny little lifecycle. I say tiny because compared to the entire program, this is going to be a small portion of what you see. The absolute best part of the agile SDLC is that we get your feedback, the feedback of the stakeholders who’s daily work lives will be dictated by what this software can or cannot do for them.
As you can see, there are more differences than there are similarities in the 2 SDLC’s. For what we want to accomplish, we need to be able to make changes, get feedback, develop in smaller sections and in groups. We need to be able to keep everyone informed as we go along, is everybody with me? <audience gets excited.. .YEAH!>
8
AGILE
WATERFALL
A graphic summary or chart comparing waterfall and Agile for the WeLoveVideo, Inc. CRM project, including features, team, delivery, and feedback Attributes within WeLoveVideo, Inc. that would dictate your recommendation on the type of SDLC you would lean toward
“The problem with the Waterfall model is, if anything goes wrong, if the product does not pass testing and QA, or if the customer is not satisfied, 9 to 18 months of effort is lost, whereas in Agile only 2 to 3 weeks of effort is lost. That’s why the SW world is shifting to Agile model of development at an increasing pace” (Akinci. 2018).
As you can see from these graph, the ability to change is a necessary part of our CRM development, and the waterfall method doesn’t really offer that, or at all. The risk involved with the waterfall methodology in a larger project is pretty high, and not just because we don’t have the ability to get together and make sure we’re still on track throughout the process, it also has a lot to do with the fact that We Love Video wants to have this implemented as quickly as possible. The waterfall method has a typical turn around time of around 9 months or more. The turn around time for agile, even with all the sprint sessions is drastically less. So as you can see, the waterfall method may be good for smaller projects, but as we decided before, the Agile process is what we’re going to fall in love with.
9
I want you guys to think, ask some questions if you have any. And if you can’t think of anything right now, I want you to keep my phone and email and let me know when you think of something.
(1975 was the room number she was born in and also the year she died)
10
References
Akinci, Ugur (2018) Waterfall vs. Agile Methodologies in Technical Documentation Retrieved from https://medium.com/@technicalwriter/waterfall-vs-agile-methodologies-in-technical-documentation-473f60240fb7
Baker, Ernest (2006) It's all about ME (managing expectations)! Paper presented at PMI® Global Congress 2006—North America, Seattle, WA. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/managing-stakeholder-expectations-proactively-define-7984
Kukhnavets, Pavel (2016) Agile vs Waterfall: Pros and Cons, Differences and Similarities Retrieved from https://blog.ganttpro.com/en/waterfall-vs-agile-with-advantages-and-disadvantages/
11
Thompson, Tom (n.d.) Why agile teams should care about documentation
Retrieved from https://techbeacon.com/app-dev-testing/why-agile-teams-should-care-about-documentation
TryQA.com (n.d.) What is Waterfall model- Examples, advantages, disadvantages & when to us it? Retrieved from http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
References Cont…
