Agile Explained - Understanding the Core Principles of Agile Software Development | Stephen Haunts | Skillshare

Agile Explained - Understanding the Core Principles of Agile Software Development

Stephen Haunts, Trainer, Public Speaker, Author

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
14 Lessons (42m)
    • 1. Introduction

      1:40
    • 2. History of Waterfall

      1:55
    • 3. How Does Waterfall Work?

      2:07
    • 4. Where is Waterfall Suitable?

      1:49
    • 5. Advantages and Disadvantages of Waterfall

      5:13
    • 6. What is Agile?

      2:26
    • 7. The History of Agile

      0:42
    • 8. The Manifesto 4 Core Values

      3:02
    • 9. Methodology Overview

      2:22
    • 10. Roles Within an Agile Team

      1:40
    • 11. Common Agile Misconceptions

      7:52
    • 12. Advantages and Disadvantages of Agile

      8:43
    • 13. Are you Prepared for Agile?

      2:16
    • 14. Thank You

      0:29

About This Class

Why Agile?

Agile is one of the great buzzwords in software development, but it is so frequently misunderstood. For example, many companies think they are doing Scrum and being agile because they are working in iterations and have planning meetings, but when a change in requirements comes along, the project stops and replanning/design takes place.

What You Will Learn?

In this course, I will explain what it means to be Agile by looking at the core principles of the Agile Manifesto.

In this course we will look at:

  • The history of the waterfall model
  • How traditional waterfall models work
  • Where is the waterfall model suitable?
  • Advantages and Disadvantages of the waterfall
  • What is Agile?
  • The history of Agile
  • The four core values of Agile
  • Methodology overview
  • Agile roles within a team
  • Common Agile misconceptions
  • Advantages and disadvantages of Agile software development

Who Is This Course For?

This course is suitable for anyone who is going to work on an Agile team or go through an Agile transformation. No matter whether you are a software developer, business analyst, tester, or business person, this course will give you the fundamental understanding as to what Agile stands for and how it can benefit your team and business.

Transcripts

1. Introduction: Hello. My name is Stephen Holt welcomes by cause I John explained I'm a software developer leader that's over 25 years. Experience like an industry. I'm also online trainer that each classroom workshops all around the world and as well as all that I'm a poppet, speaker and author recently created. This course is because of my career. I spent a lot of time working in companies who believe they're being agile. You're going in. You observe that, ensuring that they didn't scroll restorations, what can ban boards and stories. But then, when a change comes into a requirement, kind of all hell breaks loose. And you know this kind of panic. So Oh my God, things are changing what we're going to do. People have to go to the top departments for approval. They could generally be quite a mess on its not drunk. That's not what our jobs about. So in this course onto strip away. A lot of project management methodology is this course isn't about scrum. It's not about extreme programming. Whether you talk about briefly, this court is actually about the core principles of agile what it means to be a joke and provided you follow those core values, then you could be agile. It doesn't matter if you're doing scrum XP or whatever. The latest favorites methodologies. Why do you follow these four core values? Then you could be a job. So with that, let's get started. If you enjoy the course, I'll be very grateful if you could follow me. I see some of my future causes. Also, if you do enjoy the course, I'd be very grateful if you could shut out on Twitter when it for social media size be fantastic. So with that, let's get started. 2. History of Waterfall: hello and welcome to my cause, Agile explains. I'm your host, even horns in his course. We're going to look at the core principles of agile software development and dispel some common misconceptions. This isn't a course about scrum or extreme program in, as they are merely techniques to facilitate agile software development. This course is about the core principles that all agile teams need to adhere to. Let's get started by looking at the more traditional water for software development process and its problems. If you're not working in an agile based company, then the chances are you're working on a form of water for software developments in its first section. We're going to look at what water for is and identify its main problems, which will lead us onto talking about agile in more detail. The waterfall development methodology was introduced by the computer scientist Winston Royce in 1970. Winston Royce first discussed the idea of agile software development in an article called Managing the Software Developments of Large Software Systems. Royce didn't refer directly to the model in his papers. Wars for developments. This article was about process that was flawed for software developments, was his original design actually showed more repetition between stages of the model, which was for doesn't let You do Winston Voices. Actual model was more intuitive in how it works on allowed more room to maneuver Between stages. We'll discuss a more frequency of way of working with me. Discuss Agile later in this course. Although voice didn't refer to this model was awards for Model directly, he is credited with the first description of what we referred to is the waterfall model. Russia's original article consists of the following stages, which will go into more detail on in a moment. The stages are the requirement specifications stage the detail design stage, construction phase integration, testing and the buck in installation and maintenance. So it's not. Take a look at how the waterfall model actually works. 3. How Does Waterfall Work?: in waterfall. The process is divided into separate stages, where the outcome of one stages input into the next stage. The first stage in the water for was start with requirements covering all of the requirements. Analysis. Where all of those requirements for system being developed are recorded in our specifications. Documents, requirement, specifications. Then let's be signed off by another project stakeholder, usually from the business. It is the responsibility of the business analyst on the project to create the requirements documents. If you're waiting on a smaller team, that it could be done is a collaboration between team members in this stage of the waterfall cycle with business analyst or persons right in a document, try to capture all of the requirements and features of the system from the key business stakeholders. This could include the complete set of functionalities Any business, wasn't it automating and then you have operational processes from a company and regulatory perspective. The next stage assistant design the requirement specifications from the first stage or inspected and assistant designers put together. That's Ryan helped in specifying the design requirements and also helped create in the oval systems architecture. In this stage, it is a technical members of the team, which includes developers and architects that decide how the overall system will be built. Once a system designed faces complete, we move into the implementation phase. This is where the developers on the team take the previous software design and start writing the code to make it work after the implementation face where they move on to the integration and testing phase. This is where the testing team will bring all of the's system components together and test him is a single product. The test team at this stage should have a detailed testing plan that they work towards by even performing manual testing or developing automated tests. Once the testing team has completed its work and signed off, the system is fit and proper. It is then ready for deployment to the end users. You could start seeing the benefits once a solution has been deployed into production, then go into a maintenance phase during this period. If the end users report any defects they will need to get fixed, tested have been redeployed into production. If any of these figures is end up being very large in scope than a decision might be made to start the waterfall again by redefining the requirements. Designing the implementation, testing and then redeploying if this happens only can be quite time consuming, which doesn't lend itself to fix this had to be made urgently. 4. Where is Waterfall Suitable?: while in the Adroll world, there is a lot of emphasis on saying that water for is not suitable. There are, however, some projects when, what for methodology is appropriate. Let's take a look at a few. First of all, what for is suitable if your software project requirements have already well defined documented. But in reality, how often is this the case from my own experiences? A software designer and developer, I can't remember any of the many projects that I've delivered where the requirements have been clear from the start so they can be captured in the document That doesn't change is a project rolls on next, the product definition must be stable. Okay, and I can't think of a single project where this has been the case for May. As external factors like changing the marketplace or shifting business, priorities mean that your product will evolve. I've worked on many projects where the final deliver product was entirely different from what was initially specified underwater, for this shouldn't happen. But in reality, what you're building can change nothing wrong with these baby. That's fight against a software delivery process. Next, the technology should be well understood. This means that developers should understand the technology is there going to be using and how they work. Once you went to the implementation of construction phase of the project, developers usually have to work towards very rigid and set timescales. In my experience, working on the water for project, a lot of effort is expelled of the requirements and design phase, which normally eats into the time needed to actually develop the code. Next waterfall works best on projects are short on. By short I mean projects around 2 to 4 months in total. The longer the project runs for, the more chance there is that the requirements and product definition are becoming out of date. Finally, what for Works best. When all of your product team are available to work together, it is quite normal for a development seem to have a port of resources. It might be shared out between many different projects. If another project is over, run for any reason, then you may not have all the people available at the time and now required this can significantly impact of projects timescales ample delivery dates at risk 5. Advantages and Disadvantages of Waterfall: I want to do now is take a look at some of the advantages and disadvantages to the waterfall model. The first advantage is that by splitting your project, deliveries into smaller stages is easier for an organization to maintain control over the development process. This makes it much easier for schedules to be planned out in advance. This makes a project managers life much more comfortable. It's for this reason that I found the experience. Project managers tend to favor the waterfall process as you could make their lives a lot easier. Let's listen a project down into the various faces of the waterfall process. You can easily departmental ISA delivery of your project. You can assign different roles to various departments and get them. A clear list of deliverables and timescales if any of these departments can't deliver for various reasons, is easy for a project manager to adjust a rifle plan. Unfortunately, in reality, I've seen the method adapted where the implementation phase gets squeezed warm or which means the development team has less time to deliver working solution and it's coming. Quality suffers and short cuts tend to be taken. It's usually code based units and integration test that get affected first. This has a knock on effect of testing teams in the testing phase as they get a solution. It contains more problems, which makes their lives very hard. So while departmental ization is seen as an advantage, it can quickly become a disadvantage if another team is late in delivering their part of the project towards full model doesn't allow for any time for reflection or a vision to a design. Once the requirements have signed off, they're not supposed to change. They should mean that the development team has a fixed design, that their glands, words, words. In reality, this does not happen, and changes in requirements can often result in chaos as a design documents need to be updated and re signed off by stakeholders. By the time the development team start So work there are pretty much expected to get it right first time and they're not allowed much time to pause for reflection on the code that I have implemented. But the time you get to the point where you think a change of technical direction's required is normally too late to do anything about it unless you want to effect the delivery days. This could be quite the motivating for development team they have to proceed with. 10 include implementations, full of compromises and technical debts. Once the product has entered, the testing stage changes virtually impossible. Whether that is to the overall design or the actual implementation water for was a simple process. Understand non paper. It seems like a good idea for running a project. The waterfall is also easier to manage your project managers. Everything is delivered in stages. It could be scheduled on plans. Treasures are completed one at a time where the output from one face is fed into the input of the next stage. Waterfall works well for smaller projects where the risk of changing requirements and scope is lower, each step in the water for a very clearly defined. It makes it easier to assign clear roles. Two teams and departments you have to feed into the project cause each stage is well to find. It makes a milestone set up by the project manager. Easier to understand. If you're working on a stage at requirements analysis, you should know what you need to deliver to the next stage on by when underwater for the process and results of each stage of all documented. Each state has clear deliverables documented and signed off by key project stakeholders towards for model fits very neatly, INS began Charles, So a project manager is happier when they complain everything. Kautz and view the project Timeline in application That works of projects. One of the biggest disadvantages awards for models. You don't get any working software until late in the process. This means your end users don't get see their vision come to life until it is too late to change anything. It can be tough and on technical people to be clear about how they want an application to operate, and it's normally until they can visualize an application that they can give good feedback . You can mitigate this by doing from prototyping in the system design face to help uses, visualize their system. There's nothing like given an actual working code, and software to try out towards for model could introduce a high level of risk and uncertainty for anything but small projects. That's because a set of requirements and design has been signed off does not mean that the conditions won't change towards for was about getting the requirements, design and implementation right. First time, which is a grand idea in a perfect world but in the real world is very rarely the case, and it is a big risk to a project. More complexity that is involved increases the risk of trade needed further down the line. Complexity in the system is also very hard to implement and test it can often cause delays in the later stages of the water for software development. Life cycle If you're working on a project where change is expected, their want for is not the right model for you. I've worked on projects of financial services companies where variations in financial law because in compliance or regulations to change. Unfortunately, these rules are very open to interpretation, which meant the legal team was involved in a very early stage. This meant that the interpretation changed a few times during the project. If this had been awards for project, we have been in big trouble. Products frequently come of a fixed set of deadlines. This was a perfect fit for natural project. If you're working on a large project in the scope changes, the impact of this could be so expensive and costly that original business benefit for the project and evaporates. And then the project has counseled. I've seen this happen a few times, and it's a real shame, as projects that show real promises stops due to restrictions in the process. Finally, the integration and delivery of a project had done as a big bang on awards for Project. This means you're going to introduce massive amounts of change or at once it's going quickly overwhelmed testing teams and you operational teams. 6. What is Agile?: now that we're taking a look A more traditional water for software development process. Let's now start investigating alternative, agile software developments. After all, software development is a set of software development practices that promotes an evolutionary design with teams that can self organize themselves. At our software. Development inspires evil injury software development, adaptive planning methods, an early delivery of value from your software to urine customers. The word agile was first linked to development software back in 2001 when the agile manifesto was devised by a group of visionary leaders and software developers. I'm not traditional dial it and practices like waterfall agile methodologies. Such a scrum and extreme programming are focused around self organized cross discipline teams who practiced continuous planning and implementation to deliver value to their customers. The primary go of agile software development is to deliver working software that gives value sooner to the end user. Each of these methods emphasizes ongoing association between technology and the business for whom you are developing the software, after all, software methodology, is a considered lightweight that they strive to impose a minimum process and overhead within the development life cycle. Adroll methods are adaptive which means I support changes in requirements and business priorities. For out the entire software construction process changes. The natural requirements are to be embraced and welcomed with an agile software development project. There's also considerable emphasis on empowering teams of collaborative decision. Make him. Earlier, I talked about how the waterfall based development process follows a series of stages which results in a big bang of deployed software at the end of the process. One of the main ideas behind the agile software development is that instead of delivering a big Bang release into production it into the project, you released multiple versions of working codes your stakeholders continually. This will allow you to prioritize features that will deliver the most value to the users sooner so the organization could get an early return on their investments. On that investment comes in the form of money spends and time consumed in developing and planning the number of deliveries into production. That you do depends on how long complicated project is, but ideally, you would like to deliver working software at the end of each sprint or iteration. I love a good way to visualize the premise of our Joe is in the diagram you concealing screen. Now what this diagram shows is if agile software you deliver incrementally instead of all at once. You should hold his fault in your mind as we progress through the rest of this course. 7. The History of Agile: There's been lots of attempts to improve software development methodologies over the years , and many of these have looked at working intrusively. These new practices didn't go far enough in trying to deal with changes in requirements to customers. In the 19 nineties, a group of industry software Fort Leaders met at a ski resort in Utah to see you can define a better way of developing software. The term agile software developments emerged from this cavalry. The term was first used in his manner and publishing. The now famous Agile Manifesto Theater manifesto was designed to promote the ideas of delivering regular business value to your customers and made it necessary that you should focus on a collaborative, cross functional team to make this happen. 8. The Manifesto 4 Core Values: the federal manifesto is probably the most important artifact that we can look out when it comes to agile software development. It doesn't matter what your influence in Squam extreme programming when If you have a project management methodologies, you're not following the values in the agile manifesto, then you're not doing adroll properly. So let's take a look at the four core values. These are individuals and interactions over processes and tours, working software over comprehensive documentation, customer collaboration over contract negotiation and finally responding to change over following a plan for the first core value. We have individuals and interactions over processes in schools. People build software systems and still this properly, they only to work together and have good communication between all parties. This isn't just software developers but includes Q A business analyst, project managers, business sponsors and senior leadership and anyone else involved in the project or product at your organization. Processes and tools are necessary, but they are irrelevance of people working on the products cannot communicate and work together efficiently for a second of the core values. We had working software over comprehensive documentation. Let's face it, who reads 100 page products back. I certainly don't. Your business users were much preferred so small pieces of functionality that are delivered quickly so they can then provide feedback. These pieces of functionality may even be enough to the point to production to gain benefit from them. Early old documentation is bad, though, when my teams why it's on a project they used to use visual diagramming tools out physio to produce diagrams such as deployment diagrams, database scheme in software layers and use case diagrams. We typically print these out on a three prints and put them up on the wall so they're visible to everyone. Small, useful pieces of documentation out there so invaluable 100 page products, backs or not. Nine times out of 10 large items of documentation are invalid and out of date before you even finish writing them. Remember, the primary goal is developing software that gives business benefits, not extensive documentation. I prefer to the core values. We have customer collaboration over contract negotiation. Well, the software that you developed should be written. If your customers involvement Be successful in software development, you need to work with him daily. It means inviting into your stand ups demo into them regularly and inviting him to any design meetings. Only the customer can tell you what they want. They may not be able to give you all the technical details, but that's what your team's, therefore, to collaborate with them, understand their requirements and into deliver for them. But a four from final Call value we have responding to change over following a plan your customer or business sponsored may trained your minds about what is being built. This may be because you've given them new ideas from the software you've delivered on a previous situation. It may be because the company's priorities have changed or new regulatory changes have come into force. The key thing is here you should embrace it. Yes, some code may get thrown away and sometime may be lost. But if you're working in short alterations and this time lost, his minimize change is a reality of software developments, a reality that your software process must reflect. There's nothing wrong with having a project plan. In fact, up, you're worried about any project that didn't have one. However, a project plan must be flexible enough to be changed 9. Methodology Overview: Now that we understand the main core values of the agile manifesto, they're commonly used to underpin different methodologies, which is why Adroll becomes more practical. Let's take a very high level. Look at some of the common methodologies Aaron used today. This course isn't about any one particular methodology, but issues will take a glass of somebody methodologies that are out there successful we have Scrum Scrum is a lightweight project management framework that is based on an interactive working model. Ken Schwab might be Door Jeff Succulent and offers contributed the developments described over the years over the last few years. Screamers own growing popularity in the software development community because of its simplicity, proven success and improve productivity and its ability to work with very suffer engineering practices promoted by our fragile methodologies such as extreme programming. So next we have Extreme programming or Ex Pays is also nine Extreme programming was initially devised by Ken back and has emerged one of the more popular and controversial agile methods. Extreme programming is a disciplined approach of delivering high quality software faster and consistently emphasises lots of customer engagement, rapid feedback leaps, continuous testing, continues planning on teamwork to deliver working software. Frequent release cadence typically 1 to 3 weeks where a scrum is a project management framework. Exp is more of an engineering discipline. It is very common for teams to adopt scrub, yet borrow different engineering practices from extreme programming. The original Extreme programming recipe was based on fork simple values, simplicity, communication, feedback, encourage. There's also 12 supporting practices. Thes are the planning game small releases, customer acceptance tests, simple design pair programming, test driven development, re factor in continuous integration, collective code ownership coding standards, metaphors and sustainable pace. As I've already stated, though, this course isn't about scrum or extreme programming, The important message for you to learn in this course is what Pageau itself is all about. I've seen some teams think they're doing scrum, but actually when it comes to looking at the four core values, if a change comes in on the project and then has to go off to some advisory boards be discussed, approved undocumented, even though it looks like you're doing agile, what in scrum? Actually, you're not. So it's the four core values I want you to focus on in this course 10. Roles Within an Agile Team: at old teams was part of a department of a company primarily focused on their software development goals. Each team should also be focused on their teams overall vision. This means a team should be very reactive in doing whatever is required to get the job done . This means that team members may also have to work outside their normal skill sets. They should be embraced and encouraged. A cross functional adaptive team is much more likely to succeed. Most teams, of course, will have some standard areas of expertise and special ISMs, and you may also have people in particular domain or product knowledge. But it should be flexibility and team players expected roles and responsibilities. You should also be common for team members have access to the business as a whole, and they shouldn't be just limited to a select few. You should have people who are tasked with making sure the team's followed the development process, and someone who coordinates the requirements gathering with the business it's for typically be referred to like the product owner. If you're working within scum, framework, teams will normally have some form of leadership role within the team in scrum this person is the scrum master on agile teams. His person aims to enable and ensure the success of the team, the type of leaders frequently referred to as a servant leader. This role is entirely different to a direct, transactional lead on a waterfall project. One go oven agile team should be to improve as a team every day. The larger the organization, the more complicated group structures can get. Cross project teams, shared services, operations, configuration management and database administration could also come into play. But the goal remains the same. To find a software project and cross functional team capable of delivering on a plan and empowered a team to do so. 11. Common Agile Misconceptions: when a team is need to agile, it could be half of them to adjust to a new way of working, especially for used to working under awards for based methodology. When a team is faced with changing, how they work is common for excuses to be made by team members as they resist the change. No teams like this, but in my experience, it's quite common to hear many different misconceptions in this section will discuss many of these misconceptions and why they come about. Yeah, Joe is at hark with no process control. To be agile, you need to adhere to the agile manifesto. But following the manifesto doesn't mean you are using a defiant process. The manifesto describes a set of ideas. There are various processes and project management templates that you can apply it to your projects to help them become agile. Extreme programming in scrum are two of the most popular, but lean and Cambon are also very popular. When you try to implement the manifesto items, you Germany need to apply loss of common sense and pragmatism to hope you get to your goal before to wrap a more formal process around the how of agile as opposed to the why. And you need to apprise something like scrum or extreme programming, which gives you a more formal process, like stories, alteration, standups, demos, retrospectives, test driven developments and pair programming. Next we have agile is wasteful without up from planning this extremes, your customer knows that the towers of all their requirements in advance. If this is true, then by all means undertake comprehensive up from planning. However, in reality, this is rare and usually least a greater waste of having taken designer development work that was ultimately unnecessary. Next, we have agile development is not predictable American. Within established, agile team. You can bring a level of predictability. Is your development lifecycle on business As you're directly delivering working software to your customers, the frequency of these releases will be set with your stakeholders. In an ideal situation, you should have, releasable code at the end of every sprint or iteration. Next we have agile is faster and cheaper. Running an agile team doesn't mean you'll finish your project quicker or for less money. It isn't a direct money saver in that respect, what being a trial is about. He's delivering value to the business sooner you had towards working versions of your code quicker and end of each development iteration. You're supposed to have working software to demo to the business. You may not have all the requirements in place, but what is there will work. This means rethinking how you plan your workload in each situation. Instead of delivering horizontal slices, for example, the data access layers your situation on the user interface in a neck situation, you might think in vertical segments. This means you delivered to find pieces of functionality in an inspiration that may encompass work on the user interface and a data access layer. It's a mind shift change. Are seen teams struggle with. If I used to work in horizontally when they finally get it, the efficiency of a team has increased Remarkably. Being outside is also about being able to respond to change. Requirements can vary, and businesses can change their minds part way for your delivery. I'll fight where teams you treat. This is a real negative thing. If you want to be agile, you to be expect. An embrace of things will change the tools and processes of scrum, for example, designed to help you react to these changes in a more efficient manner. So next misconception we have his agile teams. Don't write documents or do you planning. Practicing their John on your team is not an excuse to avoid planning or documentation. Writing Agile is an act of doing what is needed at the time of requiring it encourages continuous planning and documentation, but only when it is necessary for a specific customer requirement. This allows teams, along with their customers, to decide if the plan or document adds value to the product. Depending on what type of company you work for. Formal documentation may not be something that you can avoid. For example, if you work in a very density regulated environment, there's lots of upfront documentation. It may be needed for evidence, a submission to a regulatory body. If this is the case in the delivery team, we need to take this documentation into account. I prefer to work of large diagrams instead of last Documents of tax. If you can get these diagrams printed out its way free paper and then put them up all over the walls, so you have something that you can refer to in your standups. With the planning side of this, you still need to do it. How the beginning of each interational sprint. You should have a planning session. When a team self allocates stories for the alteration, the number of stories that are allocated will be based on the estimates given on the velocities for the previous iterations. The next misconception is that agile means no commitments is a common belief that people are agile. Teams do not want to make promises that you have teams of developers churning away until someone shouts, We're done. A successful our child team should be very transparent about what they intend to deliver Their uses. When using methodologies are scrum or extreme programming, you have a concept of a backlog which contains a review. Heil over users. Stories and tasks were given sprint or iteration as you to find the workload for a sprint. They should be seen as a guide to what the team intends to deliver. Once a Spencer reiteration is set up, it will not change, but it may be required that you have to change your plan partly for its print. This could result in a partial replanting of that sprints, reiteration or wait until the next prince. Extreme programming doesn't like changing a sprint once is. You fly it on. This is more acceptable and scrum, but no law says you can also the commitment if required. What is important is there is a level of trust built up between the team and the business stakeholders. Next we have an agile projects will never end. This may be true in some situations. It should continue to work on a project while the customer continues to get business value . Most products in any industry have a point of diminishing returns. This is the ideal time for a natural product and development. This decision should come from the business, though for is them that you are delivering value to agile works for projects, teams and organizations of any size, not just for small projects. This doesn't mean you're necessarily work for all teams, but size is really a factor. Large and complex projects and organisations, often excellent candidates for natural transformation, raise difficult or impossible to know all of your customers requirements in advance. Next we have agile is the solutions for your problems. Natural is a change in approach and culture that comes with its own set of benefits and issues. If you're working in a well established team, there's not been following any agile processes than changing them over will not be an instant transformation. You need to do it slowly and make sure everyone has a say in the decision making process. If you don't, you make it resistance from team members who fear change, which is a perfectly normal human characteristic. Convincing your team isn't the biggest hurdle, though. Your biggest challenge is making sure that your leadership team understands and wants to adopt. Agile as a way of working. Once you've achieved this and had leadership by in the rest of the adoption just takes time and patience is everyone adjusts. The next misconception is there is only one way to do a job. The original, agile manifesto consists of the four core values. It doesn't document any actual implementation details there. Many interpretations of agile that form different methodologies like scrum extreme programming cam ban on feature driven development, to name a few. Each style has his benefits and weaknesses, and you must evaluate your situation to decide which methodology fits your team extreme programming unscramble two of the most popular methods in use today, but also leading Cambon are very popular, too. As always, we stick to the adroll manifestos, values and principles and deliver higher value software regularly to your customers. You should be considered agile. Who finally, the last misconception we have is Adul Development doesn't require upfront design. It's a common misconception. Agile teams just make it up as they go along. This isn't true. What is more realistic is that agile teams should make sure their decisions happened at the last responsible point in time for coating activities. It's mark sets with code is designed as a developer works on it, every factors to a better design as they go along. This is what evolutionary design is all about. More system wide. An architectural design could be shattered in one or more sprints ahead of time, only designing as you need see, you can react to changes in requirements more efficiently when he tries to design the entire system up front. Any design decisions that you make a lot it to be redundant by the time you come to implement them 12. Advantages and Disadvantages of Agile: as you've seen in the past videos. Agile software development is an entirely different approach of software development compared to the more traditional water for development model. Let's take a look at some advantages of using. Agile is an approach. First, customer satisfaction by rapid continues delivery of useful software. Your clients in users will be satisfied because you're continue delivering value to them. Reusable software. This is in a stark contrast compared to that of the traditional water for product delivery process. Now, if your customers are used to waterfall, they may find it. Stranger. Justin's having working software sooner. The big downside of water for words that you deliver large patients of functionality towards the end of the project life cycle by delivering working pieces of functionality Sooner or more frequently, you're giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need up front, but they could start to make use of the solution to make their lives easier and start realizing the benefits. Sooner next we have people and interactions are emphasized rather than processes and tours . I tried his focus very heavily on people and the interactions between people rather than the processes in tours. This is a core value of the actual manifesto. The reason this is important is that this the imports from your team and customers that will ultimately make your product of success as opposed to what's always use. Continue collaboration for at the entire development cycle of your project enables everyone involved to build up a good working relationship based on trust. This trust based working relationship is crucial when building software incrementally. Next, we have continuous attention to high quality code. We're working with our job. You're working short alterations on only build what it's necessary to satisfy the requirements for its aeration, and nothing calls. This forces you to keep your design simple, which is essential as simplicity helps you develop testable and therefore more reliable systems. Developers understand and choose many solutions to solve business problems. These are choices that reflects a craft that balances design, use and support. Developers provide the technical assistance of the team that neighbors them to always keep the co quality higher. Developers like to use the latest technologies for keep their implementation straightforward and clean without having to rework any of their solutions. Some of these techniques include re factory. The factory is a process of improving the design of existing code without changing its behavior. It's made changes to the structure of the code. The fact room uses a quick succession of small, well defined steps there could be verified is safe or functional equivalents. Re factoring is often done in conjunction with test driven development. Where, Unit says, and simple design make it easier to re factor safely. The next advantage is simple design. Keeping your design simple or not Repeating code helps you keep a level of maintain ability for your system. If you design your code to be modular, then you can reduce Coplin between objects. Usually so an overall, more robust system thanks advantages. Test driven development. Test driven development is a way of improving the design of your code by writing unit tests , which expresses what you intend the codes to making that test pass and continue re factoring To keep the design process as simple as possible, test driven development can be applied at multiple levels, for example, unit and integration tests. Test driven development follows a rigorous cycle. You start by writing a test fails, then you implement that my straightforward solution don't make that test passed. Then you set for duplication in the code and remove it. It is often called red green. Red Factor has become almost a mantra for many test driven design practitioners. Understanding and internalizing this cycle is key to be able to use test driven designed to solve your problems. Thanks advantages. Embracing changes in requirements, your clients or business partners. We want to change your mind about the software that is being built. This might be because you have inspired them with new ideas from the soft wave delivered in a previous situation. It could be because the company's priorities have changed. The key thing here is you should embrace the change. Yes, code may get thrown away and sometimes last. If you're working insurance orations, this time has been minimised. Change can be terrifying at first for clients and partners alike. But when both sides prepared to leave, you can't be mutually rewarding. In some ways, at trial is a simple idea, but the reality is that it can mean different things to different people, especially depending on their role in the software development process. One of the key things, though, is to be open to change, not just to move in traditional ways of organizing projects, but so that's your use of agile itself. Next, we have early return on investments. Another advances to releasing features early is you Get out early. Return on your investments. Running a software development team is expensive. You have permanent developers and testers as well as consultants with expensive day rates. Is also business analyst project managers, as well as other hardware software costs. These are all costs the business. By releasing early in generating revenue from your product, you could start to offset some of the initial investment and development costs. On the flip side of that, if you ever more water for based approach where you end up with a big bang deployments after a year or so, you'll have already spent a significant amount of money to fund a development with nothing to show for it until the end. Next, we have feedback from your customers if you release early. This means that you can start to solicit feedback from your clients a lot sooner. His customers could be public facing customers or business sponsors. I've worked on many projects where the business customers specifies requirements, which he then build only for the customers want changes. Once I've seen something they can use, this always seems to happen. It's tough for someone to specify a system without having something to play with. You can use prototyping software to help, but there's nothing like giving them actual functionality to start using early. One of the principles of our job is to embrace change in the requirements. This should be expected to giving your customers something they can feedback on sooner let down and the opportunity to make changes without causing much disruption later. Down the line in the final advanced we have is faith back from real customers. Once you start getting feedback from your customers, you could start incorporating changes. And new ideas from the feed back into the product is much more cost effective to make changes early on in the product development cycle than it is to wait until the end. Once a large release has been achieved, its not just customer feedback that helps you build the right product protest in your products. Early in the marketplace, you engage customer uptake and see how popular products will be and continue to deliver better quality. Everything we've discussed so far has business benefits or culminates in the fact that you should be providing a better quality product of every release by releasing early insisting feedback. You can learn from the product performance early and use this information to create something of higher quality product and system development, all about continuous learning and improvements. It is much easier to do when you're delivering a products by being agile. It doesn't matter where ever. Using extreme program in scrum crystal Fish driven development Lean Cam band Really, if you have a project management frameworks, if you stick to the core values of the agile manifesto, I'm routinely to live a higher value functionality early to your customers. Monitor their usage in isn't there? Feedback can apply this learning to the on going development. Increase quality as you go along now to be taking a look at some advantages, let's look at a few disadvantages. First of all, it's hard to assess. The effort required it beginning of the software development lifecycle, one complains. I've often heard from business leaders and project managers alike is it compared to water, for? It's hard to quantify the total effort and cost to deliver a product. On one hand, I could see what I would think. This, especially they come from a regimented was full process world. Indeed, it is harder to quantify how long the total products gonna take entirely. But a mitigation for this is that a product will be delivered incrementally by giving them uses the most valuable requirements first, meaning you complain for the coming sprints or maybe a few sprints ahead to provide specific amounts of functionality. Racist advantages. It can be very demanding on the uses. Time Active user participation in collaboration with the uses of your system are required for the development cycle with agile. This can be very rewarding. Ensures you deliver the right products for your uses. It's an essential principle of agile. To make sure that the users experiences are well managed on a definition of failure is not meeting uses expectations. However, this level of participation can be very demanding on the user and require a big time commitment for the duration of that product. Have been in this situation many times where the business users love the idea of what a joke could bring them. But I don't like the extra amount of time that they have to spend on the project, as I still have to fit the same of their common workloads on the final day. Survives jeans look at is a cost can increases. Testers are required all the time instead of at the end of a project. Testing is an essential part of natural project Jordan sprints, and it's orations they service. We show quality throughout the products without the need for 11 fee and unpredictable test phase it end of your product. However, this doesn't mean that test is a needy for the entire product development life cycle, and it can dramatically increase the cost of resources from your team. This extra outfront costs does save you money in the long run, though, as you continually have people testing your code. Having a combination of manual and automated testing is the best way to drive up the quality of your products 13. Are you Prepared for Agile?: for some organizations knows to be larger and older ones. The answer to the question I prepares for change is likely to be no. The idea of implementing methodologies encourage evolution of business requirements instead of relying on outfront documentation. Empowering the project team self organized instead of controlling their daily activities on replacing means a documentation with no face to face communication may seem a bit daunting for some staff. This is particularly the case phase that I've grown comfortable with their normal dates. They routines and just live with the problems in their code on the solutions that will develop him. A great debilitation when trying agile is people saying this is the way we've always done it. These types of individuals, usually very resistant to change if you're start his hesitant at first, you may find that giving agile to try on a donor project in your team will help get them familiar and motivated by agile. If I have to try a one or two agile project, your stuff is still uncomfortable working directly with the business areas, forcing changes in requirements as the project progresses and self managing their work. It might be the agile approaches are just not suited to your organizations. Working culture. If, on the other hand, your team reacts well to trial projects than his paves, the way for you to move more fully to adopt in these methodologies going agile doesn't require a change in attitude for managers and leadership to traditionally, it might be more common to have direct control over what your team members are working on. But if agile, you need to take a different approach. Managerial styles need to be more like servant leadership, where managers are there to remove any barriers from the team's progress and encourage a team to think for themselves and organize their own workloads. After all, developers are paid very well. She need to have more realistic level of trust that they will do the right thing, not for interesting thing about the dynamic of self organizing teams. As they progress, they improve ongoing motivation for the employees Project. Team members know their continued ability self managed. Their work depends on their regular delivery of high value business outcomes, additional because they are the ones who identify what work can and cannot be achieved in the situation. They are motivated by their responsibility to reach these outcomes. This combination of factors is heightened by the situation and pride that staff members Phil when they produce tangible outputs, truly meet the needs of their organization. 14. Thank You: Thank you for watching Might cause I drive explains. And I hope he found that the information be discussing the quality is gonna be useful to you in actually understanding on a prime agile to organizations. If you enjoyed the course will be very grateful. You follow me. And also, if you could people know about the cause on Twitter whenever social media sites are absolutely fantastic on You can also leave comments here on this side. So I think very much for watching. I don't see you again soon.