Agile Project Management: How to build anything Digital

1. Introduction: Hi there and welcome. Here's a very quick summary of this course. This is a course that will not teach you how to do any coding. A won't teach you how to design a shiny user interface. It will not demonstrate to you how to advertise and launch an app to go viral across the Internet. Now instead, this course provides you with an end-to-end overview of the Agile software development lifecycle that you can apply to any digital products you envision to develop. And it explains what team members and skill sets you need to point with you in order to succeed. My name is Alex. I am based in London, UK and over the last couple of years I've been working as a senior elite and project manager in big digital transformation projects, typically for banks, consumer, retail, and health care clients. By the end of this course, you will know the difference between Agile and Waterfall software development. You understand the key roles and responsibilities of team members and an agile development team, including your own in the form as a project manager. And you'll be able to explain each phase of the Agile software development lifecycle, which includes the ideation phase, fleshing out requirements, designing and building your software and showing it's tested on a regular basis and eventually getting to launch it to the market. The course is very much aimed at beginner, put it matches interested in software development. You may already be a junior developer or designer wanting to switch into a project management position. Or maybe you an innovator with a great idea for a digital tool. But you're quite unsure where to begin or what skill set is required, in which case this course is for you. If it sounds interesting, then let's kickoff and get right into it. 2. Waterfall Development: So the approach within the software development world, they tend to be two key ideas to key approaches to software development. One is the waterfall approach and the other one is the Agile one. Waterfall is a sequential methodology where task a little bit more linear. Whereas in contrast, agile is a very much iterative methodology, which includes a cyclic and collaborative process. It's a very heated debate what's best and what's better. In my personal opinion, it will very much depend on the preference for for your project, you skill set and nature of the project. And whether you need an iterative process or maybe emboss sequential one. Nevertheless, there's certainly a bias, I would say 20 as agile development in software development. And as a result, we will focus on that today. Nevertheless, let's dive into waterfall vey quickly just so you have an understanding as well. The waterfall model is definitely the oldest and most straightforward one. Basically we finished one phase and then we start the next page. It's very easy, very straightforward. So as a result or as an example on this slide, you may want to do all the analysis of the project first and then, and only then do you start your back-end development. They are definitely some benefits that can be, that can be argued for developers and customers agreed quite early on what will actually be built. In the very beginning, you define the analysis, you define the scope of work. And that makes planning arguably a bit more straightforward. In a similar fashion progresses quite easily measured. You have this full scope of work in mind. And as a result, you can quite easily say how much has been built already off that. As a result, software can be designed completely and very carefully based on the complete understanding of all the software deliverables. But once again, that's of the theory. And there are definitely a lot of drawbacks that have been seen in actual practice. Maybe most importantly, I'd argue is the lack of effectiveness of requirements. If you start, when you start a new project, the reality is you don't know anything. You don't know about the complexity, you don't know how to build anything just yet. You don't know what the customer wants, how the market is going to respond. So whatever you analyze in the very beginning, maybe completely not meaningful at the very end once you launch the product. So once again, any small details that may be left out, details that may be completely wrong. They will then hold up the entire process wants discovered. And as a result, a project gets not only delayed, but becomes quite costly. Also, once you launch something after a long time of analyzing, developing, and testing it well could be that the product in the end is completely undesirable or maybe outdated by the time it's life. So the possibility that a customer is dissatisfied with the delivered software product is definitely high. And once again, that becomes costly. 3. Agile Development: So when it comes to agile, a quick history lesson here is sort of around 2000, 2001 people got together, software developers got together and they very much shared the frustration about the current state of affairs, how software development was being tackled. And importantly, they all agree that the excessive planning and documenting of software development is inefficient. And really what matters is pleasing their customers and that is being lost. So as a result, they introduced and came up with the agile software development. Agile software development tends to or seeks to break up all the development work into smaller milestones. And you build your app, your product in a series of cycles. So once again, rather than building everything and then launching, you only focus on a certain feature that you then launch and then you carry on each cycle as seen on this slide, we'll include that you similar stages like a waterfall, you do some planning, you do the development tests and you review. But once again, crucially, you then ship, you then launch to the customers early on. And as a result, each release provides a testing ground where quite quickly you're meant to get feedback from the customer, from the real market. And based on that, you can then iterate and change your product to the actual customer and market needs. Really, the key consideration here when it comes to agile is that the customer is at the heart of the development team and the customer work very, very closely together. They collaborate, and it's the customer that guests to see and use the product early on and as a result, can provide feedback. And based on that, things change all the time. There's no linear plan that is being followed. But rather after a quick release, it is the customer who provides their feedback and the plan is being adapted accordingly. There are a few key principles that came up that we come up with as a result. And that is, we want to focus on individuals and interactions over processes and tools. It is the people, the customers that at the heart of everything, it's not processed or tools or you may have once established, we will adapt things all the time in a similar fashion. It's working software, actual stuff that's out there and working and being used. That is more important than overly comprehensive documentation, project plans and so on. Absolutely, it is important to write things down to share knowledge, but working software is the most important thing. I've sort of already hinted at it. The customer collaboration is key. The reality of life is, look, the customer doesn't know what they want. They probably won't get it right the first time and they will change their minds. And so working with the customers hard, but that's sort of the reality of the job. There's absolutely no point of having a contract in place and sticking to the contract. When it turns out that a customer is absolutely not interested was written. What's written in it? Yeah. So it's all adapting to the customer feedback to invest what they find. Instead of sticking to something that's been negotiated many, many years ago. And that really takes me to the last point. We're just, you want to respond to change. You don't want to follow a plan that's been set up a while ago, but rather, you respond to what the customer has perceived. If you're more interested, those principles have a look at the Agile Manifesto that's been established by the software developers in 2001. It is a fundamentals of key to effective software development is being used all the time across all the big projects. In software. 4. Agile Ceremonies: I really want to touch upon Agile ceremonies, which is a very fancy word for meetings. I will just touch upon 44 key ceremonies of key meetings that are being used within, within software development. And what a sprint planning, sprint planning. There's a lot more detail behind it, but quite abstract, quite high level, it would mean that you plan what you're going to be building within the next week or so. So all the developers, analysts, designers, and so on, especially the customers and product managers come together and they decide what is the next feature, what is the next thing that we want to build? A woman commits to that within that planning session. And the goal is to build something within the next two weeks and dies. And again, followed by release that we saw that we saw just now. The next thing is steer daily stand-up. You'll have to stand up. Having said that, I think most teams actually do. But within the name it is daily and it's the team coming together. And the emphasis here is very much on communication, regular communication within the daily stand-up. And it's really just a 15 minute session every morning, you communicate what you've done yesterday, what you're planning to do today. And importantly, whether you have any risk issues that you experience where you need help. And so every developer, analyst, designer, whoever is in the functional team, as part of the meeting. And as a result, quite quickly you get updates from each team member and understand where everyone is at and whether anyone needs help. When it comes to communication, visual communication is important. You want to visualize what is actually being built. You want to get feedback quite quickly. And as a result, you have a sprint demo can happen every week and happen every, every two weeks or so. But the idea behind that is again, you want to share off then he went to fail often you want to get feedback very often in a basin that want to iterate. So a sprint demo can be anything from some development that's been done, to a new design, to some customer feedback that you may have received. The idea is that across all the various functionalities, various functions within team, you want to have a transboundary share to the team members what is happening. Lastly, there's a retrospective. Really all that says is that the team comes together after certain time periods. It tends to be after a sprint that's been completed. Sprint can be anything from sort of a week, two weeks, four weeks max. But the idea is that team comes together and discusses what has gone well within that cycle of work and what has to be improved. Once again, it's very much a tool for communication. Making sure that people collaborate, making sure that everyone is happy, making sure that the team works efficiently. And really that any use of a risk can be mitigated in any future spreads. 5. Your Team Members & Skills: So theories, grade, methodology is awesome. None of them matter. If you don't actually have something to put into practice. To put something into practice, you need real people, you need a team. So in this section, we will provide a quick overview of what a typical Agile team looks like. Of course, don't be mistaken as always. Depends on the size of spending, on their complexity and maturity of your project. But the idea is to have an idea of sort of the typical team members. So very famous same software is easy, people are hot and I'll be fine. I personally find that to be true. So invest in your team. Let's have a look. First and foremost in the Agile world, that is the Scrum Master of a fancy word. If you want, you may forgive him to say the project manager, program manager. There are nuances to that, but for the sake of sort of high-level overview, I think we can say that maybe the case a scrum master is responsible to repeat a glue between everyone, between all the stakeholders, the people, developers, analysts, designers decline the customer and so on. It is then that managed the planning process. They drive multiple releases, they facilitate release planning. They're responsible for the scheduling of all the Agile ceremonies that we've mentioned. They provide access to tools and people. And as an example, anything that comes out of a daily standup meeting, really, the actions they are responsible for their own until they find the right owner. Scrum master is also report on the project status to all directions downwards and upwards. They call it coordinate release support. They are responsible for risk assessments. So look, as you can see, it's a very diverse work, diverse set of responsibilities that is hard to define. But really they want to help to protect the team and to unblock any problems and ensure that the Agile processes are followed to be, to be efficient and to be effective in your development. Every product with a product owner, somebody that is responsible for the vision for the short-term as well as long-term vision. And so the product owner typically is the CEO of the product really. They are responsible for the market and the business case for any sort of competitive analysis. They tend to be industry experts, knowing the industry and the customers inside out. They have an idea of the return on investment and net profit. They are representing their customers. So often more than not, it is the owner comes up with the requirements. Somebody who prioritizes work and so represents what the customer, at least what they think the customer wants. So a crucial, crucial person within the team. The business analysts often sits very close to the product owner. Because as I mentioned, requirements are often determined by body part on that. But really it's current in the name the business analyst is responsible for any analytical solutions. They increase the business value by collaborating with the product owner. They create a product backlog, which again, it's a fancy word of saying a set of requirements. They may develop a business case by working very closely with the part Maja. And then importantly, they write down the requirements. So they, they, they don't stop at the high level, but they actually go into the detail, write them all down and convey them to the rest of the teams. Often, more often than not, requirements should always be done as a team. But it is the business out of this responsibility to actually draft them in conveyed in doing, for example, a sprint plan. Lastly, they may support the Agile practices. They encouraged improvement of services and of course they become experts within certain functions. The UX and UI designer, there's an important differentiation between UX and UI. Ux designer, for example, may be conducting user research. They are creating user persona, which is a representation of that user research. They may determine the information architecture of a digital product. They may be sketching out user flows, or they may be sketching out what an app, what a design, design could possibly look at, love Look, look like. And then based on that, they create prototypes that are being tested. Whereas in contrast, but not always exclusively, a UI designer then puts that into an actual user interface design. I, high-fidelity design looks good and it looks like the end product that is being developed by the development team. So overall, responsible for journey mapping, the end-to-end flows are being defined and designs responsible to be sitting together with the customers. Try and understand what they are they after. And doing lots and lots of testing and then translating that into an actual design. A developer, again, in a name, develops certain, certain features, but I think importantly, there are additional responsibilities. That are often being overlooked. Developers are crucial in estimating the size of any new requirements in any evaluation of the technical feasibility. They helped understand what can be done, in what timeframe, how complex and may be, what may be required, and so on. So they oval together with a team, help implement the backlog items. They, they ensure that testing is being done for everything dies being done is being designed and defines. In addition to the actual development, they also ensure quality control. It's not just being developed, but it's also being tested thoroughly before, before it goes into the shipping stage to the market. And I mentioned testing, I mentioned before they're testing is often also overlooked. It is absolutely crucial that you test your application, that you test your new futures before it is being shipped to the market. And so QA testers quality ensure assurance. They are responsible for writing test plans, which enforced the overall acceptance of new features. They made it as mentally. And they also automate that overall approach. Developers and testers work very closely together and continually integrated codebase with these manual and automated builds that functional testing and regression testing and so on. And we will get into the details of testing later on just because I think it's so important. But once again, tests as they measure the quality that they find it in the first place to improve the quality. And they enforced a quality issue as and the best practices with that are being carried out all the time. Now, don't be mistaken. These are just some examples. Teams are small and big depending on the maturity and complexity and size of your project, you'll need a solution architects to define the overall technology landscape. You need to have certain environments available where you can test, write, code and then eventually deployed. You want to make sure that releases are being done in an automated fashion. You probably want somebody who manages your data. You need an operations team, use researchers, copywriters. You wanna make sure that end-to-end product is a safe, secure. And again, when it comes to, you may need some lawyers are some compliance advice and so on. So it doesn't really stop there. But what's important is that the typical cross-functional team, maybe comprised of these Agile team members that have been mentioned. We have forgotten the most important one and we've been emphasizing a few times and so we should one more time. It is your customer. You should be as close as possible to your customer as you can. You design for your customer, not yourself. And that is the number one mistake. We see all the time. We think we know what the customer wants, but really we only build towards our own needs and thinking. Yes, sure, there are other people like me and therefore should be the right thing we're building. Trust me, you do not know and you will be wrong or the building. So get your customer in conduct customer research all the time tests with the customers and in the Agile fashion that we have discussed, launch often do it early, do it all the time and learn from the mistakes. Learn from the feedback that a customer provides to you. 6. The Ideation Phase: Okay, We talked about the lifecycle of the software development lifecycle all the time. And it's very simple as it could be possibly visualized like so. You have an idea. You want to engage in a discovery phase where you flesh out the idea bit more use of defined requirements and you build up. So first set of designs. You then build it, you test it, and then you launch. Again, we within the Agile world here. So don't mistake this as the waterfall methodology, but rather you're looking at a certain future that you're building out. Yeah. And then you provide a release and you do it again and again over and over and again. We said before, every good starts with an idea. Chances that you may have one or you may have absolutely none, both as perfectly fine. In idea. It rarely happens when you just sit down, you have to work towards it. And if you don't have enough idea, then that's fine. The best place to start is to really train yourself every day and just think of, you know, what is the problem and what is a potential solution in my everyday life? You really want to ask yourself all the time, why do we do things in a certain way? Is there a better way of solving a problem? And if you can identify a problem or sort of a market inefficiency, if you will. You're already halfway there. Now. There are loads of ways of coming up with cool ideas and it would certainly go way beyond the scope of this course to explore them all up, I'll put something up into the description if I can. But, but what I like and always use is to creation and the use of the customer journey. The customer journey really is nothing else but a process that sort of looks at what the user undergoes. Let's say, for example, a user may be looking at your e-commerce website that you're building. At the very beginning, there's a discovery stage day. They need to find out about the fact that your website exists, wants to own or they may them browser, they go through what can be bought on your website. They do some thinking about it. They do an evaluation of like, is it worth my time and my money to make that purchase? And then eventually they do make their purchase where they potentially are quite anxious about it until they see their final self confirmation that payment has gone through. And that's the end-to-end experience. You want to look for each of those stages at the site of action that the user undergoes. So for example, at the discovery stage, you are in a sort of stage of awareness. You're trying to find out about the service that you're providing. The action may be that you open the app, the website you may view tutorial, and the sort of emotion of the user at this point is they're curious and then the baby, but skeptical in terms of what you're trying to sell them. But they're curious. Whereas an unconscious at the purchase stage later on, they are now convinced about your product and you're selling day. They have a desire to have it. And the action is to do the payment and then checkout. But the emotion here is much more than they're stressed and they're looking for affirmation that they absolutely indefinitely should be making that purchase dot payments and hopefully are then subsequently happy to have done so. And the point I'm trying to make here is within the customer journey itself, that is one ability to understand what the user is feeling, what they're all about, and crucially what you can improve within an existing journey. Or importantly, what you can create a new journey and a new product or new project is something that could delight the customer, something that makes them happy by understanding what the various processes, what the various stages are, by understanding what the customer goes through, is your ability, your opportunity to improve and make that process very smooth. 7. The Discovery Phase (Technology): Now, with an idea in mind for your project, you want to make sure to enter a discovery stage before you actually build anything. The idea behind discovery stage very much is to flesh out your requirements, to play around with the first set of designs to visualize what a product could look like. You probably are not surprised when I say you can even turn, should probably even tested with customers that already at this stage. And to also determine how the application is actually going to be built, what technologies are going to be used? So with that in mind, we'll start with the solution overview. At this point, it is the solution architect of tech lead and the various developers coming together. And they want to convey and determine the solution overview. It's very much providing an overview of how every component is going to be built and chewing That's going to be well-built. So a solution overview is a skeleton of a program, of a feature of a project by a missing an important element in that project architecture, you may endanger the success of your entire project. We can't emphasize this enough. Proper architecture will allow for saving a lot of time, energy, and costs in the future. You want to make sure that you get this right. Now, any, any architecture design usually comprises of multiple layers within application, such as the presentation layer at the very top. That is what the user tends to see that as the user interface to bears components, the interaction design, that is what the user actually tends to view when using your product. Beneath is a business layer which involves or includes all the business logic or the processes, all the flows. And then lastly beneath that is the data layer, which in turn includes all your old data logic, the database itself, and so on. That, that in turn is then being wrapped. You want to make sure that you have security in place, any sort of configuration. We're not gonna go into all the detail here is obviously a very complex job, and it's being done usually by a solution architect, by the tech lead and by the various developers in your team that together convey and envision how your product is being built from a technology layer viewpoint. As always doubt numerous approaches and technologies in their programming languages that can be used for, for building such a high level technical design or in short tech stack. And as always, they all have strengths and shortcomings. Some are cheaper to use, but maybe less performant. Others may take much longer to implement. It could be even overkill or be a better performing. As a result. The worst possibility is building on a dying or unreliable technology stack. So we want to make sure you don't do that. If you make that mistake, you might have to rebuild entire application again. Or you pay premium for developers moving forward. And again, without going into too much detail, there are so few key principles I want to highlight when it comes to the stack. And that is, you want to build based on the following principles. It has to be efficient. Yeah, so your application has to perform the tasks and performs the functions in any condition. So it has to be reliable with any sort of load, any sort of amount of users being on your, on your platform. It should be flexible. The chosen solution has to be easy to change. You can change elements and it shouldn't influence that the whole, the whole project automatically, in a negative way. You should be able to extend it. So you want to be able to add as many functions as you like 2D application. Importantly, it should be scalable. It should be always possible to extend. The architecture, should allow for direct development and several parallel threads. And lastly, testability. You absolutely should be able to test the architecture easily, which means that the number of errors decreases and its reliability increases. Once again, that is the job of the solution architect. 8. The Discovery Phase (Design & Roadmap): Going, going into a completely different sphere in terms of the work. Beforehand mentioned UX design. And again, this is of the visualization of what could the product look like. Yeah, So here in the discovery phase, we begin by creating designs and screens, and we start assigning each functions and data. It's completely okay that they live in multiple places. You have no idea where he just sits at the current moment, you just playing around. And more often than not, this process takes place on whiteboards, on paper, or as you can see currently on screen, some sort of scribble tool where you can make sure that you can play quite quickly and change things quickly without taking too much time. The idea here is you want to make changes, you want to do that now rather than later in the process. Currently it's much cheaper to erase something. Then later in the, in the library you have to rewrite entire coat. Okay. Workflows are the pathways, uses can travel within your app. Yeah, So again, within that, you want to consider each of the things that the user should be doing on a certain screen, how many clicks it takes them to complete an action. You wanna make sure that each click is a two additive that doesn't really take too much time or work to accomplish something. As you find problems with your workflow, update those wireframes. So what we see and those scribbles are called wireframes up there, then start again tests with a customer, makes sure it works before you go into some more complex designs. What you tend to do here is also use prototypes. So click-through model is where you put all those wireframes together and have the ability to just click through them as if it was a real app, but without having done any actual development. Once again, if fantastic way to test something on the phone very quickly for more realistic testing and getting feedback right away from there. This is a fantastic way of understanding what your requirements are. This is what a business analyst comes in. So say, for example, that a UX is on hazard determined a sort of UX design on the left side. As you can see, we have a menu wherever search bar we have some sort of filter at the top, you have various, various things. So click on such as workshops or marketplace or whatever may be in that particular application. And so was easily convey currently visually needs to be put into more detail in 3D, that becomes the backlog of requirements. So a business analysts will work together with the product owner, with designers, with the developers to ensure the vision and that the designs are now being put into actual requirements. And they are being defined with older detail that is necessary for developer then to actually build out. Lastly, and again, a completely different aspect of work is the product roadmap. This is what a product owner, the CEO of the product comes in. And within the discovery phase, you want to have a somewhat an idea. It doesn't have to be too precise, but you want to have an idea of the high priority themes that will help everyone really to focus their time and energy to do a few things. Va they well, agile product, roadmap is the idea behind that as a navigational tool. Yeah, it helps teams to focus on where they're at, where they're going, but also gives them the freedom to course-correct as needed. So for instance, if we are a key one at the moment, we understand what we're building at the next couple of months. But it's still the freedom to change and adapt what may be built in Q2, q4. So really an agile product roadmap is a high level strategy visualize, and it's focused on outcomes rather than outputs and talks of, and themes and epochs rather than feature. So nothing is defined at that point. So visualization and indication of what's to come. And that helps communicate the product strategy with the other parts of the organization and with a customer. And ensure that you get buy-in from your team and from key stakeholders. Overall, that was a quick insight of various things you may be doing in the discovery phase. As always, there is a lot more. It's depending on the project. But look, ensuring that you have a solid technology foundation and solution overview is absolutely crucial. You do want to have a sort of go at visualizing what the end product could look like and test it with customers. Early on. You want to have an idea of the requirements that are being built out in the first set of weeks to come being done by the business analyst. And you want to ensure that the CEO of the product, that product owner is able to convey the vision and where we go, not just within the next immediate few weeks, but really with a long-term vision says and what the end product is to look like. If that is done in addition to any other things you may have to do, then we enter the Bill phase. 9. The Development Phase: Okay, built probably one of the most interesting and intense periods within the project, arguably the ideation and discovery phase, as well as the launch phase towards the end, takes significantly shorter time than the build phase, may as well be 70, 80 percent of end-to-end project that you will deal with the Bill phase and as a result, in incredibly important but also where most things go wrong. And so I need to be improved. It's a long process and not want to be overlooked. We're going to have a quick look at the day-to-day working for the team, which is within the Agile world, you are going to be following. This workflow here is of high level again, which is you have the backlog of requirements that you have put together previously. And so each day really, you are going to choose which item you're going to tackle. You're going to put that into the OpenFlow. And then over time that is to be then selected for being in progress I is being developed. It goes into the QA column quality assurance where it's being tested. A base on that. If it's passive goes to done and if it has not passed, it goes back to the in-progress. More often than not, that actually happens physically on a wall, on a whiteboard, or the like, of course, can be done digitally as well. But they often, it's just a bunch of posters that are being handed from column to column. And it's a great way for, for teams to visualize what work is being done. And databases, especially doing a stand up to visualize and conveyed to everyone what is actively being worked on. And very quickly you'll be able to see if there's any impediment, if there's any so blocker. Why a certain ticket, why certain requirement is not moving forward? So that is the overall end-to-end workflow. You take a requirement and you work your way through the various workflow stages. And poor business analysis view point. It is now the objective to write the user stories, the requirements they are, they're called user stories. And as an example, if you take, for instance, the menu, be that now certain feature, certain requirements. You tend to write it in the following format, which is the, you define for whom it is. So in this case, it is a user who has already locked into your application as an authenticated user, you then define the objective for that particular user. So in this case, I want to access the side menu that is the desired as the objective. And then you say, well, why? So what, what is the, so what? And so you define that as a so that in this case, I can view any sort of additional features that may be available within, within the product. So once again, Diocese of the business out of this job. This goes into a lot more detail, but at high level it's listed as a user story. Where do you find who is the user? What do they want to do, what's the action and why? What is the objective? So as an authenticated user, I want to access a side menu so that I can view any additional features touching up on sort of a very high level tasky for the business analyst. In a similar fashion, a UX designer we've touched upon before has defined various workflows. Berries, UX screens, US experienced screens that may look up, look like this. At this point, can you scribbles and certainly nothing that you want to ship and launch into the real market. So it's now at this point the sort of tasks for the designers to put that into something a bit more shiny, into an actual user interface. And so it may, for instance, become something like that. Yeah, you go from a UX interface and that's then be interpreted by designers as of the end user interface or the developers are actually going to be picking up and developing Naturally. We then also have to build, we are absolutely not going to go into that in this particular course. Lots and lots of various ways of building code, going through different languages and so on. There will be a whole different, a whole different course. So we're going to have to skip that. But once again, keep in mind, we are following the Agile methodology in our particular example. Yeah, so we're gonna go through the workflow of analysis, billing the whole thing for a certain feature and they're releasing it very quickly so that we get feedback from the customer immediately. Before we do that though, there's one aspect I want to emphasize and that is testing. So we won't be touching on development today, but I think testing is something that we want to quickly have a look before any future gets released. It should go a food thorough testing, and it should do that all the time in ideally, it should be done automatically. So let's have a look at that. 10. The Testing Phase (#1): So testing, I have now I mentioned many times how crucial and utterly important I find tests and to be within any piece of software development lifecycle. Luckily these days technology allows us a much easier life of the capsule testing and lot of it can be automated, whereas some, some aspects of, of course still have to be done manually by the developers, all the testis, quality assurance teams or even business out of this, whoever maybe park managers and so on. If we're looking at the application, testing is crucial however, so let's have a look at the various type of testing is typically being done. One is unit testing, usually in a degenerate doing done by developers. They use either manual or automated tests and they ensure that each unit in their software meets the customer's requirements. So once again, you can either test those test cases, mainly that of course, is time-intensive. It takes a long time, it's repetitive, and therefore takes quite a bit of effort on. Good news is however, automated testing automation tools these days, they can allow you to record and save a test, and therefore you can replay it as many times as needed without any sort of further human intervention. So anytime new coldness being developed and deployed before the deployment, a developer is to write their unit test and is to execute the unit tests, ensuring that that particular new piece of code has been thoroughly tested based on the requirement. Next, integration tests, absolutely crucial. Think of it as individual models are being first tested in isolation as part of unit testing. But once that's been completed there then integrated. So if you were thinking, think of it as a building, a car, you may be unit testing the doors, you maybe, you know, testing the engine, that trunk, whatever is the color, whatever it may be. But then one-by-one, slowly integrating that too as one single system. And so integration testing ensures that any sort of new code change anything you add to the overall system, does not impact the existing functionality of the software. You want to ensure to check that the combinational behavior makes sense. You want to validate whether the requirements are implemented correctly or not. Often then this is followed by system testing, meaning we want to test a whole system. All models, all components are integrated in order to verify the system works as expected or not. Once again, if you think of the example of the car, It's great that you have thoroughly checked that each individual item it's been it's been unit tested. You didn't have checked that they're all integrated and integrated tested as you put together the car. But then lastly, don't forget the whole car itself still needs to be checked for all the various different aspects, requirements, and needs to be driven smoothly, has to have the right breaks and gears and needs to work for thousands and thousands of miles continuously. The color needs to make sense. So the system as a whole was also a crucial part to be tested and that is being done after the integration tests as part of system testing. I may have mentioned the customer from time to time in this course, and no surprise here then user acceptance testing is commonly referred to as in short UAT. And reward it means is, you know, showing the product or the feature to a customer and they do the testing forward. So real people, real customers determined whether they think that the software that you have created can be accepted in, can go live. This is therefore not as automated as the previous examples. Rather, these are time intensive sessions, but hopefully irregular sessions where real people, real users come together as part of small groups. That can be family in France, I can be early adopters, that could be power users, that could be people that you pay money for. And really you want to have various ways of testing that you want to at times just show them the software and ask what they think. And on the other hand, you may want to be very specific and write test cases and provide very specific samples to be explored by these particular users. And then they have plenty of opportunity to provide you with feedback. 11. The Testing Phase (#2): Really this gives you an opportunity to have a very open feedback by people who are going to be using your application in the end, in the real-world. Performance is, of course a crucial aspect. Imagining you build a website, but it doesn't load people who tend to click away after 2.5th of not seeing your results. So it's incredibly important to test both for the low testing do normal usage times and peak times, but also to stress test your application IE, you purposefully try and find ways to break the system. More and more users are you being a, being assimilated? And you want to check, does the system scale. There's very much comes back to the Oval application and architecture framework that we've discussed previously. You want to make sure that a technology that you have to design and envision, actually this work in is capable of dealing with all of the users are accessing your platform. Accessibility is usually referred to as surf the web content accessibility guidelines. It is an internationally recognized set of recommendations to improve web accessibility. That is a particular example for, for web design. But it really, it does apply to anything that really your app or whatever you may be building in a digital world, you want to make sure that everyone can and is able to use your end product. And so what I was comprised of is to make sure that the vision is very clear. Ie you have maybe, you know, severely sight impaired users. They need to be able to use your application. There may be people who are hard of hearing and maybe deaf. And they do have to have a particular tools to access the application mobility. Those who may find it difficult to use a mouse or keyboard, you want to provide them with alternatives. And then thinking, thinking of understanding people who have dyslexia, autism, any sort of learning difficulties. Again, you want to provide a simplified approach for them to use the application. As a result, even if it's legal or not, you want to absolutely think about accessibility from the very start. If you want to redesign our need to redesign in retrospect, trust me, it's going to take time. It's going to take an insane amount of effort and cost to do so. So think of it as an absolute key requirement from the very start, run all your accessibility tests from the Early on self-development. And you'll be off to a flying stuff. In a similar fashion. Compatibility ensures that your software is able to run on different browsers and operating systems. These days we have thousands of device sizes to deal with. They all look different on different screens. Think of it, of iOS, but particularly Android and have a lot of differentiated a device sizes and operating systems. So, you know, constantly, you want to ensure that the new software that you launch into any new future you're launching is compatible to these requirements that can be done manually, but more and more, most of it is being done automated in an automated fashion through emulators and simulators where you don't even need any device anymore. It's all done in the Cloud. And you can ensure that you knew code runs across all those platforms. And lastly, more and more crucially, I think for everyone and especially because it's received quite a few media scrutinise is of course, the security of the application. You need to ensure that you carry out regular pen testing. Are you security testing? Look, if you have an e-commerce store, for example, and you can watch online shopping, you'll be regressing person information, credit card information and so on. The user has to trust you. And if they don't, then you don't have any customers. And B, you may have a big problem with the authorities. But you're going to see there's no security means that any sort of authorized access is granted to protect the data. And unauthorized access is restricted. And you want to ensure that you don't have any vulnerabilities in any sort of your own code and custom code or any third party code. Keep in mind if your users of different supplier, you pop up with a third party, you absolutely want to make sure that they also are able to withstand any attack. Once again, that is just a high-level overview of typical testing being done. There is, as always, more. It is soft depending on pending on your, on your complexity and the size of your project in terms of how much you do of which. But it is crucial that testing is a sort of a key and monetary aspect of your software application. That approach. 12. The Launch Phase: And we are nearly there. The lunchtime, probably the most intense, maybe the most exciting part of the entire lifecycle that we've looked at so far. You've probably been thinking about your idea for, for years, if not longer. And now the last couple of months you've been building out your code, you developments, you design, and now you're ready to launch the first set of features to the market. When it comes to the launch, it's always a good idea to kick things off with friends and family. You have a bit more of a sort of friendly audience. And you can test and get feedback. Early on. Again, I'm repeating myself, but do not underestimate the importance of sort of initial friendly customer feedback where you can quite quickly iterate and improve your product. Also give mind when you do launch something to, for example, an App Store, it is always a process you want to make sure that the APSA properly configured for their release. You gotta fill out a couple of forms for each store you go to submit screen shows a bit of a marketing material, quite a description. So a bit of work has been done there as well. And then be it Google or Apple, they may Mallory review all these apps submitted to the App Store. Well, Apple actually there so more than, than Google. But it's possible that they won't press a bunch of changes based on your configuration. So keep that in mind when it comes to your timeline. Once you are live and the products out in the real market, there are of course, a few ways of promoting it other than their friends and family and sort of word of mouth. The obvious one these days is social media. Be that Twitter, tiktok, and whatnot. Professional networks like LinkedIn. That is one avenue data one is more so for the bloggers and vloggers, progress through affiliate marketing. And of course, if you do have the money, then you can engage in a more extensive campaign advertisement. Do so slowly in the beginning and obviously to more aggressively as to when you plan a full launch. But, but one thing I want to emphasize is that this is not the end, right? So app development doesn't stop at the launch phase. Rather, it is a continuous cycle of iteration, as we've now many times emphasized in the Agile development world. And so you wanna make sure that you monitor the app and the uptake by users. You want to make sure that you are able to access any crashes that may have been experienced. Libraries exist that do track those. And they tell you what the user was doing, the device that we're using, any sort of technical info that may be important to sort of replicate the problem. You definitely want to start understanding your users better. You want to make use of analytic tools such as Google or Facebook analytics. And that again, helps you understand who is using the app. What is their age, their gender, where they're from, what languages do they speak, and so on. How many times do they use the app when we're doing the day? How much time is being spent in the app, what screens are being viewed, predominantly, which ones are not, and so on. I'm fantastic, awesome opportunities out there. The creation of heat maps where you can see where people click, what screens. I'll click that most often and so on. But really the idea here is you are able to improve based on those analytics. You don't want to just build onto portions of the chapter there seldom utilize, but you want to invest where the action is, what is the largest potential for growth? And it is really those tools that provide insight, makes sure to measure performance. I mentioned before, people are not very patient when it comes to that. So you want to measure the technical performance and ease of system we deploy, has extensive performance monitoring in place all the time. That way you're able to track how many times an action has occured, how long it took. And, and again, you find that as a good opportunity to space for optimization. You can also put any alerts and place to know when an action is maybe taking a little bit slower whether your server, your environment is overloaded. So you quite cryptic and look to fix those as well. And then of course, even sort of manual monitoring when it comes to looking at the App Store, for example, do respond to customers cost comments. Take their feedback into, into account, make sure that the product manager does see them. And according the, that is the key feedback you need in order to improve and they quickly get other next iteration of your application. 13. Conclusion: That takes us to the conclusion where the end of the course. I hope those various stages of the software development lifecycle made sense and it was somewhat useful to you. Look, if there's one thing I would say at the very end is a one size fits all is not that. While the methodology of Agile development and that the process in itself does work and it can absolutely be consistently applied. Of course, it does heavily depend on the project, the complexity, the size, the, the, the, the funding is available to you, the skill set of the people, and so on. And every project is different. And in one, you may be heavy, heavy on technology and back-end systems and the business domain, whereas others, it may be very much more focused on graphic design and sound engineering and the development there. And you need to adapt as S required. And the one thing I would say from a project management perspective, or you being a product manager or a CEO of a small startup is duly by values. Because you as a, as a PM, as a project manager or somebody who's not involved in every single stage, but rather the glue between people. You are never going to be the expert in anything. Really more. It is you who provided a holistic overview, but you are not a domain expert. So duly by those values, I like the ones shown on the screen. Trust, empathy, transparency, and collaboration. Ensure that the teams can self organized, empower them, that they can do what's needed to solve the problem. And I think if you do lead by those values and if you establish that trust and sort of believe in the skill sets of people, then you too can build a killer prodrug, an awesome digital product that follows the software development lifecycle that's been presented today. That was it. I hope that was fun. I hope that was useful if there's any questions. Don't hesitate to contact me and we'll see you next time.