10127121, 4:50 PM Introduction to Agile Sofware Development Transopt Introduction to Agile Software Development Discover Agile Software Development, as well as the principles and values behind the Agile Manifesto, Table of Contents - History of Agile Software Development Why Agile? Advantages of Agile Agile Principles, Agile Values Agile Best Practices . Agile Software Development Life Cycle Agile Information Radiator ‘Agile Methods ‘Agile Management Agile Software Development Considerations 12, Issues Transitioning to Agile 13, Exercise: Identify Agile P History of Agile Software Development [Topic title: History of Agile Software Development. The presenter is Colin Cainan_] In this video, we've going to look at an overview of Agile software development and describe what Agile software development is and its history. So Agile software development is a type of project management. And, obviously, software development is a broad field. But Agile development, in particular, helps to work with process improvements within the software development life cycle. It can definitely help with software development application. And it does that through Agile project management, So a little history of Agile project management. Agile project management can be traced back to 1957. And that will give us our rudimentary start to project management, And that was when software developers were working in developing software for IBM and Motorola. They kind of came up with this idea of a model of developing software. And they came up with this model to combat an existing model — the waterfall model — for developing and for project managing software development. Now the waterfall model had been around and it was the prevailing form of project management at the time. And it is generally loosely affiliated with the idea of Gantt charts and layouts of tasks that need to be done at certain points in the project in order for the project to move forward. So generally the waterfall model did not leave much room for error. And it was pretty heavily micro managed in order to make sure that the processes and the steps in the waterfall were met correctly. So it was identified that definitely more flexibility was needed in the software development process because software developers were kind of at their wit's end in terms of what was happening with this waterfall model. So some more versatile approaches were introduced in the 1990s. And those include things like dynamic systems development method — DSDM — XP - extreme programming, the scrum methodology and feature driven development, which is known as FDD. So those were some of the lightweight and versatile project management systems or approaches that ‘were brought into software development in the 90s. And those new approaches that happened in the 90s are all ~ even though they existed before Agile — they are now considered to be part of the Agile manifesto. So what is the Agile manifesto? Well, the Agile manifesto was something that was introduced in 2001. And, at that time, a number of individuals met to work through a solution to the problems that they were having, And it was basically to come up with an alternative software development process and something different than ‘what had been existing in the world up until that point. So what happened? The outcome of that meeting of these [Link]/securele/ 1635399612. eff708432ec017120e07 12800458381 Bfaaa0Sb/ectiranscriptsid6209612-Tba7-4607-A550-483ed819... 1/12,072721, 459 PM Inroduton to Age Sotware Development Transcript individuals was this manifesto for Agile software development. And that manifesto for Agile software development was basically seven pages long and it consisted of four core concepts. And those concepts were individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. So those were the concepts that they came up with to help with improving the software development process. And, since then, there's obviously been a growth in Agile popularity throughout the world. It’s been helping people get stuff done, get through software development projects quicker, within budget, release cycles are faster, and so on. And, with that, there has been the growth of what we call the Agile Alliance and the Scrum Alliance. And these are essentially non profit global organizations that help promote Agile and Scrum throughout the world to make the software developers lives easier and to help projects be delivered on time. So that was an introduction to Agile software development and the history of Agile Manifesto. Why Agile? [Topic title: Why Agile? The presenter is Colin Calnan.] In this video, we're going to describe why organizations should introduce Agile software development, So some of the things that we can look at when describing why organizations should introduce Agile will be the idea of priorities change. So, obviously, using Agile with their iteration phases that helps prioritize the highest value features first. So, when you iterate and you go through prioritizing which work needs to be done in each iteration, that means that basically at any point in time, most of the work done is of high value so the highest priority work is done first. As well as that customer focus. So some of the most important lessons you'll get about your software will come from customers. So Agile teams are able to get sofware into the hands of customers pretty quickly by building just enough to fulfill their needs. As well as that, using Agile helps to increase product quality by ensuring that teams are responsible for maintaining a high level of quality and also verifying that everything that goes out actually works. So thorough testing processes, quality assurance, etc, Another reason for using Agile would be to allow you to maintain competitiveness. Now what do we mean by that? Well, generally, most organizations has some problems with process. And then, with Agile, you can help find those problems and fix them and help the teams stay competitive and help your product stay competitive by being able to iterate and allowing teams to zero in on problems that are maybe slowing them down or making delivery unreliable. And, as well as that, your software, your product, your business can cope with what we call the loss of a star. So the loss of an all-star employee, a crack developer, a great project manager, and so on. And the way Agile helps with that is that generally teams change, new hires come on, employees move between projects, etc. But Agile handles that through methods such as things like pair programming, where developers would pair up with one another and work on a similar computer ‘or work remotely via terminals. And that helps to distribute the knowledge and the know how throughout the organization so in the event that one of your star developers leaves, that the knowledge has been transferred across members. So what are the other areas — so revenue, cost, and risk management. So these are other areas in which your Agile can benefit your business. So, with revenue — because Agile is iterative — it means that features are delivered incrementally, which basically means that all of the benefits of those features are realized early on as the product continues to develop. So you're rolling out features that are valuable early on, thus generating revenue, rather tha method having to wait right until the end until everything is done to release that. So this helps with that, So cost control...so obviously the idea of things like fixed time scales with evolving requirements in a fixed budget can help so that the scope of the product and its features are variable, rather than the cost. So the cost remains fixed, but the things that are delivered to that cost and the features that are delivered can change. So that helps keep cost under control instead of this ever creeping cost. We have to get all of these things done by this time and the cost keeps going up and up and up. The cost is fixed and the time scales are generally fixed. But there's scope of what's delivered within that changes depending on how things are going. And then finally, there's the idea of risk management. So because you're doing small, incremental releases and the product owner and the product team are there to help identify any issues early on, it makes it easy to respond to change. ‘Therefore, reducing the risk of things being developed or things being created that are not what was needed or hitpeticdn?2 [Link]/securele/ 1635399612. eff708432ec017120e07 12800458381 faaa0Sb/ectiranscriptsid6209612-Tba7-4607-8550-483ed819... 2/1910127121, 4:50 PM Introduction to Agile Sofware Development Transopt ‘was wanted or don't suit the purpose or the needs of the application or the organization. And then some other key benefits of using Agile. Speed-to-market, obviously this iterative process helps you get your application out there quickly, it's always in constant beta state. Visibility and transparency — Agile encourages visibility and transparency between the client and the software development team so that the client and the stakeholders can always see what's going on and are aware of the state of the project at any time. Flexibility and agility — again, with this Agile process, instead of fearing things like scope creep and the never ending project, which might happen in something like a waterfall. With Agile, the time scale is fixed and then the requirements and the features are modified in order to fit that —so there's some flexibility there. Business engagement, so obviously, through the product owner or the user representative, there's a high visibility of the product and the progress. And flexibility is there when change is needed. And that creates much better business engagement and customer satisfaction. So the introduction of a user representative, a product owner on the product side can help engage with the businesses and customer satisfaction ‘As well as that, we're building the right product. So one of the ability of Agile development requirements is the ability to embrace change. And, by doing that, it makes it possible to embrace changes and to pivot. If things are not going as they should or changes needed to be made, you end up building the right product for the customer using Agile. So those are some of the reasons why organizations should introduce Agile software development. Advantages of Agile [Topic title: Advantages of Agile. The presenter is Colin Calnan.] In this video, we're going to identify the advantages of Agile over the waterfall model. So lets first have a look at the shortcomings of the waterfall model. What are some of the shortcomings? Well, firs is it's difficult to make changes using the waterfall model. Documentation is made early on and the project moves on from there. So making changes is more difficult because all of that stuff has been set at the beginning, Working software is produced late into the eyele. So it’s a step-by-step process — a stage-by-stage process. And it's not until later on in those stages that any actual working software gets produced. There's also great risk and uncertainty because it's impossible to predict risk on a long timeline at the beginning so that generates this uncertainty. It's also not ideal for long duration projects. Because again, as the project grows over time, that risk and uncertainty grows as well as that software gets produced later and later in the model. As well as that, i's not suitable for regular requirements changes. The requirements are set in waterfall at the beginning, they're documented. It's a whole phase of documentation and requirements. And then off you go with your software development so regular requirements changes are not suitable. And it’s also not suitable for complex object-oriented projects where there's a lot of interaction between elements that may need to be revisited as the project moves forward. So let's have a look at the advantages and disadvantages of Agile versus waterfall. One of those is customer availability. With Agile, it prefers the customer to be available throughout the project for discussions. Whereas, in waterfall, they get involved at milestones. Scope — so Agile welcomes changes and then the changes come at some sort of cost through other features. Whereas waterfall works well when scope is known in advance or when contract terms limit changes. So the scope is very ‘much set in waterfall. Feature prioritization — so in Agile, priority is generally organized by what are the most valuable features? And those are implemented first, kind of, reducing the risk that the product that's produced is unusable. Or if, for example, funding runs out and there's no money left, at least the features have been prioritized so that the most important ones are done first. In waterfall, basically it's a kind of do everything we agreed on approach and they get an all or nothing, So that kind of incteases the risk of failure. In terms of teams, Agile prefers like smaller dedicated teams that are highly coordinated and they're synchronized, Whereas, in waterfall, there is team coordination but synchronization between those teams is kind of limited to these handoff points instead of there being a constant sync. Funding ~ so Agile works really well for time and materials or other kind of non fixed funding. Waterfall reduces risk in fixed price contracts by getting an agreement up front in terms of what should be delivered. And then feasibility. So Agile is better where it's feasible. So it depends on the project and the situation. But Agile, if it's feasible, is definitely better. The idea of waterfall may reduce risk depending on certain constraints in the htpsedn2 [Link]! 1635399612 0f1708432ec01120607 1045896 tesadSbeottranscrptsid62006"2-Toa7-4607-8550-4836d819... 3/19072721, 459 PM Inroduction to Al Sofware Development Transcript contract. But generally, it's preferred to go with Agile. So what are some of the strengths of Agile over waterfall? Well, there's this non linear approach. This iterization approach and constant delivery. Early customer involvement — so the customer gets to see the product that they're looking for early on There's this customer sense of ownership. So the constant communication involving them in conversations about it helps them feel a sense of ownership. As well as that, there's time to market, So this quick iteration means that you have a working piece of software out the door as quickly as possible. And then finally, you've got user- focused development. So, if you're iterating quickly, you can be checking the feedback from your customers or your users and making sure that your development is focused on their needs solely. So those are some of the advantages of Agile over the waterfall appro‘ Agile Principles [Topic title: Agile Principles. The presenter is Colin Calnan_] In this video, we're going to identify the principles of Agile software development, And we're going to start with team focus. So what are some of the things that Agile development can bring to software development? What are the principles we can apply that will help a team focus? Well, the first one is this idea of self-organized teams. And the best architectures and requirements and designs, generally, can emerge from self-organizing teams - teams that have the ability to organize themselves. And Agile can help with that. As well as that, we have team self-reflection. So, at regular intervals in the project, it's important that the team reflects on what they're doing. And that helps them to become more effective and then helps them to adjust their behavior accordingly. As well as that, close and frequent cooperation between partners between the client and the developers must be there constantly, daily, throughout the project. And then face-to-face communication is really important as well. One of the principles of Agile is that effective and efficient communication happens when there is a face-to-face conversation within a development team. So the next area we can look at is customer and delivery focus. So some of the things we can look at here are the idea of changing requirements. So it's important that,..and one of the principles of Agile is that we embrace changing requirements. That we welcome them even late ina development. That we use Agile to kind of hamess change and make it work for the customer in order to give them some sort of a competitive advantage. As well as that, measure of progress. And the measure of progress is basically the working software. So one of the principles behind Agile is that a piece of working software is a good measure of progress. Then we have the idea of software delivery. And, with Agile, we're able to deliver working software frequently from a very short time scale to a longer time scale, but with a preference for a shorter one, And then finally, you have customer satisfaction. One of the highest priorities within Agile is to satisfy the customer. And we can do that through early delivery of the software that's well tested and it's continuously delivered. And then finally, in the last set of principles, we can look at the individual traits and processes. So one of the principles around Agile is this idea of motivated people. And obviously, you ‘want to build a project around motivated people. So give them the environment, the tools, and the support that they need to help them get the job done Then, as well as that, we have the idea of sustainable pace. Agile, in essence, and the processes that it implements, promotes sustainable development. And the investors, the developers, the clients, the users should be able to kind of maintain this pace indefinitely if it's done correctly. As well as that, we have this idea of attention to good design. Obviously, this idea of improvement, continuous requirements, reviewing, continuous development, that all goes together and works together to help give good attention and attention to a good design. And then finally, you have this idea of simplicity. Obviously, when you have processes that try and maximize everything, then that lends itself to being simplicity. So basically, it maximizes the amount of work done. So those are some of the principles of Agile software development. Agile Values [Topic title: Agile Values. The presenter is Colin Calnan.] In this video, we're going to identify the values of Agile software development. So we're going to look at these four parts of the Agile manifesto. The first one is, [Link]/securele/1635399612. eff 708432ec017120607 12800458381 faaa0Sb/ectiranscriptsid6209612-Tba7-4607-8550-483ed819.... 4/12072721, 459 PM Inroduton to Age Sotware Development Transcript individuals and interactions over processes and tools. So that's essentially saying that we need to be people focused. And why do we need to be people focused? Well, people develop software and some of the values that ‘we can use in order to help people develop software is this team-focused approach. We can make the team our core responsibility something to focus on. We can help increase and improve interaction between team members as well as wanting to be able to help team members collaborate with one another. And those values can help us achieve some desirable outcomes. Those are things like clear communication between team members. The possibility for innovation, the ability for people to be able to have the space, and the support to innovate. Effective teamwork allowing team members to work effectively together. The idea that it will create adaptability within the team — that people will be able to adapt quickly to changes in the project, as well as ownership. Creating a team-focused approach with interaction and collaboration can definitely help with having tes members feel some sort of an ownership to what they're working on. So the second part of our Agile Manifesto is the idea of working software over comprehensive documentation. Obviously, with documentation, there can be a burden of heavy documentation that can slow everybody down. So, in Agile, we want to steer away from that. The documents that we create must support product development. And that's really important, they can't hinder it. They should not really be focused on what is done so far or what will be done. They're more focused on the software functionality — on the piece of functionality of the software that you're going to be building. And all of these values can help achieve some desirable outcomes like more time spent developing as opposed to reading or developing documentation, Regular code review and iteration that can help fix problems as opposed to spending all the time up front trying to discover those. Project feature completion — so these features of the project get completed quicker. And clearly documented requirements, when you start to focus on discrete pieces of functionality, you can write better documentation for them that are short and clear. The third thing we're going to look at in our Agile Manifesto is this idea of customer collaboration over contract negotiation. So you want your customer relationships to be formal and informal, ‘And the way, I guess, develop customer collaboration is through that kind of communication with both formal and informal collaboration as opposed to any kind of strict contract negotiations. The emphasis really is on collaboration over conflict. You want to involve the client without butting heads with them. The way you can do that is through the use of communication software and that helps keep the client up to date. So it's collaborating with them, letting them see, being transparent. The clients can also tweak requirements so that helps develop a stronger relationship with them. They see that they have an input through the process consistently and constantly. And that leads to things like flexible contracts, the ability to be able to have a flexible contract with a client that's not set in stone. And that changes are made for improvements so changes can be made to make processes better. And then there's this idea of mutual responsibility that both you and the customer are somehow responsible for the outcomes of this project. So allowing them to have collaboration and a window into what's happening helps them feel responsibility for getting the project done. They have a role to play in getting it delivered. The fourth concept that we'll look at is this idea of responding to change over following a plan. And we can look at that from the idea of using something like a flexible project ‘management system to help us respond to change, something that can change with us. Adaptability and rapid response to change, that's something that as an Agile team you want to be adaptable and be able to respond to change rapidly. And then, obviously, it's important to know that many factors may change over the course of a project. So, if we have tools for managing change, it's going to help us respond and adapt better. We can also look at things in a different way. We can approach them so we can see through the lens of challenges become benefits. Instead of challenges becoming things that slow the project down, we see them as a benefit that can help the project to help us adapt and learn more quickly. And some of the desirable outcomes of this is that we have this predictability of change. It's no longer a change, it’s not a thing that surprises us. ‘Change is a thing that we understand will come and it can be predictable. We also become easier at adapting so the outcomes would be that it's easier to adapt to things because we're used to it. Progress tracking becomes something that is consistent and happens regularly. And then, there's this idea of transparency that the flexible project management system, the tools that we're using, it helps to create this transparency within the project. So those are some of the values of Agile software development. hitpstcdn?[Link]/securele/ 1635399612, eff708432ec017120e07 12800458381 Bfaa0Sb/ectiranscriptsid6209612-Tba7-4607-8560-483ed819.... 5/1210127121, 4:50 PM Introduction to Agile Sofware Development Transopt Agile Best Practices [Topic title: Agile Best Practices. The presenter is Colin Calnan.] In this video, we're going to identify Agile software development best practices. So the first thing we're going to look at is product backlog and ownership. So what should we be doing in order to maintain product backlog and ownership? The first thing we could look at is the idea of prioritized features lists. That is a list of features with some technical information about those features. What those features are made up of and what they require in order to be built. There should also be the idea of some sort of a list of bugs within our product backlog. And knowledge acquisition, things that we've discovered that need to be recorded and stored in there for review or for reference. As well as that, we have this idea of functionality description. We want to be able to list and describe the functionality of these individual prioritized features in our list. And, that is through this, the use of what we call user stories. User stories built around the idea of a task or a scenario that a user carries out and what the outcomes might be. And then it's also important to identify the product owner role. You want to have one individual within the team who is the product ‘owner, who owns the movement and is the responsibility that they ensure that the stories are correct, that they have ownership around the product backlog. As well as that, we have the idea of the Serum master role and the Sprint backlog. So the Scrum master is the person who essentially guides the Scrum team, They are generally a process owner. So they own the process of how all of that works. They also manage the backlog with the key stakeholders. So they will communicate and discuss how the backlog is being set up with the key stakeholders. They also help prevent over commitments on team members. So they work to make sure that that doesn’t happen. They organize sprint planning, so they make sure that the sprint is planned and that the dates are set. They also work with defining what the sprint goals are. What are the goals of the sprint in terms of the prioritized features in the backlog that we can get done? And then they also, as I just mentioned, ensure that the backlog is their responsibility, and that they're able to prioritize it and set it up correctly. So, as well as that, there's this idea of individual input and commitment, So it's important to have individuals within the team be committed to their work, And the way we can do this is through things like short, frequent meetings. The daily standup is a good example of that, or the daily Scrum. Where you come together for a very short period of time to discuss what you did the day before, what you're doing currently and any hurdles or blockers that are in your way. There's also the idea of planning poker, where the teams sit down together and go through this essentially game of estimating between them. It can help result in more input into solving problems and giving some better context to estimates. Also this idea of team self-organization, the team should be able to communicate with one another without the need for a centralized person to communicate between them. There's also the idea of mutual commitment between the product owner or the Serum master and the individual team members that they have a mutual commitment to each other and to the project. As well as that, it's important to have an open workspace where you have things like whiteboards, and you have your charts and everything that you need for individuals to be able to see in one space. So that they can work together. Go to the white board together or start working things out. As well as that, some things that are good to have are like a window on an open workspace that everybody can go to, to have a break every once in a while. Another thing that you want to make sure is that people move around within the project. You want to make sure that individuals have dipped their toe, basically, in all of the different parts of the project. So that they are not sidled into one specific part and they just work in that one. Some other best practices are things like bum down charts within the project management. We can create burn down charts that show how ‘we've progressed so far in term of our estimates, and how much time we have left. So are we on target, are we off target for the sprint? Sprint review meetings, so once your sprint is over you sit down to review what happened in the sprint. Any things that you could have learned, mistakes that were made, things that could be carried through, sprint retrospective. Actually the sprint review meeting is where you review what's done with the client and the customer up until now. The sprint retrospective is when you review what happened in the sprint in terms of things that could be leaned, how did the sprint go, etc. Released planning, obviously it's important that you want to be able to plan your releases, schedule them, make sure that everybody knows, create code freezes, etc. hitpscdn?2 [Link]/securele/ 1635399612. eff708432ec017120e07 1380045838 faaa0Sb/ectiranscriptsid6209612-Tba7-4607-A550-483ed819.... 6/1210727121, 459 PM Inroduction to Al Sofware Development Transcript And then measure project velocity. Somewhat similar to burn down charts, you want to be able to look at how ‘many pieces did we get done in this sprint, how many did we get done in the sprint before. Therefore, we can kind of project out that we can have the same number of things done in the next sprint, so this idea of velocity. ‘As well as that, coding standards. It's very important to have those. Pair programming can help with having some coding standards, as well as solving problems. This idea of creating spike solutions, small programs that can help solve difficult problems. We also want to make sure that the code is unit tested. So the smallest possible pieces of the code are tested to make sure that they work. And then regular acceptance testing where basically the delivered parts are tested to make sure that user stories have been correctly implemented in code. So those are some of the development best practices when using Agile. Agile Software Development Life Cycle [Topic title: Agile Software Development Life Cycle. The presenter is Colin Calnan.] In this video, we're going to describe the Agile software development life cycle. So as I mentioned before, there's lots of different kinds of Agile software development, but they all kind of follow the same basic approach. And that approach remains the same depending on whether you're using Scrum, Extreme programming, or some other Agile method. Step one in this process is this idea of project initiation or starting the project. Here's a graph that kind of outlays the Agile life cycle. So you can see that it’s cyclical, it’s in a circle. And here are some of the parts, some of the components of that development life cycle. So here on the left, you can see that the first part is to start the project, and this happens once. So we start the project, and we initiate the project. And what we do then is we kind of define what the project is, what its goals are. We help create some guidelines around what the project's requirements might be, so we start defining what exactly it is. And maybe in this point, too, we'te doing things like setting up our environments to make sure that everything is the way it is and we're ready to go for development when it starts. So then the next step would be feature development, we jump into developing features. We dig into our backlog, we start working on things. And then we start integrating those pieces of functionality into the system and testing them. Then, if the tests succeed, what we do is we move on to the stage of, well actually what we could then do is go back to working on integrating and building more functionality and integrating and testing. Build more functionality, integrate and test, more functionality, integrate and test, until everything passes their tests. ‘Then what we can do is move into the next steps, which is this idea of review, feedback, and approve. So we can have a look, see if the piece of functionality is there, provide some feedback on it, and then decide if i's been approved or not. Then if that has been approved, we push it forward for release. And then once we move that piece of functionality forward, what we can do is we can kind of record and make changes. So, if it has not been approved and it doesn't go to release, what we have to do is, we have to look at, okay, what went wrong? And then implement the changes until that function works. So there's this kind of record what happened and make some changes. And then we can move forward to adjusting and tracking. So we can adjust some of our behaviors in terms of what went wrong. And we can kind of reflect and prioritize and move forward into the next iteration of development cycle. Where we jump through into the next development phase and take it from there. So that’s an overview of what the Agile development software life cycle looks like. Agile Information Radiator [Topic title: Agile Information Radiator. The presenter is Colin Calnan_] In this video, I'm going to describe what an Agile information radiator is and how it works, So let’s start with an overview of information radiators. So what is information radiator? Well, it's a bit of a generic term, and it’s used to describe any kind of big visible chart, those big visible charts for our Agile projects. And those can be handwritten, printed, drawn, they could be digital. And usually what those charts contain is the latest information about what's happening in the project. ‘Those information radiators, they can help enable informative workspaces. So basically, it's possible for people to be able to see what's happening at any one time. So all of the information about what's happening in the project is available at a glance. Things like maybe the number of automated tests, the backlog status, the hitpslicdn2 [Link]/securele/1635399612. eff 708432ec017120e07 12800458381 fasaNsb/ectiranscripsid6209612-Tba7-4607-A550-4836d819.... 7/1210727121, 459 PM Inroduction to Al Sofware Development Transcript velocity, any issues that have occurred, the continuous integration status, and so on. What these information radiators do is they help promote responsibility and transparency among the team. If this stuff is always up on the wall and it's always visible, then it promotes ownership and responsibility of things. The team has nothing to hide from its visitors, from its stakeholders. And it has nothing to hide from itself. So it acknowledges and confronts problems and issues that might come up in the Agile project workflow. So here's just some examples of what they might look like on the wall. You would have a number of these different charts, whether they're handwritten, drawn, using Post-it notes. You ‘would maybe have a backlog, which would show all of the issues. The analysis state, in terms of some of the things that you're diving into right now. What's happening in development right now? What are the things that are being developed? Items that are in test and then elements that need to be signed off. So that’s an example of some of the graphs or the types of graphs that you might use. And then some tips for creating these information radiators. Obviously, the purpose of them is to help to keep the team focused on what really needs their attention, So you want to make sure you determine what to include. What are the things we need to get up here to help everybody feel included, and to promote transparency? You want to determine the method of presentation, are you going to do paper or is it going to be digital? How are we going to present this information? Obviously, the most important thing is that it must be easy to read, understand, and update. You don't want to create something that's going to take up time. The whole point of our Agile process is to tun things around quicker and get product out as fast as possible, So you don't want your information radiator taking time away from that. As well as that, you want to be able to make changes frequently to it and ensure that it's always up to date. Obviously, that's really important because it reflects the current state of the project at the current time, So it's important to keep it up to date. So that's an introduction and a description of what an Agile information radiator is and how it works. Agile Methods [Topic title: Agile Methods. The presenter is Colin Calnan.] Tn this video, we're going to look at the Agile methods. First one we're going to look at is the Scrum Agile methodology. This traces back to the 1990s when it was developed. And it's, essentially, an iterative process made up of sprints. And those sprints are time chunks of development that will happen in order to achieve that certain endpoint. It's an incremental development process and it’s built to adapt to continuous change. So it's built so that, as time moves forward, you can pivot quickly and change what's happening on your project. It consists mainly of this idea of user stories, which are stories based on users’ interactions with the system and what the outcome should be. And then its purpose is to create a potentially shippable product on each iteration. The next one we'll look at is Agile Modeling. Now Agile Modeling is basically a collection of values, principles, and practices for modeling software and documentation that we can apply toa software development project in a lightweight manner, Agile Modeling can be tailored into a full-fledged software development methodology, like extreme programming, for example. And luckily, this work has already been done in the form of what we call the Disciplined Agile Delivery framework. Now this is a framework that's a lightweight kind of guidance framework to help organizations streamline their processes and kind of create a solid foundation for agility within their projects. Agile Modeling is also a collection of best practices, essentially, things like test driven design, model storming, iteration modeling, executable specifications, active stakeholder participation. So there are all these best practices that help create what we call Agile Modeling. The next one we could look at is this idea of Extreme Programming. So Extreme Programming improves our software project in four essential ways, communication, simplicity, feedback, and courage. So extreme programmers constantly communicate with their customers and their fellow programmers, They keep their designs simple and clean. They get feedback by testing their software starting on day one. As well as that, they kind of deliver the system to the customers as early as possible and then implement changes as suggested. So they're agile, there's responsiveness and feedback. And then, obviously, every time they have a success, that kind of creates respect for the contributions of each team member. So that enables extreme programmers to kind of feel courageous when they're working in their projects to respond to the changing requirements and technologies. hitpstcdn2 [Link]/securele/1635399612. eff 708432ec017120e07 12800458381 faaa0Sb/ectranscripsid6209612-Tba7-4607-A560-483ed819.... 8/12072721, 459 PM Inroduton to Age Sotware Development Transcript As well as that, we have Adaptive Software Development, the ASD model. And it has this kind of principle of continuous adaption for the process. It's divided into four phases, the communication and planning phase, which is where the project specification documents, proposal documents, and then risk assessment, etc., are carried out. The analysis, requirements analysis phase, which is started only when a customer approves a proposal that was prepared in the first phase. So things like the quality of the software will be approved, an analyst would have gathered details and information. The software requirements spec document is produced in this phase. Then we jump into the design and development phase. That's where the ASD process would model a prototype and take a prototype approach to kind of verify the design and the requirements. And then finally, we have testing and deployment where test cases are created for the increments. And then each module, or each part of the software is tested, unit tested, followed by integration testing and so on. So that's that phase. And then finally, we have the Feature-Driven Development. Obviously, this is a kind of step-by-step methodology driven around the features that need to be created. So step one is to develop an overall model, so a kind of like detailed walkthrough with domain experts to help to create a large model for the work that needs to be done. Then it jumps into building a features list where you kind of decompose the domains into subject areas and then create categorized features lists and then plan by features. So you want to be able to dig in to each feature, work out the scenarios that are there, consider the assignment of tasks to people, as well as timelines. And then we jump into the design and the build by feature. So you want to be able to design the models around the software, and then work on building those models in the sofiware. So those are some of the Agile methods that can be used when working in an Agile software development framework. [These methods are Extreme Programming (XP) Agile Methodology, Adaptive Software Development (ASD) Method, and Feature Driven Development (FDD) Method.] Agile Management [Topic title: Agile Management. The presenter is Colin Catnan.] In this video, T'm going to describe incremental and iterative development — or IID. So what is incremental and iterative development? Well, it's basically the ability to be able to revisit phases of development dramatically and that helps improve project efficiency. Now the idea of revisiting these phases over and over is what we call incremental and iterative development. So the development's life cycle is essentially cut up into increments or iterations. And then each iteration touches on one of the kind of traditional phases of development. So, for example, with ID requirements as an ongoing process that's periodically revisited and then as new requirements surface and as the scope changes, the IID process continually captures the requirements iteration after iteration. So it's constantly revisiting the idea of capturing requirements and managing change of scope. So how does it work? Well, it goes back to the idea of lean development from the 80s. [The Lean development contains the continuously improve, create value for the customer, eliminate waste, optimize value streams, and empower people stages.] And it's based around the idea of continually capturing requirements iteration after iteration, So that's how it would work. The idea is that ITD allows for what we call multiple passes or iterations over a project life cycle to properly address complexities and risk factors that might get missed through a one-time through. And that's basically key to addressing these complexities and risk factors. As well as that, it enables experimentation and learning. There's this kind of trial-and-error approach that's almost encouraged or an atmosphere of trial-and-error created that basically helps...so like lead to more efficient innovation. And here we can see how that iterative approach works. In our graph here, we start in Phase 1 and we work through that and it continues on through the life cycle of the project. Periodically coming back to revisit Phase 1 and maybe change the requirements or modify the scope of it, in order for it to keep moving forward. And we see, those phases get shorter and shorter as we get towards the end of the product. And then finally, there's this idea of the feature of an iteration. What are the features of an iteration in our development? And in iteration in the context of an agile project — in this case — is a time box, essentially in which the development takes place. And that is a certain duration and that duration is usually a number of calendar weeks, maybe between one and four. And it's usually of a fixed length. So there's a fixed duration for that project. So let's say it would be a duration of four weeks per iteration, And then it starts with this idea of a vision and planning phase, where you work through the vision for what's going to happen and the planning for what's going [Link]/securele/ 1635399612. eff708432ec017120e07 1280045838 faaa0Sb/ectranscriptsid6209612-Tba7-4607-8550-483ed819.... 9/1210127121, 4:50 PM Introduction to Agile Sofware Development Transopt to happen over the next iteration, And then it would end with a closure phase of revisiting that talking about what worked and what did not work and so on. So that is a brief introduction to the iterative development. Agile Software Development Considerations [Topic title: Agile Software Development Considerations. The presenter is Colin Calnan.] In this video, we're ‘going to recognize factors to consider when moving to an Agile software development methodology. So the first one to consider is, are projects taking too long? So obviously, when you want to move into an Agile software development methodology, with Agile, results are delivered in short iterations, with frequent results, and generally, in weeks rather than in months. So that's the consideration, are projects taking too long? Then, if they are, then you should consider using Agile. Are changes in scope, cost, or schedule considerations? So, with Agile, feedback and discussion happen daily and can be approved immediately. So changes to scope ot cost or schedule, they're not cumbersome, and they can happen really easily. Large numbers of defects. So, if your current project maybe has a large number of defects, you might want to look at Agile. Because with each iteration in the process, defects are generally resolved quickly. The product is updated, and then deliverables are released and then tested functionally. So it’s the idea of failing quickly, which means that smaller and less frequent defects generally in the project. Inadequate communication. If you've got too many cooks in the kitchen, with Agile, team sizes are small, with stakeholders and lead developers comprising the core team. And then this can help facilitate communication between team members, and decision making as well. Conflicts are also easily resolved and quickly resolved, and tend to be handled at a more pragmatic level. And then resource dependencies, so things like QA testing etc., are dependent on one another before they can move forward, Then with Agile, all team members and decision makers are involved on a regular basis. And they've worked together throughout the iteration, so it can speed things up. If your testing is proving costly, then with Agile, since changes are approved, tested, and implemented during cach iteration, the change request costs are minimized. And then inconsistent workloads. So, with Agile, the resources being the team members, are generally more engaged and familiar with the product early in the process. That they're not waiting until a certain part of the product or project where they're working on it for a consistent period of time and then they're off if for another period of time. So those are some things with Agile, that Agile can help improve and provide benefits to. So some of the questions to ask if you've made a decision to try to give Agile a try. Some of the questions you could ask would be who, what, and how. So who in terms of, who are the stakeholders? Who will be the active people working the project? Do they have the capacity to participate in Agile? And who's responsible for completing the deliverables? And then with what, you could ask things like, what changes are going to be needed to our current software development life cycle, for example? Or are there any organizational changes that we'll have to implement in order to achieve a successful Agile implementation? Or maybe, are there any cultural roadblocks that might come up? And things like, what are you asking your IT professionals to deliver versus maybe operational professionals? And then finally, there's how. And this is probably the one with the most questions. How will you track changes and sprints? How will you ensure that people are ready to accept the change? How will you know that the project is on track? How do you evaluate the success of the project? And how do you ensure that collaboration and interaction and communication remains consistent and of high level throughout the project? So those are definitely some questions to ask when you're thinking of implementing Agile. And then finally, as well as that, you want to make sure that when you're implementing Agile, that i's always useful to get some outside expertise. So to bring somebody in and to bring in an expert on the team. So generally, if you're bringing in an expert, that expert should obviously understand Agile fundamentals. Even, if you're training up an individual to be an expert, you have to ensure that they understand the fundamentals and have the mechanisms in place to be able to succeed with Agile. They also want to be able to identify and mitigate risk across the whole process, being it people or technology. As well as that, they want to be able to provide leadership in the Agile space. So being able to make decisions, both things like the length of iterations, the definition of work, the definition of testing, etc. hitpstcdn?[Link]/secure(e/ 1635399612. eff708432ec017120207 1280045838 faaa0Sb/ectiranscripsid6209612-Tba7-4607-8560-483ed81.... 10/12072721, 459 PM Inroduction to Al Sofware Development Transcript Also you want to make sure that they can enable organization-wide collaboration. So you want to make sure that there's acceptance of Agile throughout the organization. And then you want to make sure that they have some practical experience that you can leverage so that you can use that for your team, So as well as that, here are some other elements that we need to think about when creating governance or providing governance for Agile development. So basically, your team should be aware of some of the challenges and constraints of Agile development. And on the other hand, they should also be able to choose the most suitable Agile method for the project. So they want to understand what the constraints and challenges are of Agile. And then be able to dig in to the various Agile methods to be able to select one for their project based on those challenges and constraints. And then once they should also find the best choice for Agile, considering which methods are best for them. So they can look at different adoption styles in terms of how Agile can be adopted into the organization and into their process. So kind of like a three phase process of understanding your challenges and constraints. Choosing an Agile method that works for that. And then figuring out how to adopt that into your current processes. So that was a quick overview of how to recognize factors to consider when moving to an Agile software development methodology. Issues Transitioning to Agile [Topic title: Issues Transitioning to Agile. The presenter is Colin Calnan.] In this video, we're going to recognize the issues organizations can face when applying Agile principles in given scenarios. So let's look at some of the challenges that teams can face when implementing Agile. So the first one to look at is management and organization challenges. So, for Agile transformation, all aspects of the organization are going to change. So that fundamental change is going to cause some challenges. As well as that, coaching and mentoring in this process can be difficult because of not only technical problems that have to be solved, But also, the mindset of people need to be considered. You could also have knowledge-management issues. So generally, the plan-driven methods have heavy documentation, and rigid reports are required. However, in Agile, it requires a little less documentation. And it’s a little bit more responsive and rapid. So that can cause some problems with people who are used to managing things with heavy documentation and rigid processes. There's also some issues in changing to an iterative software development life cycle. Obviously, that idea, the traditional life cycle, it can cause conflicts for people that have difficulty understanding how to move from that traditional life eycle to a more iterative one. And then there's differing measurement practices. Obviously, with the quicker iterations, things are measured differently. And then a lot of obstacles are reported when this happens when you switch to Agile Sometimes it's difficult for people to forget their previous role. And then they can be a bit resistant to change. And then, as well, there are some project management challenges that come up. Because obviously, the project ‘manager, they should be leadership instead of being a commander. So they have a very different role than they might normaily have in an Agile process that they might have in a more traditional one. And then there are some challenges in the work environment. So for example, the lack of face-to-face communication or different cultures and time zone may cause issues with an Agile development process unless it's managed carefully. So as well as that, there can be some confusion and misunderstanding about the process. It can be a cultural challenge for people who have been used to doing things and how they spent every day. To have a new process dropped on them can sometimes be a challenge. As well as that, this idea of estimates versus deadlines. People have a common misunderstanding about that. Estimates and deadlines are not the same things. And that can be difficult for people to get used to if they've come from a scenario of deadlines where things are due, as opposed to creating estimates, And that can have some issues in terms of people adjusting their expectations accordingly. As well as that, there can be confusion over roles. So obviously, project management versus product ownership, scrum master versus project manager, ete. So that can be something that is challenging. And then confusion with cross-functional team formation. Obviously, people may be used to working within their silo team within their specific department. And then the introduction of a cross-functional team is something that they struggle to have to get used to. As well as that, a rapid approach to change may work best. So trying to go slowly and do partial or gradual Agile, it does not work. You have to just jump right in and go full Agile all at once. And then there's also this idea of an acceptance of a flat structure. Obviously, people are used to maybe a hierarchical way of working within a team, But within the hitpscdn?2 [Link]/securele/1635399612. eff 708432ec017120e07 12800458381 BfaaaDSb/ectiranscripsid6209612-Tba7-4607-A560-483ed81... 11/1210727121, 459 PM Inroduction to Al Sofware Development Transcript Agile methodology, generally, things are on a flat structure where everybody's working together towards the same thing. So that can be difficult for people to get used to as well. As well as that, there can be some resistance to change. So for example, people might be actively resisting things, where they try to sabotage the process, or they'll bad mouth it. Or they may be passive in that they'll go along with it. But they'll say to themselves, well, who cares, why? I'm just going to do this, but I don't really care about it. ‘You can have unconscious resistance, where people are resistant to it. They're just not aware that they're resistant to it. So over time, they put up resistance to it in ways that it just happens unconsciously. And that generally, others may try to block participation. So they may do things that prevent others from participating in it. As well, as we covered, they might just pretend to go along with it. So they're saying, well, I'm not really interested in this. It doesn't really apply to me. But I'm just going to go along with it anyway. The resisters can cause a lot of damage to the process. Because, for example, maybe their job is testing, ‘They might just do enough testing to just get by. And then assume that the other tester is just going to do the real work, and leave it at that, So something that you might need to do in order to fix this is that you must build momentum to overcome resistance. So you want to make sure that you start this quickly and that you build enough momentum. ‘What you can do is create the feeling within the organization that this change is inevitable, that we're doing this. It’s going to happen with or without you on board. So it's like, create, you want to break through inertia with as much momentum as possible. As well as that, there can be difficulty adapting, so failing to adapt to new roles. People may take on a new role, and they just can’t change their existing processes to do that. Intimidation is obviously another big thing. With teams managing their own work, members have much more responsibility for prioritizing and decision making. And this can feel like additional pressure. Group self-organization, obviously. If people are used to a specific hierarchical structure where they're given instructions, it can be difficult for them to self-organize within groups. Small cross-functional teams. Again, without the experience of working cross functionally, it can be difficult for them to get on board and become embedded in these small cross-functional teams, And then, obviously, incomplete adaptation to Agile methods. Where they maybe keep some of their old systems and old ways of doing things and take on some of the new Agile ones. But if you skip it, you're basically diminishing the value of it. So the idea is, it's all or nothing. And then training in Agile methods. Obviously, you want to make sure that your team is trained up as much as possible. And that they have all of the supports that they need for moving their process to Agile. Exercise: Identify Agile Principles Exercise [Topic title: Exercise: Identify Agile Principles. The presenter is Colin Calnan.] In this exercise, you will identify the advantages of Agile over the Waterfall approach. Identify the principles of Agile software development. Identify the values of Agile software development. Identify Agile software development best practices. And describe the Agile software development life cycle. So pause the video, find your answers, and then we'll come back and walk through them. Solution Okay, the first one we look at was to identify the advantages of Agile over the Waterfall approach. And there's quite a few. Just cover a few of them here. So one is that Agile is a non-linear approach. So it's iterative, it welcomes change. It also helps create coordinated teams. It involves the customer earlier. It creates a sense of ‘ownership for the customer, It reduces the time to market for a product, And it also helps with user-focused development, If we look at identifying the principles of Agile software development. We can see things like some of the principles around that are self-organized teams, team self-reflection, Close and frequent cooperation between team members, Face to face communication, changing requirements in the project. ‘The measure of progress, rapid software delivery. Customer satisfaction, motivated people. Sustainable pace, attention to good design, and simplicity. The next question was identify the values of Agile software hitpscdn?2 [Link]/securele/1635399612. eff 708432ec017120e07 12800458381 BfaaaDSb/ectiranscripsid6209612-Tba7-4607-A560-483ed81... 12/19072721, 459 PM Inroduton to Age Sotware Development Transcript development. Okay, so some of the values we could look at here, And the four values in particular that we'll look at would be individuals and interactions over processes and tools. Number two would be working software over comprehensive documentation, Number three, customer collaboration over contract negotiation, And number four, responding to change over following a plan. The next question, to identify Agile software development best practices. Again, there are quite a few of these. We'll cover a few of them. So some best practices would be to establish a product backlog and ownership of the process. To create a prioritized feature list, to write functionality descriptions or user stories. To create a product owner role and create a scrum master role. To do sprint planning, to write sprint goals, and to manage the sprint backlog. As well as that, you could do things like short stand up meetings. Do planning poker for estimating or planning. Work at getting self-organized teams, maybe have an open workspace. Create burn down charts, measure your project velocity. Implement some coding standards, and work to have pair programming on your team, And then finally, let's describe the Agile software development life cycle. So this is obviously a cycle, so step one would be start the project. Step two, define what the project is, and what its goals are. Step three would create some {guidelines for the project's requirements, Step four, develop a software function. So we're getting to development, so start developing a software function. And then steps five and six would be integrate the function and test the function. So develop, integrate, and test. Then seven would be if the tests succeed, then move onto the next function. And repeat the develop, integrate, test for each function as they pass the tests. If the test doesn't succeed, then what you need to do is record what went wrong And then implement the changes until that function works. Then following that, you need to reflect and prioritize, based on client feedback and new challenges. So once you've integrated your functions, you can reflect back and say okay, there's some feedback from the client and some new challenges. We need to reflect and re-prioritize. And then once everything's been tested and integrated, you then release the function to the ‘market. Then you move on to the next function, and then repeat the steps over again, So the develop, integrate, test. If something went wrong, reflect and prioritize, and then test and integrate again, and then push to market. That's the description of the software development life cycle. [hope you're able to answer those questions. As T mentioned, there are many answers to most of those questions. And if you got some of those, then that should cover it mostly. hitpscdn2 [Link]/securele/ 1635399612. eff708432ec017120e07 12800458381 faaaDSb/ectiranscripsid6209612-Tba7-4607-A550-483ed81... 19/12