CCT 118: Integrated Product Team (IPT) and Waterfall, Spiral, Agile, Scrum Development (D8.1.2-8.1.5)

Are you prepared to navigate the intricate maze of software development and cybersecurity? This week's episode guarantees to arm you with the expertise to conquer the CISSP exam and apply these vital skills in the real world. We delve into the structures and strategies that define successful software projects, comparing the precision of the waterfall model to the flexibility of agile, scrum, and the hybrid vigor of the spiral approach. Our foray into recent cyberattacks on US pharmacies serves as a stark reminder of the omnipresent cyber threats and the critical role third-party providers play in cybersecurity risk management. 

This journey through the software development lifecycle shines a spotlight on the crucial stages, from system requirements to operations, all while emphasizing the significance of aligning with customer and stakeholder needs. I also share insider tips on selecting the right programming languages and development tools to match project needs and developer expertise. For those who favor visual learning, we've got you covered with insightful resources from my blog and CISB cyber training that paint a clear picture of these methodologies in action.

Finally, we cap off with an exclusive offer for our listeners pursuing CISSP certification: a treasure trove of 360 free practice questions, available over six months to elevate your study game. Sign up today to receive the first set of questions and unlock a personalized learning experience with tailored content that will guide you through the cybersecurity domain. Whether you're a seasoned pro or a CISSP aspirant, this episode is your gateway to mastering the ever-important intersection of software development and cybersecurity.

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

TRANSCRIPT

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started. Hey y'all, sean Gerber, with CISSP Cyber Training, I hope you guys are all having a wonderful day today. Today, we're going to be talking about some amazing aspects as it relates to software development, and this is in domain eight. We're going to be getting into integrated product teams, waterfall, spiral, agile and scrum development. What was some of the key topics that you would have with your trying to study for the CISSP exam. You're also going to understand this was from chapter 20 of the ISC squared book, and there's some key topics that we will be covering. So it's going to be an awesome thing for you to be ready to go. So just hang on, let's go for the fun. But before we get started, we are going to get into just something that popped up on the news yesterday, and this was related to some cyber attacks that happened against some pharmacies across the United States. Now, as you all are aware, obviously there's so much cyber activity occurring with on the internet and affecting so many different companies and services. This is one that just happened I just saw, it just yesterday and there's been a lot of flurry of activity that's been going on, but this one took down the change healthcare. What it basically is, from what I understand and again, this is just my slow understanding of it is it is a service provider for companies such as CVS and other pharmacies and therefore it's the kind of the foundational, it's the middle person between, or the middle company between those two, and it had basically what they were saying is it works by, it's owned by, united Healthcare and it claims to handle around 15 billion healthcare transactions each year. So I mean, that's a lot of transactions that are occurring within the United States itself, and so, with that many transactions in the healthcare industry, it would be a prime target for some level of ransomware attack, and it seems that somebody went after it. Now I've seen various articles around this stating that it was a nation state. I don't know. I think it's a bit premature for them anybody to say that at this point, because it could be anybody, but that was something that did come up. But one thing that's happened is it has been an enterprise level event that's caused a cascading effect throughout all of their different pharmacies around the country and as a result you've seen it there's been a pretty big impact within the United States. So CVS made a comment that they're working on the problem. They're saying that it could be down until potentially Friday, which is today as a recording of this podcast. So that's something that they're looking at as well. Another one is sure health out of Michigan had a problem as well. So I think it's just something to understand is, as you all are getting into the cybersecurity business, that it isn't just this is the third party. Suppliers are the people that are also affecting you Because of the fact that they're all intertwined and interconnected. It is an important factor for you to truly understand how your business works and also the third parties that may provide you services, because if they get hit and they end up taking you down because they can't do their job, then it ends up being a cascading effect. So something to kind of kind of think about as it relates to the CISSP is, when you're studying for your CISSP certification, what are different ways. You can use your experiences and your powers for good to help fix some of these challenges. Okay, so let's get started into today's topic, and we're going to get into the integrated product teams. Now, you may or may not know what this means. The one thing I've learned with the CISSP is the fact that there are so many broad topics that it covers just a vast, wide range of different areas that you but you may not be exposed to all of these. One thing that I actually wasn't exposed to. I read it in the book and and understood a little bit about the concept, especially when I took the test, but the one thing I didn't really truly understand is the overall concept until I was exposed to it with what I'm doing for a living right now, and as I understood the concept of an integrated product team, it at first I was like, okay, well, that makes sense on paper, but let's talk about how it actually can be worked in practice. It's interesting. I've seen this product team concept work very, very well and it seems to be one of those that has the merit that if you use it within your company depending on how you're going to use this in the environment that it could be used potentially very positively. So let's just kind of run over what is an integrated product team? Now, an integrated product team is a group of professionals from different functional areas. Now, what I mean by the different functional areas is you may have someone that's in IT, you may have someone that's within finance, someone that's within HR. They have different functional areas who work together to build the overall program. And if we understand Agile, which we'll talk about here in a minute, it's like an Agile program that's on steroids that encompasses maybe a lot more people than just your normal development team. Now these can be used really very helpful within the software development lifecycle piece of this, just because, as you're developing software, it's good to understand what are some of the requirements. It's also very positive to have these individuals that are part of the team be able to give you guidance and direction as you're developing a product or program, whatever you need. So there's really a good way to help it meet whatever the stakeholders. And the stakeholders are usually the folks that are sponsoring this event, and this would be someone within finance, somebody that's within senior leadership. They would be a stakeholder within whatever product you're trying to create, and so these product teams will have somebody from the stakeholders involved in them and, from an IT standpoint, having somebody that is involved from the beginning is extremely valuable for you to be able to make good quality content, good quality code in a way that meets the customer's needs, and that's what really the ultimate goal of creating code is to meet what the customer is looking for Now. It allows it to be developed in a timely manner which actually meets the needs of the users, and it's developed in a high quality manner. Now we want it to have it be consistent with whatever potential industry standards and best practices are out there and, being part of this integrated product team, it does allow you to do that and it allows you to ensure that you know we're the best industry standards are or the best practices are, as an example. So we'll say I have a product team that's set up and this product team has IT, it has finance, it has HR, it has someone from legal in it as well, and you go together, you're building out this program and you're going to put this program, let's just say, in Europe. Well, if you put this program, whatever you're developing in Europe, your legal people can say okay. So if we're putting this data in Europe. This is what we need to worry about from a data retention standpoint your compliance. People may say, well, this is what we need to worry about as it relates to GDPR or any other regulations that are coming up within that environment. So, as you can see, that is a big factor. Well, then you roll the IT people into it and they may say well, because we're operating out of Europe, it's one of those things where, if we keep the data stored within the United States, there's going to be some level of latency. So let's look to store the data in, let's say, ireland or in France or wherever you decide, and pick a point of where it's going to be stored, and it's bringing in all different parties to help you ensure that you're getting the best product developed. And you may think this is kind of intuitive, right? I mean, I've been doing this a lot of years and you go. Well, yeah, if you bring everybody involved, you get a good idea and you can come up with requirements and you can figure out what to do with this program. But what so happens so frequently is that they'll get a request and they'll say here's some work that we need you to do Well, it will go off and do it, but they won't really consult with some of the other parties to make sure they're getting the right product developed for that region. So it's an important piece that I think if you have an integrated product team, it can really help you get good quality product that does have some level of consistency across all these different areas. Now there's the various stages of the software development lifecycle are included within the IPT. This would be such as planning, design, development, testing and deployment. So we're going to kind of just real quickly walk through where do you see these at? So in the planning stage, your IPT can help define the scope of the project. Again, we talk about identifying the stakeholders, establish the goals and objectives of the project. So that's what you want to plan before you even get started and that's part of the IPT. So again, you'll see these as part of something that may come up in the CISSP exam. What are some various stages that you may experience related to the IPT? In the design stage, you they can help define the architecture we talk about. Where is this going to be developed, where's going to be set, identify the requirements and then also the specifications this comes into? Where am I going to store the data? Who's going to access the data? What form or method are they going to access this data by? In the development stage, you're going to develop the software exactly the way you planned it right. And then you're going to test it, ensure that it meets the requirements of the stakeholders and the goals that have been established. And then, in the testing phase, you're going to identify any issues and ensure that it has a high quality, for that the stakeholders, when they receive it, they actually have something that they can use and it meets the requirements that they wanted. Now we all know in the development world they're going to come up with a product and then this product. There's going to be changes to this product, but the ultimate goal with the IPT is that they are embedded with you from the beginning and they understand what you're trying to accomplish. And then they have a fully invested effort into making sure that this does occur. And then, finally, in the deployment stage, you're going to deploy the software and monitor its performance, ensure that it meets the needs of each of your users. So again, planning, design, development, testing and deployment. Okay, so now we're going to move into the waterfall model. Now I've got a. If you look at my slides, you'll see this. There are the video. You can go to CISB cyber training. You can go to my blog, and the videos are all posted out there. So they're all available for you to be able to go and study them as well. They'll also be on YouTube at a later time. I put all of them on my or on my website first, before they actually go to YouTube. Because why do I do that? Well, the ultimate goal is I want you to go to my website. That's why, right, so that there's marketing in all of this, right? The ultimate goal is to get you to my website so that you watch the videos and so that if you decide you want to purchase something, you can purchase something. If you don't, that's okay, because, guess what, there's free stuff there as well. But if you go to the website, you'll see this, the video. And the video is around the requirements, analysis, design, coding and testing and operations. That's the waterfall piece of this and we're going to get into. What does that mean? Well, it means that when you start this whole process off, it kind of cascades down. So you got it like thinking of it as a set of steps and these steps are steps that you walk up, you know right. So you go into a building. There's a set of steps. Well, if you put water at the top step, it flows down these steps and it just it's like a waterfall. It just goes down each of the steps to each layer level of layers. Well, there's six layers in the waterfall development method and that deals with requirements, analysis, design, coding, testing and operations. All of those are within the waterfall model and that is what ends up happening as it goes down each of these various steps. So look at that visual picture that if I'm developing in the waterfall model, it's a set of steps that I'm going down each time. The reason I said that is also I've got a design out there on the site that you can go look at and it's from oxagilecom. They give a picture of a waterfall method method. I was going to make something and like I don't have time for that, so I just grabbed the link that they have. But it's a really good site. It's got some good stuff about the waterfall method. Go check them out. They would appreciate that. I'm not really sure what they do out there outside of development piece, but something you can go. Look at Waterfall model again. So when a couple start with each of these blocks and we're going to go into what they do, what's the importance of them? So the waterfall model there's a system requirements. These are the first phase where the requirements of this systems are actually collected by analyzing the actual needs of the user. This step involves detailed communications with the stakeholders, the end users, and to basically understand their needs. Now, the difference with this is we talked a little bit earlier around integrated product teams. You can incorporate the waterfall model with the integrated product team. You can incorporate agile with the integrated product team, or spiral. You can do any of these with these integrated product teams. The key thing to understand is when this development lifecycle is designed so that when you come out with a product, you want to develop a widget of some kind, so a new app I want to develop for my company. If you follow the waterfall method, you're going to start off with system requirements for this widget and you're going to then what does the customer want? What do my stakeholders want, what are all the pieces in this? And then you begin the overall process around that, and that includes from the system requirements includes having meetings, analyzing the needs and expectations and then document the overall system requirements that are needed specifically for beginning this process Now. So that's the system requirements. The next is the software requirements. So now, once you understand what they actually want to do, what do they want to create you now need to understand what are the software requirements needed to give them what they want. So not all software is developed the same. So if you want to use something that is I'm just again, I'm not a developer. I'm going to put that out there right now. I have not slept at a Holiday Inn Express. That's a really old commercial but I can tell you that I've done a very little development and about I've led developers, and so what I'm saying is that Python is very different than C++ or C sharp. They're very different coding methodologies. Now they all have their need, depending on what you're going to use. So you may use want to use Python because, let's just say, for example, you're in the IoT market and you want to have something that's pretty lightweight and it's running on something that has low computing power. That is real easy. Python might be a good option for you. But if you have something that's a very robust site. You may want to use C, sharp, c++ or any of the dotnet frameworks any of those you may want to use, depending upon what kind of development world you're going to be getting into. The other thing to keep in mind from a development standpoint and again this was with me, with only my knowledge that I have leading a team, I've noticed that my guys have you can either go very robust, like we're using a dotnet framework, or you can go even into the WordPress environment and use something that's very it's much easier to develop in and it has a lot of scalability. But again, you have to understand what is the capabilities that you're trying to accomplish and what are your people, your developers, what are they good at? So the other part of this is when you're looking at your team, what kind of team do you need from development standpoint to recruit to run your development shop? And that might be something to kind of consider as well, because if you're trying to find new developers, sometimes finding people that can do in Python much is much easier than finding somebody that can do in dotnet, and they have different costs associated with each of them. So you have to decide which way you want to go. I know I went down a relevant of a rabbit hole there, but the point of him trying to make is the software requirements are a key factor in deciding what is the overall plan that you're trying to accomplish and based on what the stakeholders want to do. So in the software requirements you're going to translate the system requirements into software specs. You're going to document functional and non-functional requirements and then you're going to review and finalize the software requirements in a document themselves. So that's your overall thing. So you got system requirements, software requirements, and then you get into preliminary design and going back to systems and requirements and software requirements. This falls under the analysis bucket. So this is what you're going to have to do at the beginning. Once you get done with the analysis piece of this, then you're going to get into the design piece of this. So when you're dealing with design, you have both things. You have a preliminary design and you have a detailed design In the preliminary design. This is where you get the systems architecture and the design is specifically outlined. You put the preliminary design focuses on high level structure and design decisions. This is where you'll define your overall architecture for your comp or for your development piece of this. You're going to determine your major components and how they're going to interact. Do you have a cloud environment, do you not? Do you have an application that's on your phone? Is it a web app? Is it an actual developed application? You're going to determine that overall design and then you're going to design that, create the documentation that's going to be associated with that design. Then, once you do building upon the preliminary design, this involves a more detailed specification of the software components, which can include understanding the architecture a little bit deeper, understanding the necessary developers that you need to actually develop them, the product you want to have. Again, this comes back to am I creating a product, a piece of code that is going to be on something very lightweight for the IOT world, or am I going to be to have something more robust that may be dealing in the banking or financial sectors or potentially healthcare sectors? Then you're going to have to understand what that is a very different type of developer that you may need. So you may have to go out and hire different people for those specific tasks or go out and find a third party that can do that work for you. This will become down to refining the system. This is the architecture and design, develop them, detailed design specs for each of the components, and then documenting the specific interfaces and how is the data going to be stored and structured between these interfaces. Okay, in the next level of the waterfall method is you have to code and debug. So this is where you're going to be doing the coding and actual writing the code based on the design specs that you came up with. You're going to have to test the individual components for functionality and then you'll debug and fix any issues defined during the overall testing phase of this. So that's where you actually do the work, okay, and then you do your testing with it to make sure it runs. And then that's not the testing, but that's your basic compiling and then running it, debugging the problems, going back and fixing some of those issues, and then you move on to the next step, which is the testing method. So, once the coding is done, you've now moved into the testing piece. And this word meets. You want to ensure that the product that you've created meets the specific requirements. So you're in the code and debug area. You're going to go kind of do some iterative approaches to this to make sure it meets the requirements that you have. But then you're going to go out and you're actually going to. You're going to test it to make sure that the meets the needs of the stakeholders and perform the various methods as far as unit testing, integration testing and then system testing. The ultimate goal is you want to make sure that you give a product to them that they can actually use and it meets their requirements. You'll verify the software functionality against these requirements and then you will address or any defects that will be found during testing. So you'll address those specific defects that are there and you may be able to adjust those as necessary. Now the problem with waterfall is is you have to follow this cascading effect. If, for some reason, there's a massive design change, that has to occur because after the testing you realize ah, I really wanted to do X. Well, you can't just go back and start over. You have to wait till the end of the waterfall method and then you will readdress that in your overall testing plan. You'll make sure that that meets the backlog. Are they actually going to go and use this? Are they going to want to use this piece of requirement in the future? And they'll have to make a decision whether they want to do that or not. So you can't just stop it in the middle of waterfall and start over. You have to follow it all the way through. So, like water going on the steps, you've got to let the water continue down to the bottom of the steps. The next one is operations and maintenance. This is the final phase where the system is deployed and maintained. The maintenance involves updating the system to adapt the changes, deploying the software to a production environment, monitoring performance, and then performance updates and maintenance will be needed to address changes and improvements. So again, the operations. That's all of your six steps as it relates to the overall piece of waterfall Requirements, analysis, design, coding, testing and operations. And again, it's sequential. You have to start at the top and you have to go to the end. You cannot stop the waterfall method in midstream and then start over again. That's just bad, bad idea. Don't do that and that'll be one of the negatives that you run into when it comes to the waterfall method. Okay, so the next one we're going to talk about is the spiral lifecycle method or model, and this is again. There's a picture, a graphic that you can see on CISP Cyber Training. You can go to the video. Watch the video. It's theartoftestingcom. This is where this graphic came from. Really good graphic. It kind of talks about the different objectives and what we're trying to accomplish with spiral. So as I go through this, I would highly recommend you go back and refer to that or you go in the book and it talks about it in the book as well. And one thing I do like about the art of testing is graphic. It is a bit better, more defined than the actual book itself. Now, the spiral method serves as what they call a meta model, or a model of models in the software development world, and it provides a framework that can adapt to various types of projects, incorporating elements from both traditional waterfall and no more flexible iterative approaches such as agile. So there's some key components as it relates to spiral. It's an iterative development plan. It's repeating cycles that allow for incremental refinement of the overall product. There's risk management involved, which basically each of the cycles begins with identification, analysis of the risks, followed by development strategies to address those specific risks. It also has to have stakeholder involvement. Regularly. Involving the stakeholders will ensure that the involving product meets their needs and their overall expectations. There's adaptability, where the model supports incorporating new technologies and responding to changing requirements throughout the entire development process. So those are some key points. I can't say it. Iterative development, risk management, stakeholder involvement and adaptability. Again, those are the four main components that you're dealing with as it relates to spiral. So let's talk about the various phases of the spiral model. Now, if you go back to the graphic, phase one is you plan your objectives and you find alternate solutions. Phase two, you do a risk analysis and the resolving of these issues. Three, you develop the next version of the product. And then four, you plan the next phase. It just goes in that iterative plan. It just goes in a circle. It starts, you plan the objectives, you start, you do analysis, you develop, then you plan for the next phase. It just keeps going in this overall cycle to get where you want it to go. And that's kind of a key plan as it relates to the overall phases. Now, when you're dealing with those planning analysis and creating an overall evaluating, the planning defines the goals, the alternatives and the constraints for the iteration. It's the one that decides what you're going to do. Back on the waterfall. Same concept at the beginning. Your design phase is like the planning phase and it helps you define your goals, your alternatives, your constraints, and what are some, what are the constraints of the overall iteration that you're planning on trying to accomplish. Then you also, then you'll do a, the next phase, you'll talk about risk and we'll identify what are the risks and what are strategies to help you mitigate those other areas. Then, obviously, in the engineering, is your development phase. That's where you'll take your, you'll develop your code, you'll then test your product based on the iterative objectives that you did in the planning phase and then from there you'll get the feedback from the stakeholders and you'll focus on making the changes in the next spiral session. Now, again, the neat part about it it is a flexible, risk driven approach to development. It does allow for continuous improvement and that the part that's nice about that is or waterfall, like we mentioned, you have to go through all six steps to get there, the phases of the spiral. You can't again. You have to follow all four. You can't back out and start over again, but it does allow you do this to go through a much faster process potentially, and allows you to make these changes in a much quicker, more dynamic way and based on what the stakeholders may want. Okay, so we're going to quickly roll into the product called scrum and scrum is part of the agile product management framework and we'll get into agile here just right after scrum. So this may may add a little bit of context when we talk about agile, but when we deal with scrum, scrum has basically three primary roles and the scrum is part of the overall sprint planning process. I've used scrum multiple times. It's multiple times used, obviously, for like two years, but it's really good as it relates to the software development team concept and it is designed to guide teams in the iterative and incremental delivery of an overall product. And it does it. It's very, very useful. There's the scrum framework on top of the agile methodology. It does it works very, very well. So you hit the roles within scrum you have a product owner, you have a scrum master and you have the development team. So each of those are a key factor in the overall plan when you're trying to use the scrum and the scrum is based on the met, the outcome, what's the name of it? It's not, it's not soccer, it's out of the UK and I'm totally doing a blank on it, but it's based on scrum. On that cash I'm going to blank, but the overall goal is that it's a group of people that are working together to come up with a product. Now what happens is is you will have this sprint planning session, so you'll break this into. The sprint is a defined time which you start. So you start from start zero and you start off sprint zero and you begin this process, and typically these sprints are about a two week iteration. You can make them a week. There's a lot faster you can make them three weeks, but what I've learned is that about two weeks is about the right sweet spot to do a sprint when it comes to the software development space. And you'll do the sprint planning. You'll plan ahead of time what are you going to do in the upcoming sprint. So you have a day that you deal with the planning and what are you going to complete during this upcoming sprint. The then will also have what they call daily standups, which means you will get together with the team once a day in the morning for usually about 15 minutes, depending on what your development team is at If it's in the United States, if it's in India, if it's in China. You may have to move your timing when you do this, but typically it's beginning at the beginning of the day in which you'll do your sprint standup and it's for you to share updates and discuss any issues that you may have during the overall sprint. You'll do a sprint review which demonstrates what you've completed during the sprint and then you'll also, at the end of it, do a retrospective on what has occurred and how did it go. You'll look for ways that you can improve the next sprint during the retrospective and you'll look at maybe some things that caused some issues so right. You'll do a basically a lessons learned kind of meeting. So it's an important part of the overall process and it's an iterative approach as well. But you can define the time box in which you're going to run this sprint, which could be, oh, like I said, a week to two weeks, could be three, would not go beyond three weeks. It's way too long. Too many things change during that time and that's a one nice thing about the sprint was something that does change. You can make potentially some changes during the sprint If there's functionality with code that you want to do, whereas like the waterfall, you can't do so much. And even with the spiral, you have to follow through the spiral process. With sprint that you're dealing with the agile process. You don't necessarily have to do that. You could actually make subtle changes. But you got to be careful because real quickly you can make a change and it'll expand and blossom to the point where you don't get done the work that the stakeholders want you to do. So so we'll come back to that in a minute Scrum when it comes to that, you'll have three different topics. You have the product backlog, you have the sprint backlog and then you have the increment. Now the product backlog is a prioritized list of features, bug fixes, technical work, acquisition, knowledge and acquisition that you need to have. That is the product backlog. Your sprint backlog is a list of tasks that could be completed during that specific task or specific sprint. So you have a backlog. It's a long list of different tasks you wanna get done. You then take a subset of those and put those into your sprint and you will work specifically on those. That is the sprint backlog, and then an increment is basically the sum of all the product backlogs combined completed during the overall sprint one. So it's basically what did you get done during that time frame? Those are the key pieces to understand as it relates to scrum product backlog, sprint backlog and then the overall increment. Now the sprints. These again, these are worked into time box areas, called your sprints is what they call them, and again, they're usually a window of two weeks that you can then have a product that's out the door, it's been tested, it's been vetted, you have consumer or you have the customer has looked at it, it's done through some quality control and at the end of the sprint, they have a product they can actually use. Now the thought process is is, rather than chase many different things, you focus on a couple key pieces within that sprint and you get them done, but you look at the ones that are most valuable for your organization. If you go to the video, you'll see a graphic out there as it relates to what a scrum would look like. You have your sprint planning, your daily scrum, your sprint review, your sprint retrospective. Those are the four phases that you would have during your overall plan and that's it's a great, great product. I do like doing that. Okay, the agile methodology this is a framework that it breaks down projects into dynamic phases that are known as sprints, which we talked about, and it is an adaptive planning and self organizing for short deliveries periods, so short delivery times. Now, the agile methodology is based on the agile manifesto. Now, the agile manifesto is a document that focuses on the four values that are associated with the four pillars of agile and the 12 principles for agile software development. So we're gonna go into the four pillars and then into the 12 principles. Now, the 12 principles is a lot, so just hang on. We won't go through in detail on all those, but I'll just kind of rattle those off so you understand what are the four, the 12 principles that you may have to understand for the CISSP. Now the four pillars of agile. You get individuals over processes and tools. The agile teams value the team collaboration over working independently and doing things by the book. They're again. They want the overall collaboration process in place. Working software over comprehensive documentation. A friend of mine told me this. He said it's better to get it done than to get it perfect. The ultimate goal is to get working software out the door and it's available to you without having this comprehensive a laborious documentation in place. The third one is customer collaboration over contract negotiations. It's ensuring that the customers are extremely important in this process, that they give you what they want. You then make, develop the software based on their needs. Again, that's the collaboration piece of this, not versus I'm haggling over a contract negotiation point that I didn't develop the code. That was what purple color? It was an orange color that I've seen that happen and that therefore, when you get into haggling over a contract on something like that, you've got problems, it's gone off the rails, it's got an issue. So, again, understanding the customer collaboration piece of this. And then the fourth thing is responding to change over, following a plan. Again, you have to be flexible, as it relates to the agile methodology, and they need to understand what, how to make those changes. Now, what are the 12 pillars of agile? Okay, so we're just quickly. I'm just going to walk through these customer satisfaction, welcome change, basically allow change. Frequent delivery, giving the product quickly, collaboration, understanding what the business wants and giving them what they want. Motivated individuals, people wanting to make a difference and wanting to develop Face to face conversations. Again, this may not be in the same room. We dealt with COVID, it's all can be done virtually, but you want to have people that are having conversations on video talking about it. What's going on? Software, working software, obviously, sustainable development process that works, technical excellence, simplicity. Obviously, simplicity is amazing. The more simple you can make things, we just tend to make things way too complicated. Self organizing teams, basically, which means that they work together and they come up with a plan and it's not a strict guidelines you have to follow. And then 12, regular reflection. Regular looking at how you did, what did you do good, what did you not do good, how can you make it better. So those are the 12 pillars of Agile Customer satisfaction, welcome change, frequent delivery, collaboration, motivated individuals, face to face conversations, working software, sustained development, technical excellence, simplicity, self organization teams and the regular reflection. Again, that's what you want, right? You want all of those 12 things to make your Agile program work. Now, these frameworks are designed again to work with other types of mindsets. They also can work. When we talked about scrum, kanban is another one, and then extreme programming. These are all the methodologies that can be incorporated within the Agile methodology. So, again, it's an important piece of this. The last thing I want to say about Agile is, again, it does allow for continuous improvement, adaptability and flexibility. If I haven't beat it enough, I really like Agile. That being said, waterfall and spiral have their methods in which they are valuable. So you will have to decide, as a software developer, if you're leading a team in this space, that which one is best for you, your team and your customer. But those are just the things that are out there. All right, I hope you guys enjoy this. That's all I've got for you today. Head on over to CISSP Cyber Training. I've got a brand new thing out there for you all. I've changed my, basically the point of I've given away about 360 questions, but I realized I was giving them out over a too long of a period. So over the next six months, you will get 360 questions. Sign up, you get 60 free questions right out of the gate. Within the first month you'll get 60 free. Next month you'll get another 60 free. So you're gonna get 360 free CISSP questions available to you just by going in there, signing up and being part of my email distribution list. Being part of that list, you're gonna get a lot of aspects of any content that comes out that's new. That's only for you guys. You're also gonna get emails that are specifically around what to help you study for and content that comes up as it relates to understanding the cybersecurity domain and what you need to be prepared for as you're getting into cybersecurity. That is all I've got for you today. Head on over to CISSP Cyber Training and I hope you guys have a wonderfully blessed day. We will catch you on the flip side, see ya.