Overview of Agile and Scrum, working with the Scrum methodology. This module will provide an overview of the Agile Family of methodologies. We will define Agile and Scrum. We will introduce you to the basic concepts of agile as part and parcel to that, we will look at the Agile Manifesto. Elsewhere, we compared waterfall and methodologies. Now we'll compare waterfall and agile. We'll consider several myths about Agile, things that people know but are actually false. Adopting agile requires organizational change and we'll take a look at some of those challenges. There are defined roles that people play in Agile, and we'll look at some of them. Finally, we'll look at the general benefits we expect to get from adopting Agile. Scrum is an agile methodology. A Scrum team has certain roles. Scrum master, who runs the show in terms of applying the methodology. Product owner, who owns and is responsible for the product under consideration. Team members, who are other members of the Scrum Team. Tech leads, were people who are technical leads on a part of the technology and other stakeholders. We will revisit these roles in more detail in a later lesson. Key to this methodology or meetings, we will go into further detail on them in the organizing a sprint lesson. For now, we'll identify these three types of meetings. A project planning meeting, the daily scrum meeting, and a retrospective meeting. The same organizing a sprint lesson we'll also identify agile artifacts. For now, some of the artifacts are a product backlog, a sprint backlog, user-stories and burndown charts. From user stories come what we need to do. Backlogs are part of what we use to organize desks. Burndown charts tell us about how we're doing in terms of completing desks. There are two readings on this topic, a simple one now and a more elaborate one going with the organizing a sprint presentation. Agile, scrum. What are we studying? Well, Agile is a broad term referring to a family of methodologies, all of which are considered Agile. These methodologies include scrum, lean, test-driven development, extreme programming, and pair programming. In fact, we often combine them. We will discuss scrum in this module. We've already discussed in the curriculum, test-driven development. Pairs programming can be crucial. It means literally programming in pairs, yielding a number of benefits, such as another set of eyes to spot bugs, a partner to bounce ideas off as we work, and a reduction in dependency on any one person, then there's always a spare from the air. Enterprise scale software development has been challenging and will remain so. In my 40 plus years of experience, I've seen projects succeed and projects fail. I've managed projects, participated on projects, and been witness to many more. I could recount projects that when massively over time and over budget. If I could summarize failure in one phrase, it might be confusing, deliverable with being done. Waterfall projects with too much time spent up front on functional specifications that were turned over to development deems that didn't fully understand them, would then spend many months working to implement them, only to find out that something had been missed or that market conditions and changed. By the time they were done, it was years after they'd gotten started. How can we make software development easier? High-level languages in IDES help. But we had all of those on waterfall projects. We even had object-oriented programming, but they still used a waterfall methodology. What we really need to reconsider is our methodology, not just our tools. Tools, especially object oriented programming, raise the level of discourse, increase reuse, increased code flexibility. But those things by themselves are demonstrably not enough. We need methodologies and tools to support the methodology that help make user needs clearer and more understandable. Do this directly by increasing collaboration with end users as part of the development process, not during some business analysis with the end-user in January and delivering a so-called finished product the following year. They should be considered active members of the product team. The right methodology with supporting tools helps us identify requirements, design solutions, managed the project, and ensure quality. This is why we turn to Agile, which helps us to build stronger, more cohesive and focused deems better allocate our resources and improved project planning. Agile is one family of methodologies that can make software development less difficult, but it requires a mental shift from the older waterfall way of doing things. Agile looks at risk, project schedule, how much effort various activities will take? How complex things are? How we can have a continuous cycle of improvement and more. In our next video, we'll look at briefly defining what Agile is.
