Speaker 1: Welcome back. So far, we've explored a little bit of Agile history, the Agile manifesto, and some of the types of projects that benefit from an Agile approach. Up next, I'll introduce you to some specific methodologies under the Agile umbrella. The most popular of these by far is Scrum. In this video, I'll briefly recount the origins of Scrum and discuss the basics of Scrum methodology. So what the heck is Scrum? Well, I'll tell you first that it's not an acronym. If any of you have ever played or watched the sport of rugby, you may recognize the term. For those that aren't familiar with rugby, it's similar to American football, a full contact sport played on a field with a similar shaped ball. Scrum refers to a formation in rugby where all of the players on the team lean forward, lock their heads together, and then work as one unit to try and gain precious yards towards the scoring line. The originators of the Scrum methodology saw their team as a heads down group working very closely together to get that ball down the field, just like Scrum in a rugby match. So how does the Scrum methodology work as a project management methodology? I'll give you a brief overview here, and we'll dive into it more throughout this course. If you work in Agile project management, it's highly likely that you'll use Scrum or an approach that is based on Scrum. In the 2019 State of Agile report, 72% of teams using Agile methods were using Scrum or a hybrid. When you use Scrum for project management, you form a team that will work together to quickly develop and test a deliverable. The work is completed in short cycles, and the team meets daily to discuss current tasks and clear up anything that's blocking their progress. First, let's review some terms and concepts specific to Scrum. The backlog is the central artifact in Scrum, where all possible ideas, deliverables, features, or tasks are captured for the team to work on. It's prioritized and proactively managed by the team continuously throughout the life of the project. The sprint is the name of the time box period in Scrum where work is done. The sprint can be between one and four weeks long, but most sprints are around two weeks. This is often called the iteration. And then there's a practice called the daily Scrum, also called the standup. This is where the team meets for 15 minutes or less every day of the sprint to inspect their progress toward their goal. Next are the roles, the first of which is the Scrum Master. This role is responsible for ensuring that the team lives Agile values and principles, follows the processes and practices that the team agreed to, sharing information to the larger project team, and they also help the team focus on doing their best work. The other notable role in Scrum is the Product Owner, who is responsible for maximizing the value of the product and the work of the team. The Product Owner owns the inventory of work and has the final say on how to prioritize the work. And the Development Team is responsible for how a team will deliver that product. Scrum is popular for many reasons. First, it has clear roles and responsibilities for the folks on the team, while continuously emphasizing the power of the team as a whole. Scrum has a very regular and predictable meeting and delivery schedule, with predefined agendas and outcomes for the meetings, making it easy to teach new team members. It supports and reinforces the Agile values and principles, while adding some structure and foundations that help new Agile teams get started, and more experienced teams get better. And, it's all free and open for all to use. Since it's the most commonly used Agile delivery framework, there's also a huge amount of guidance and support online as well as Scrum-specific training and certifications. Scrum lends itself best to the following types of projects and teams. Ideally, a Scrum team should be cross-functional, with around 3 to 9 team members. Some call this a pizza-sized team, because it has the same amount of people who could share a large pizza. If the team is too small, you might not have the diversity of skills to get work done. If the team is too large, it gets hard to distribute information. Lastly, Scrum works best for projects where the team and management are open-minded, adaptable, and value continuously learning how to be a better team. Trying to force a team to do Scrum will almost always fail. Note that in all of these examples, I never once mentioned the word software. Although Scrum emerged from software projects, people have adapted Scrum to suit all kinds of projects, from wedding planning, to house moves, to building rockets. Great, you now know some of the key characteristics of Scrum and which types of projects can really benefit from it. It's an exciting method, and while we have much more to discuss before you can fully implement Scrum, we'll first discuss a few other popular Agile methodologies. Learning about these approaches will help you become a well-rounded, versatile member of any project team. So what are you waiting for? Meet me in the next video. Hi again. There are many popular Agile methodologies that are still around from the 90s, when Agile was invented. These methodologies share Agile values and principles, but have very specific practices and applications. In this video, I'll touch on a few of the most popular ones besides Scrum, which we covered in the last video. First, one of my personal favorites is Kanban. This is a methodology that can be applied in a very simple way, or it can be used to drive the entire project. The Kanban name comes from two Japanese words, kan meaning sign and ban meaning board. You may have already used a Kanban board because it's the most famous feature adopted by the majority of Agile enthusiasts. The reason Kanban is so popular is that it provides transparent visual feedback to everyone who might be interested about the status of work in progress. Kanban boards, or charts, display the progress of a project as to-do, in-progress, and done. Also, just so you know, there are software tools that create digital Kanban boards for you. The Kanban method ensures that the project team only accepts a sustainable amount of in-progress work. This means the amount of in-progress tasks are limited to what the team can actually handle during a certain amount of time. This is called the work-in-progress limit, or WIP limit. The WIP limit is decided on by the team. This is a reflection of Agile, in that teams are both self-organizing and empowered, and they're operating at a sustainable pace. The team members add new tasks to be completed only after they finish their previous task and are below the WIP limit. This approach means that once a task has started to be worked on, it becomes a priority for the whole team to get it to done. By focusing on less work, the work gets done faster. This goal of trying to maximize efficiency is called flow, and is a core principle of Kanban. Another Agile methodology is Extreme Programming, or XP. It was named that because it took traditional software development activities to an extreme level, but I also believe it's because it emerged at the same time as extreme sports, like snowboarding. XP is another one of my personal favorites. It was the first Agile methodology I was introduced to back in my days working on some of the original cell phones at Qualcomm, the company behind the radio technology we all use in our phones today. Since XP came out of the software industry, it refers to specific software terms and activities, like coding and programming. But the XP method can be used in lots of non-software environments as well. The XP methodology aims to improve product quality and the ability to respond to changing customer needs. It does this by taking best practices for the development process to extreme levels. For example, one best practice is the idea of test-first development. This means testing out parts of the product before building them in full. Often, only the larger features get tested, which is still good, but means some details might get missed. XP takes this practice to the extreme by finding ways to test more and smaller features of the product to get even more feedback. There are four basic activities that are performed during the product development process that the XP method tries to enhance. Designing. In software development, this is where you write a design document describing the parts of the code or instructions for the product and how it will function. In non-software environments, this would be describing the various pieces and parts for whatever it is you're trying to deliver. For example, if you're delivering an ad campaign, maybe the main pieces are the artwork, the copy, and the ad buy plan. XP wants to ensure that all of the pieces of the product will fit together properly, so it stresses simplicity. Start with a simple design to meet the most basic and important requirements. Simple designs also take less time to complete. Once the basic model is designed and has been tested, then you can think about adding on other features. Coding. Code is the language that's used to write software programs. It's the instructions that tell the computer what to do. In software development, writing clear code is crucial, just like clear writing is crucial in any situation where you want to be understood. XP demands clear and concise code so that others can easily read and understand the program. This makes it easier to troubleshoot problems and come up with solutions. In non-software environments, code would be similar to writing clear and concise processes or instructions for how to build or use your product. Testing. Like I described earlier, means checking the product for flaws so they don't end up in the final product. In XP, more is better, so if a little bit of testing can eliminate a few flaws, lots of testing will eliminate even more. The goal is to test for and eliminate any flaws in a feature before building it and continuing on. Testing also means checking to make sure the product features meet the customer's requirements, which leads us to listening, which is about listening to the customer and ensuring that the requirements are integrated into the product. This relates to Agile in the way that it values customer collaboration, frequent communication, and regular feedback. XP features some other innovative practices that are used across many Agile teams, regardless of the specific methodology being used. First, there's pair programming, which is when two team members work together at the same time on one task. Usually, this is done in the same physical location, but with the use of digital collaboration tools, this can happen remotely too. Another practice is continuous integration and continuous refactoring. This is the practice of merging product changes into a shared version several times a day in order to get quick feedback on the quality of the code or product. Then there's avoid big design up front. This relates to designing and means the design should be just enough to get started and should be continuously improved as the product evolves. And finally, there's write tests, not requirements. This means that instead of writing a product requirements document and then later writing a test plan, your test plan can serve two purposes by A, telling the team what to build, and B, comparing what they built to what was supposed to be built. Okay, so we've got Scrum, Kanban, and XP. Let's explore one more. For those of you who took the earlier courses in this program, you already learned a little bit about this final methodology called Lean in the context of Lean Six Sigma. Lean methodology consists of five principles that serve as a recipe for improving project outcomes. They are define value, map value stream, create flow, establish pull, and pursue perfection. Let's break these down. Define value means identifying and focusing on what the customer wants and including the customer in the process. A product's value is the sum of all the things the customer wants. Map value stream means mapping out the process or stream, including all the steps involved in producing value for the customer. It also means challenging any steps that can be considered wasteful or unnecessary. Create flow means ensuring the product flows through the value stream efficiently, continuing to eliminate waste throughout the cycle. Work to remove interruptions, delays, and barriers to the work stream. Establish pull. Think of asking someone to pull something off the shelf. You want to make sure the customer is pulling on the product or asking for it throughout the value stream. They might pull or ask for features and incremental deliveries. The idea is to make your process as smooth as possible so that the customer can pull on the product at any time and you'll be able to present what you've been working on or add a feature request. Finally, there's pursue perfection. This means pushing your team to continuously improve the first four process steps. So how does this relate to Agile? Well, Agile emerged after Lean, and the inventors of Agile were inspired to apply Lean manufacturing principles to software development. Like Agile, Lean is a set of principles and a value system. Many of the differences are really just in the wording. Awesome. Now we know more about some other methodologies that are considered Agile. There are several more, but the reality is that many teams evolve and blend methods to create the tools and processes that work best for them. We'll discuss more about how to do this blending in the next video. Hello. In the last video, we reviewed a few of the more popular methods for applying Agile values and principles to your projects. We explored Kanban, which focuses on visualization and managing flow. XP, which is concerned with taking product development best practices to an extreme degree. And Lean, which actually predates Agile and aims to capture core principles that eliminate waste and deliver value to customers. We've also compared Agile to Waterfall to form a better understanding of what each approach values or tries to accomplish and what kinds of projects they work best with. Throughout these videos, we've explored Agile project management in a couple of different ways. First, we explored Agile as a way of thinking about the project delivery process through the values and principles outlined in the Agile manifesto. Second, we explored Agile through different project delivery frameworks and methods like Kanban, XP, and Lean, and especially through Scrum. These two ways of applying Agile demonstrate that the real power of Agile comes from not only adopting certain processes or strategies, but also from adopting a certain kind of mindset, one that is necessarily different from the traditional Waterfall models. This means that you can still get some benefits from thinking in an Agile way and seek to apply those Agile values and principles from the Agile manifesto, even when you need to use a Waterfall delivery approach. So, with all this Agile stuff bubbling around your heads, let's do a quick recap on some of the key tenets of traditional Waterfall project management. Then, we'll explore some of the ways you can blend the methods and approaches you've just learned about to best fit the needs of a specific project. As we learned in earlier courses, a Waterfall project lifecycle is made up of the following phases. Initiation, planning, executing and completing tasks, and closing out the project. And all of the tasks within each of these phases, like identifying goals and scope, scheduling, budgeting, and risk management. Agile project management includes most of the same phases and tasks, they're just done in different ways. So, even though these two approaches have clear differences, blending them might make a lot of sense, depending on the type of project or project team you're working with. Here are some reasons you might want to blend Agile and Waterfall styles. Your stakeholders, customers, or sponsors are more comfortable with traditional approaches and using workflows, or delivering traditional work products is easier for them to understand and follow. But, your project team is already established in Scrum, and they wish to continue. Maybe there are regulatory requirements that insist on certain traditional work processes, such as large requirement documents for certifications. Or, it could be that one of the vendors involved in a large project is already following a traditional approach, and the integration between the teams requires some blending of methods. In these cases, a project manager might choose to blend aspects of Waterfall and Agile, so that different parts of the project can be worked on in ways that meet project requirements, but don't negatively impact other parts of the project, or the project as a whole. Let's explore some more examples of how to blend methods. Let's say your project is to develop a software product. During the retrospective for the last sprint, a team member says, I need to implement a certain feature, but I don't have much experience building that particular feature. Someone else on the team is an expert on that feature, so you decide to pair them up so they can work on building the feature together during the next sprint. You've just blended XP and Scrum. XP provides the basis for working in pairs from pair programming, and retrospectives are a key component of Scrum. Here's another incredibly common example. Most Scrum teams I know use a Kanban board to track their progress through their sprint. One word of warning though, watch out for too much change in how you do things. Teams work best when they can build up some consistency. Let's come back to Office Green. As project manager of Virtual Verde, what types of methods might you want to use to get the project started? Where would you blend some traditional methods and Agile methods? Here are some factors to consider. The existing plant suppliers are used to dealing with the original PlantPel's office delivery team. Some of them might be interested in experimenting with an Agile approach, but not all. In this case, you'll want to include those vendors in discussions early on to gain buy-in and address any concerns. Office Green also needs to really watch their costs, so you'll want to use traditional budget management controls to make sure they don't go over budget on their program. Well, that brings us to the end of this video. Let's review the key points I want you to take with you. First, Agile is a mindset, a way of thinking about the project delivery process through the values and principles outlined in the Agile manifesto. Second, Agile values and principles can be achieved through certain frameworks and delivery methods like Scrum, Kanban, XP, and Lean. And finally, Agile and Waterfall are both effective ways of approaching project management that add specific value. There are times when blending these styles will add even more value than sticking with just one, so don't be afraid to mix things up. As long as different parts of the project can benefit from certain processes without negatively impacting the project as a whole, go for it. Coming up, I'll teach you all about Scrum teams and how to use Scrum as a framework for running a successful project. It's going to be fun to take you on this journey.