Key Foundations of Agile & Scrum Project Management | Google Career Certificates

[TICKING] [MUSIC PLAYING] SUE: Hello, and welcome to Agile Project Management. So far, this program has covered the foundations of project management and what it takes to be a project manager. We've explored the phases of the project lifecycle, initiation, planning, execution, and closing. And we've reviewed lots of different tools and techniques for managing and communicating your plans. We've also discussed how to handle various challenges, risks, and issues that come up along the way. If you've completed all the courses so far, congratulations. If you're just now joining, welcome. Either way, you're on your way to a new, or maybe just improved, career in project management. Now that you have a solid foundation on what it takes to manage a project, I'm going to share with you one of the most popular approaches to delivering projects, Agile. In my opinion, Agile is also the most interesting and flexible approach to project management. Agile is not a project management methodology in and of itself but more of an overarching approach and philosophy to deliver value to customers, which is the goal of most projects. Despite not being a specific methodology, there are lots of frameworks and methods under the Agile umbrella. In this course, I'll help prepare you for a career in Agile project management. I'll provide you with a history of Agile and introduce you to a specific Agile delivery framework called Scrum. I'll teach you about the core roles that make up a Scrum team. And finally, I'll cover some best practices and real-world scenarios where you can use the Agile approach to lead your project to success. Oh, and I should probably introduce myself. My name is Sue, and I'm a senior technical program manager with Google Support Platform. We build the products you use to get user support from nearly all of Google's products. I started at Google in 2014 and worked on product reliability, making sure Google's products are up and running all the time for billions of people across the world who depend on them. Before Google, I worked at many companies of different types and sizes where I ran and worked on projects using Waterfall, Agile, and everything in between. I started my career as a software engineer working on cell phone technology. But I didn't have a degree in computer science. Since then, I've had many different roles, but program management is my passion because it brings all of the disciplines together to deliver amazing outcomes for the customers and equally amazing results for the business. I still remember the aha moment I had when I discovered Agile. And I'm excited to share it with you. I hope you're ready to discover Agile and experience your own aha moment. In the next video, we'll start learning the basics of Agile. Meet you there. [MUSIC PLAYING] To quickly review, Waterfall is a popular project management methodology that refers to the sequential or linear ordering of phases. You complete one phase at a time not proceeding to the next until it is done. Then you move down the line like a waterfall starting at the top of a mountain and traveling to the bottom. The term agile refers to being able to move quickly and easily. It also refers to flexibility and the willingness and ability to change and adapt. Projects that adopt Agile project management take an iterative approach, which means the project processes are repeated, often many times, during the lifecycle of the project. In this case, the team operates within many shorter blocks of time called iterations. Individual iterations might get repeated depending on the feedback received. During each iteration, the team takes a subset of all the project's activities and does all the work required to complete that subset of activities. You can think of it as a lot of mini Waterfalls for each activity. This iterative approach enables the project to move quickly as well as making it much more adaptive to change. So the term agile means flexibility, repetition, and openness to change. But what do we mean by Agile project management. Agile project management is an approach to project and team management based on the Agile Manifesto. The Manifesto is a collection of 4 values and 12 principles that define the mindset that all Agile teams should strive for. So in very basic terms, Waterfall is linear and sequential and does not encourage changing up the process once it is started. Agile, on the other hand, is iterative, flexible, and incorporates necessary changes throughout the process. Now, a bit of a history lesson so you can have a better sense of how and why Agile has become such a popular approach to project management. Agile methodologies emerged organically during the 1990s as the software industry was booming. Software startups like Google were blazing a trail to get more software products built in less time. Meanwhile, the tech giants of the time were experimenting with faster ways to build better software and stay competitive. And by the way, software isn't just the apps and websites that we all use every day. Software also includes the code behind innovations in agriculture, medical devices, manufacturing, and more. So in this competitive, growing environment, companies couldn't just create new innovative products. They also needed to innervate the very processes they were using to develop those new products. In 2001, the thought leaders and creators of some of these new processes, also called methodologies, came together to find common ground between their methods and solve a problem. The problem, they agreed, was that companies were so focused on planning and documenting their project that they lost sight of what really mattered, pleasing their customers. So these leaders came up with the Agile Manifesto to guide others on what they believed really matters when developing software, which is keeping the process flexible and focusing on people, both the team and the users, over the end products or deliverables. Now here's where Agile gets even more interesting. You can still use Agile even if you're not planning to work on software projects. Agile has been so successful in the software industry that its values, principles, and frameworks have been applied to nearly every industry. In fact, the Agile methods that you're going to learn also draw heavily on Lean manufacturing principles that originated in Toyota's car factories in the 1930s. You'll also find Agile methods being adopted in the aeronautical, health care, education, finance industries, and even more. Cool, right? Agile is everywhere. [MUSIC PLAYING] Agile was created in response to the strict linear process of Waterfall. While Waterfall aims for predictability and tries to avoid change, Agile embraces the reality that the world, markets, and users are uncertain and unpredictable. For example, your customer might say they want feature A. But when the final result is delivered, they realize they actually wanted feature B. Agile aims to solve that problem by getting customer feedback more quickly to make sure that the team is building what the customer really wants. Part of working with an Agile mindset is always seeking out ways to work more efficiently. We do this by finding ways to streamline processes without reducing product quality or value. The key to streamlining is to reduce waste. For example, unnecessary documentation is a form of waste. Another form of waste is spending weeks or months working on a feature only to find out that the customers, who could also be users or stakeholders, don't like the feature after all. You could reduce or eliminate both of these forms of waste by increasing team and stakeholder collaboration. More collaboration means less documentation and earlier feedback about the product. Let's consider some more differences between Waterfall and Agile. Three important aspects of a project are requirements, documentation, and deliverables. Requirements are conditions that must be met or tasks that must be finished to ensure the successful completion of the project. Think of these as the set of criteria that fall within the scope of your project or a list of specifications that must be met. In a Waterfall project, you'll probably need a product requirements document, which lists the scope and requirements of the project. You need to have several formally approved project plans, and you might have a team of people whose job it is just to write and approve these plans. You might also set up a change control board, a formal and rigorous process to manage any changes to requirements. All this is designed to protect the team from building something that the client or stakeholders don't want and aims to minimize any changes that could lead to scope creep. Formally approved project plans work well when the desired end product is known and understood. An example of this might be leading a project that has clear requirements and goals based on mandated regulation. But if that's not the case, a Waterfall team risks building out an entire deliverable only to find out later that the customer doesn't like the final result. In Agile, requirements are treated as more dynamic and expected to change as the team receives feedback and new information. There is usually an initial set of requirements or feature ideas when the project kicks off. But that list of requirements and features is continuously growing and changing throughout the project. The team works with stakeholders to prioritize the requirements, always moving the most urgent or valuable items to the top of the list. Then the team goes down the list, working on the requirements in iterations. By going down the list, the team is able to get feedback on their work quickly and frequently. At the end of each iteration, the team gets feedback and can make necessary adjustments to the requirements before continuing on. OK, the second aspect is documentation. All projects require documentation-- project plans, stakeholder maps, schedules, charters, contracts-- the list goes on and on. Waterfall projects use lots of documentation because there are lots of hand-offs between phases and hand-offs among different teams within the project. Also, because the work is done in bigger chunks, you'll need to leave behind more pieces of documentation at each stage in the project. But, in Agile, there's an emphasis on real-time, person-to-person conversations. This doesn't mean that there's zero documentation. It's just in a different form. Instead of big, formal documents with a rigorous change management and approval process, there are shorter documents that have just enough detail to achieve their purpose. These documents are much more focused on what the reader needs to get the job done and are written only as needed. Finally, let's explore deliverables. A deliverable is a tangible outcome from a project. In Waterfall projects, you often don't release the deliverable until the very end. The final product release feels like a big event, major announcement, lots of hoopla, and is often super fun and exciting. Agile is just as exciting but has smaller, more frequent releases. So each release has a less formal celebration, but it builds up to be just as exciting. When there's lots of uncertainty in a project, such as in a new, emerging industry or market, the steady release of project deliverables enables an Agile team to get feedback and learn as they go. Without regular feedback, the team could end up delivering something that the customer doesn't want. So now you have a better idea of some key elements of Agile that distinguish it from Waterfall. Three differences between these two project management approaches are the way each one deals with requirements, documentation, and deliverables. [MUSIC PLAYING] Now that you're more familiar with the history of Agile and how it's applied to project management, let's discuss the inspiration behind this Agile movement, the Agile Manifesto. In this video, I'll list the four values of Agile and describe how each Agile team needs to strike a balance between the four values. Being familiar with the Agile Manifesto will help you understand the core principles and values Agile project management so you can put them into practice on a project. The Agile Manifesto was written in 2001 and brings together the collective wisdom of the people who developed it from their vast experience and thought leadership in the tech industry. If you'd like to find the Manifesto, it's easy. Just type in Agilemanifesto.org in your search browser. We've made it available for you here in the course readings as well. Let's check it out. The Manifesto for Agile software development states, "We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more." There you have it, the Agile Manifesto and the four values of Agile. It's a short list, but it packs a punch. The Manifesto is saying that it's helpful for every Agile team to think about both sides of each statement during the execution of a project but should find ways to ensure that they're always placing more value and emphasis on the things on the left over the things on the right. From the 4 values, a set of 12 principles were developed that reinforce the message of the Manifesto. These values and principles inform the why, how, and what of Agile project management planning and processes. Let's take it from the top. First, the Manifesto emphasizes individuals and interactions over processes and tools. At its core, this value stresses people communicating with each other over using lots of processes and tools to force things to happen in a certain way. For example, have you ever emailed someone with a question and ended up in a long, back-and-forth exchange due to simple follow-up questions or clarifications? Chances are that you could have gotten the same information in less time with a brief conversation. Agile wants to ensure that teams work together, collaborate, and help each other achieve the best outcomes they can. Agile also values individual perspectives and creativity. This does not mean that every team is chaotic. The value just means that processes and tools should be used to facilitate and drive good project management and improved collaboration within the team and should never be used as a barrier to teams working well with each other. The second value emphasizes working software over comprehensive documentation, meaning that teams should prioritize spending time working on things that actually create value and avoid spending any more time than they really need on debating, writing, and reviewing documents. Now, this value might seem like it only applies to software projects. But just replace the term working software with whatever your project is trying to deliver. Maybe the project is writing a legal brief, designing an office layout, or preparing a sales presentation. Whatever your project is trying to deliver is the thing that creates value. In other words, it's more important to deliver the product the customer wants than to comprehensively document the process that you used. Onto the third value-- customer collaboration over contract negotiation. In Agile projects, the customer satisfaction is considered the highest priority of building a high-quality and valuable product. After all, if it's not valuable to the customer, then there's little point spending time on it. When the Manifesto discusses contracts, it refers to the official documents that require sign-off and formal agreement with the customer, such as those huge requirement documents or formal change requests. Agile values having the freedom to collaborate with customers early and often. In doing so, teams can quickly react and adapt to what customers need rather than waiting out the process of negotiating contract terms just to make a few changes or request resources. There will still be contracts with Agile project management. But the focus is on identifying what's really needed and leaving space for collaborative, customer-focused work. Agile teams are encouraged to seek out every opportunity to include the customer or stakeholder during project execution. This could be presenting early prototypes, asking questions, or bringing them in to do some initial product testing. And finally, we have the fourth value-- responding to change over following a plan. This last value is crucial to an Agile project. As I explained in the history overview, Agile grew out of a world that was changing so fast that organizations couldn't adapt and struggled to survive. As a result, this value stresses that every Agile team needs to acknowledge that change is inevitable. The larger, longer, and more complex your project is, the more uncertainty there is. For many projects, finalizing a well established plan at the beginning of the project will likely lead to an on-time delivery within budget but may run the risk of not meeting customer needs or adding maximum value. As a project manager, the key takeaway to remember here is that the most successful projects are the ones that are able to smoothly integrate change. Agile project managers still create and value their plans, but they can cope with and are able to adapt if the plans need revising at any time during the project. So there you have it, the four Agile values-- individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. What's great about Agile is that it gives us these values and also lets us find the right balance between the two sides. You may have to fine-tune your project style to meet industry needs, team dynamics, and organizational goals to find the healthy balance that works for you and your team. [MUSIC PLAYING] For this course, I've grouped the 12 principles into four themes. These are different from the four values. The four themes of the Agile principles are-- value delivery, or how do Agile teams deliver highly valuable products to their customers; business collaboration, or how do Agile teams collaborate with their business partners and stakeholders to create business value to the organization and their users; team culture, or how does a team create and maintain the right interpersonal and team dynamics to deliver value for the customers and the business; and retrospectives, or how does the project learn to continuously increase performance of an organization and business? As I said, I've grouped each of the 12 principles under these themes so they're easier to learn and remember. Let's dive in. The first theme is value delivery and includes five principles. Take a few seconds to review them. This theme is about delivering the work as quickly as possible. And remember why? So that we can get feedback and mitigate the risk that we spend too much time building the wrong thing. Also, no one gets any value from your work, including your company, until you deliver it. So the longer you take to deliver, the longer you wait to get revenue, and maybe the more time the competition has to get ahead of you. These may look very software-oriented, but, if you replace the word software with deliverables or solutions, these can apply to almost any project. For example, deliver working solutions frequently-- see? The value theme is also about simplicity. How much time do you think it takes engineers to add all the buttons and features to products that ultimately end up confusing the user? Simplicity allows a team to focus and work on the things that matter the most. An example of this theme in action might be prioritizing getting feedback on a product prototype so you know which features really matter. Or it might mean ensuring the team only works on approved features and doesn't spend time on unnecessary ones. Another example might be reserving 10% of the team's time to work on bug-fixing or polishing a process, which should help you go faster in future iterations. The next theme is business collaboration and includes two more principles. Quick note-- one of the principals uses the term business people to refer to those involved with things like sales, marketing, customer support, and account management. We'll use the term developers to refer to those who are involved with making and creating products. OK, so we discussed customer collaboration during the values discussion. And here we are again. Collaborating with your customers helps the team get critical business information immediately, allowing them to adjust and adapt to any new information instantly. No matter if it's realized early or late in the project, customers will get what they want to achieve their business goals. You can achieve collaboration by making sure that business people work near the development team, ideally, in the same office or virtual space. If that's not possible, maybe co-locating a day a week, encouraging instant messaging, or blocking off time on your team calendars each day or week to collaborate. The goal is to enable easy access between business people and developers. Another example might be how you handle feedback and changes in priorities. Rather than trying to keep the customer away from developers due to concerns about scope creep, create a weekly huddle where customers and business people can explore feedback and new ideas with the team. This could be a great way to discover that one really valuable feature is super easy to build. Whereas, another feature of the user's thought would be easy Is actually really hard. Our third theme is team dynamics and culture and includes four more principles. Remember, the first Agile values stresses individuals and interactions over processes and tools. Notice that the principles in this theme reflect that value. This theme emphasizes creating an effective team culture that is inclusive, supportive, and empowering. Having an effective team culture is essential to a project's success. These principles really boil down to making sure your team is motivated to do the right thing, feels trusted to do the right thing, has the resources and space to work closely together on their goals, and works at a sustainable pace. An example of emphasizing effective team culture would be to ask the team what kind of equipment they need to do their job and then giving them those tools. Another manifestation of this theme is letting teams write their own processes and templates rather than forcing them to use something from headquarters. Teams work best when they feel like their input is valued. So you, as the project manager, should make space for your team to engage and actively contribute to the team culture. You'll build trust and empower them to approach their work in a way that suits them best, which, in turn, will allow them to work more productively. Finally, the fourth theme is retrospectives and continuous learning. The last principle stands alone in this theme, so I'll read it aloud. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This one sits on its own because I want to draw attention to how important it is for Agile teams to continuously learn and adapt to what's working and what's not working for them. Teams should always be figuring out better ways to work. And it's really valuable to set this time aside after each iteration to focus entirely on how to improve. In these sessions, the team can step back and consider questions like, how is the team doing? Are the customers happy? Are there processes we could optimize? Are our tools working for us? Are we following the values? Are we accumulating any debt? And by debt, I mean processes or technology that slows us down. We've officially finished discussing the Agile Manifesto. It's amazing to think that these 4 values and 12 principles are the foundations of so many advances in project management. I'll come back to these values and principles throughout the rest of this course to demonstrate how these connect to the day-to-day activities of an Agile project. [MUSIC PLAYING] Every project exists within organizations and settings with different cultures, business objectives, and industry dynamics. In this video, we'll discuss some different scenarios in which you'd want to adopt an Agile mindset. I'll also introduce you to a concept called VUCA that can help you decide which management approach is best for your project. Remember, Agile is about delivering value in a world with high degrees of uncertainty, risk, and competition. It sets a team up to react as quickly as possible to new information, new market opportunities, and even new technologies. Agile works best in industries or projects that are susceptible to or that encourage change and uncertainty. What kinds of businesses or industries besides software come to mind that deal with lots of change? A few that I think of are biotechnology, with emerging vaccines, treatments and technologies; media, with endless new ways to share content; the food industry, with celebrity chefs and the latest food craze; and fashion, an industry built on keeping up with shifting trends. Did any of these surprise you? On the flip-side, here are some industries that you might think of as fairly stable-- agriculture, aerospace, manufacturing, and mining. But even these industries with rigorous supply chains and codes have to adapt to change due to new laws and regulations, natural disasters, and other unforeseen issues. One thing that the year 2020 taught all of us is that no industry is truly immune to change and uncertainty. We're going to explore a concept for categorizing and thinking about these forces that shape our world no matter what industry we're in. That concept is called VUCA. And it can help you decide which project management approach is best for you. The US Military War College developed a concept called VUCA, spelled V-U-C-A. VUCA is an acronym that defines the conditions that affect organizations in a changing and complex world. It was designed to help us factor in the forces of change and uncertainty in our projects and businesses. VUCA stands for Volatility, Uncertainty, Complexity, and Ambiguity. I'll explain each one and what that could entail in projects and business settings. First up is volatility. Volatility refers to the rate of change and churn in a business or situation. In a volatile project, you would discuss how the next disruption to your operations is always right around the corner. Or it feels like things never have time to settle into a normal rhythm. Next is uncertainty. Uncertainty refers to the lack of predictability or high potential for surprise. In an uncertain environment, it would be difficult to create plans for the future that were not based on a large number of assumptions that could turn out to be incorrect. Then there's complexity. Complexity refers to the high number of interrelated forces, issues, organizations, and factors that would influence the project. For example, if one product being worked on relied on diverse and global suppliers, that would add to the complexity of the project. And finally, we have ambiguity. Ambiguity refers to the possibility of misunderstanding the conditions and root causes of events or circumstances. A project that suffered from ambiguity would have difficulty pinpointing the causes of project delays, making it difficult to design mitigation plans to reduce the risks. Let's recap. VUCA stands for volatility, uncertainty, complexity, and ambiguity. It's a concept that was developed to deal with these forces in a changing and uncertain world. Businesses can apply the concept of VUCA as a tool for determining how best to approach projects. Phew, that's a lot of info, but it's all good stuff. Having an understanding of these concepts will help with decision-making in all kinds of projects. Adopting an Agile approach increases your chances of success despite this uncertainty. And these concepts apply to the business world at large, not just projects. [MUSIC PLAYING] Now let's discuss why it's important to understand VUCA as it relates to project management. When we get started on a new project, it's helpful to examine the environment and conditions in which the project exists before we decide the best approach to use. If your project environment has high levels of volatility, uncertainty, complexity, and ambiguity, then it's a good sign that you should consider an Agile approach. While an Agile approach is not a perfect solution that will get rid of VUCA, it will lead to better outcomes by giving you and your team tools and systems to mitigate the risks that VUCA presents. When you consider Agile values and principles, it's clear that Agile is a proven and well-documented solution to the challenges VUCA presents to your project. OK, let's revisit the Office Green scenario we introduced earlier in the program. We'll use this scenario throughout this course as well to illustrate the power of an Agile approach to project management. If you're just joining us now, I'll give you a quick recap. In previous courses, learners acted as the lead project manager at Office Green, LLC, a commercial landscaping company focused on interior plant design for offices, restaurants, and hotels. For this Agile course, we'll come back to Office Green as they pursue a new business opportunity. The Office Green market research team noticed a major shift to more workers setting up and working from a home office. They wanted to react fast to a potentially huge market opportunity and not lose revenue if businesses had less need for their previous office service. Instead of offering indoor landscaping designs for businesses, Office Green wants to find a way to capture this new market full of home offices. I don't know about you all, but I have a hard time keeping plants alive. I can't keep a cactus alive. But I love all those video conference backgrounds that are so nicely decorated with beautiful, live plants. This shift to working from home came about suddenly, so Office Green didn't have any project plans to start from. They didn't have time to do a lot of prep work, but they wanted to maximize this opportunity before it was too late. To do this, Office Green assigned you to be the project manager of a scrappy new Agile team. Your goal is to deliver their new service called Virtual Verde. What environment did Office Green face? Volatility, uncertainty, complexity, and ambiguity. They experienced volatility in the form of a major disruptive change to their business plans; uncertainty through a lack of predictability, which made it difficult to create concrete plans for the future; a high level of complexity due to interrelated factors like suppliers and the economy; and they experienced ambiguity by not being able to determine or control what might cause future changes. By using an Agile approach to their project, Office Green was able to address high VUCA factors that were affecting their business. Instead of business slowly or quickly eroding due to market forces, Office Green embraced the changing market and remained flexible in how they approached their next project. We'll follow along with Office Green and your work as a project manager at Virtual Verde throughout this course and find out how you do. [MUSIC PLAYING] 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-boxed 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 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 three to nine 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. [MUSIC PLAYING] 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 finished 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 we'll 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 coat 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. OK, 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 workstream. 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 in 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 out 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. [MUSIC PLAYING] 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 common on 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 Plant Pals 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 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 adds 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. SPEAKER: Congratulations. [AUDIO OUT] --our channel to learn more from Google Career Certificates. [MUSIC PLAYING] SUE: In this video, we'll explore the results of a project and the end product you'll ultimately deliver which is what holds value for the user and the customer. I'm going to define the term "value" as it relates to project management. Then I'll share some strategies and tactics you can employ to maximize the value your team delivers. The end product of a project is what provides value to the user. Value could be financial benefits, user growth and engagement, or compliance adherence. The term "value" can mean different things for each customer based on what they expect the product to accomplish. The number one Agile principle is to satisfy the customer by delivering valuable software. You can always replace the term "software" with the words "product" or "solution" for non-software-related projects. Delivering value as quickly and efficiently as possible to users is the primary reason Agile came into existence. The term "value-driven delivery" means you and your team are focused on delivering a product of high value. Just because you deliver a product, that doesn't mean it's valuable. As I explained during the overview of Agile history, there was a growing problem of project teams churning out products that weren't very valuable. This is because teams were focused on the process and weren't taking the time to evaluate the usefulness of the product until the very end after it had been delivered. Agile redirects the team's focus to be about the product and ensures that the process for producing the product supports the goal of delivering value. How can you make sure your team is focused on value-driven delivery? Build the right thing, build the thing right, and run it right. Remember, Agile and Scrum evolved out of the software industry, so the terms "build" and "run" describe processes for building or running a software program, machine, or other technology. You can replace the words "build and run" with terms like "create," "produce," or "deliver" for non-software projects to describe the same concept. Let's break this down. First and foremost, to deliver value, you have to build the right thing. You can do this by making sure you really understand what your customers want. You might ask a customer what they want, and they may say they want to build a website to promote their new plant service. But take this one step further and ask about their goals. Do they want to increase their brand recognition? Do they want to get more customers? Having a solution-oriented conversation with your customer will help you build the right thing. The Agile value of individuals and interactions over processes and tools extends beyond just the team. It refers to having those important interactions with our customers and users too. Next, you must build the thing right. That's lingo for ensuring that your team only builds the requested or approved features. Working on features that aren't necessary can lead to complexities in the product that don't add any value to the users. In addition, building more than you need delays a reduces your value upon delivery. It also increases the risk of bugs or other issues down the road. And finally, in addition to building the right thing and building the thing right, you have to make sure that you're running it right. To run it right means that your team has thought through how the user will interact with the product once it's been delivered. Make sure your team thinks through some of the operational tasks that will need to be addressed after the product has left the door. Ask the following questions. How do users get support? How does the product add value to users long after they initially received it? And how do you make sure that new features and capabilities reach the existing users? Building the right thing, building the thing right, and running it right all work together to ensure that the team creates a steady and continuous delivery of value to users throughout the life of the product. Let's consider how the Virtual Verde team can ensure that they focus on value-driven delivery. First, how could the Virtual Verde team ensure they build the right thing? How do they know they're creating something the customer really wants? In this case, the team needs to ensure that they create a service providing the types of plants that customers want to buy. So they could create a survey that asks current and potential customers what their plant preferences are and the type of home office design they want to create. Then they'll use this data to update the user stories on their product backlog. Next, how could the Virtual Verde team ensure they build the thing right? Once the team knows what kinds of plants and designs the customer wants, how do they ensure the right processes are in place to deliver them? Well, the team can secure a trusted plant vendor that carries the desired plant types and work with designers to make pots, vases, and other plant accessories in the different design styles that customers like. The team can also communicate with marketing to make sure the types of plants and designs that customers want are prominently featured on the website and in the catalog. And finally, how can the Virtual Verde team make sure to run it right? How do they ensure customer satisfaction once a customer has signed up for the service? How does the Virtual Verde team retain their customers long after their plants have been delivered? The Virtual Verde team can send out follow-up customer satisfaction surveys that ask about their plant and design offerings, delivery times, plant quality, and other insights. The team can then use this data to continually evaluate their vendors, plant and design offerings, and marketing strategy. For example, the team could find ways to increase the quality of service by offering watering cans and automatic plant health systems or even free, monthly gardening tips so the user feels empowered and supported to maintain their plants. There are many ways to maximize your team's value delivery. Building the right thing, building the thing right and running it right all work together to ensure that the team delivers value to users. [MUSIC PLAYING] As a project manager, part of your job is to help teams stay focused on delivering value. A great way to do this is to build a value roadmap. It's an Agile way of mapping out the timelines and requirements for the product development process and can be used in all types of businesses. This roadmap is a guide that demonstrates where to go, how to get there, and what to accomplish along the way in order to maximize value. It helps map out a product idea and the strategy for how to deliver it. As the team follows their roadmap, they gather input from customers and stakeholders and apply their findings to each iteration of the product. Creating a roadmap helps the team explain the vision of the product and can also be used to identify important milestones. A typical value roadmap has three components-- a product vision, a product roadmap, and release plans. The first component of a value roadmap is the product vision. Your product vision is a critical step to starting any new Scrum project. Your vision is based on your user interviews and market analysis and becomes your team's North Star. In other words, it's what guides your team. The product vision defines what the product is, how it supports the customer's business strategy, and who will use it. Next there's the product roadmap, which the product owner is responsible for creating and maintaining. It provides a high-level view of the expected product, its requirements, and an estimated schedule for reaching milestones. It's key to making sure your team is building the right thing. The third component of a value roadmap is a series of release plans. The product owner and project manager work together to develop these plans. Product releases occur when the team has developed a basic working version of a given feature or requirement. A release plan includes the approximate date when the team is expected to release and deliver certain features to the customer or user. An Agile team may have several releases over the course of a project until their project is considered done. For this reason, only the first release date should be considered to be set in stone. The rest of the release plan is based on early estimates and is subject to change as the project proceeds. A release plan contains a release goal, which is an overall business goal for the features you plan to include in the release, the list of backlog items, such as epics, user stories, or features that you require for that release goal, an estimated release date, and any other relevant dates that impact a release, like a convention or major holiday. It's important to add all of your release plans to your value roadmap to help you stay focused on the path to your overall value goal. In summary, the value roadmap contains three key components-- the product vision, product roadmap, and release plan. These three work together to help an Agile team reach its goals through multiple iterations. A value roadmap only works if the team is collaborative and all stakeholders work together regularly. This will ensure that the project achieves results that align with the Agile values and principles. [MUSIC PLAYING] My first tip is about creating the product roadmap. The product roadmap provides a high-level view of the expected product, its requirements, and an estimated timeline for reaching milestones. Many of those milestones will be product release dates. You'll need to ensure that product release dates are only rough estimates. This is because, as an Agile team, you know that things can and do change. This is especially true since these dates could be anywhere from several months to several years down the road. If the roadmap is too specific, it might set the team up for failure because the dates can't be guaranteed. Speaking of product release dates, this leads me to my next tip, which is about the release plans. There are some important things to know about creating a release plan which includes approximate target release dates. It's very important that the Product Owner and project manager or Scrum Master work together to develop each release plan. This is because the release plans need to connect the product roadmap with the team's capacity and velocity. The capacity and velocity is the measure of the team's ability to complete work at a certain pace. A release plan that isn't connected to the team's ability to complete work could be unrealistic and lead to an unsustainable pace for the team. This would violate one of our Agile principles, which states, "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." If there are any hard dates or deadlines on your roadmap, meaning a date that cannot change, factor these into any release plans that might be affected. For example, Virtual Verde might realize that Office Green has an office decor convention in October. And they want to launch the first phase of Virtual Verde services at that event. Communicate hard deadlines with your stakeholders so there's a clear understanding of must-have features. This way, if the team discovers it might be at risk for not meeting the deadlines, they can quickly focus on the must-have features. Since Agile is all about embracing and anticipating change, it might seem like having a release plan goes against the Agile value of responding to change over following a plan. But having a release plan does not mean you are resistant to change. An Agile team treats a release plan as a living artifact. So the plan can change based on the environment and new information that's received. Some common factors that may result in a change to the release plan could include a change in team velocity or how much work the team can do in a given iteration or sprint. This could be from adding or losing team members or even just efficiency gains from how they work. A second factor is a change to the product scope, if the product owner approves the change to the product. And a third factor that could affect a release plan is improving the understanding of how much effort is needed to build certain features. The team may discover that a user story or epic is more or less difficult than they originally thought, after doing some research or simply from better understanding the product space. My last tip for creating an effective value roadmap is that the Scrum Master or project manager should always review the release plan before starting a sprint-planning session. They review the release plan to check whether the team is on track. If the team is off track, the Scrum Master needs to have an open conversation with the Product Owner and business people to figure out what they can adjust to get back on track. This is where the Scrum value of transparency is key. An effective value roadmap is a powerful tool for building and delivering successful products. The plans you create will help you stay focused on delivering maximum value and the ability to remain flexible and stay Agile. [MUSIC PLAYING] As you conduct your project management job search, you're likely to find many of the organizations you apply to as either already being Agile, making the switch to becoming Agile, or not yet Agile but ready to transition. As an entry-level project manager, it's not likely you'll be expected to lead a complete change to Agile in a large organization. But you may be expected to help support the change process. On the other hand, you might get hired by a smaller organization that does want you to lead the change. The techniques I'll share with you in this video will set you up to be prepared for all of these different scenarios. Let's begin. First, let's review some of the key learnings from one of the earlier courses on organizational culture and change management. When an organization shifts the way it conducts business, it usually requires a shift in its culture as well. Understanding organizational culture and the change management process is crucial when introducing new ways of working. Organizational culture is based on shared workplace values and pops up in people's behaviors, activities, the way they communicate, and how they work with each other. A change that's out of sync with the existing culture is much more difficult to complete. In fact, there's research proving that companies that don't consider the cultural aspects of Agile are more likely to fail. Change management is the process of getting folks to adopt a new product, process, or, in Agile's case, a new value system. OK, let's get into how to help introduce or continue the adoption of Agile or Scrum into an organization. Unless the organization has many years of Agile behaviors and experience, you may be facing a change in organizational culture. These changes take time, sometimes years to complete. As a project manager, you might only implement a few changes, and that's OK. You'll still be adding value by demonstrating to your team or organization new and different ways of approaching their business. I'll share with you some words of wisdom I heard from a colleague many years ago. They said, "Change takes patient persistence." It may feel like things are taking too long. But in many cases, small changes add up to a big change in the long run. So what are some ways that you can bring Agile or Scrum to a new team? First, I want you to think about the concept of creating a sense of ownership and urgency. When people feel a sense of ownership and urgency around a project, it increases interest, motivation, and engagement with the project outcome. One way to create a sense of ownership is to find an executive sponsor who also feels a sense of ownership for the change you're creating. Wherever possible, point out connections between the changes you're making and the company's stated mission or values. Having buy-in from someone at the top increases your chances of successfully driving any change in organizational culture. Ideally, your sponsor will reinforce the benefits of Agile to the organization and give you the support and resources you need. What about creating a sense of urgency? My favorite approach to this is to ask the team, the organization, and the stakeholders questions about what's working and what's not working right now. Then I ensure the changes relate directly to those opportunities. Here are some questions you could try. What is preventing us from providing the best possible product to our customers? What is allowing our competitors to outperform us in this market? And how can we help our teams become more productive and supported in their work? This not only helps you prioritize your work. You get the team thinking about the possibilities they'll enjoy if the change is successful. You can use these questions going forward to collect feedback during the change. Coming back to these questions and demonstrating the incremental improvements is the true spirit of Agile. Let's come back to our friends at Virtual Verde. When the team set out to create this Agile project and change towards an Agile approach, they realized that the CEO of Office Green wanted to make sure they took advantage of the market trends since more people were moving to home offices. They created a sense of urgency by highlighting that home office decorating was becoming a hot online trend, and they wanted Office Green to become a part of the action. Lastly, the Virtual Verde team had lots of experience from their Plant Pals project, so they could gather a team who was motivated to apply what they learned and try a different approach to a new market opportunity. Bringing Agile or Scrum to a new team could be challenging but well worth the effort. By applying some of these techniques, you'll increase your chances of success. I found that, with a little patient persistence, you can get past some of the initial skepticism. And the benefits of an Agile approach will start to become obvious to the team. Once this happens, change will become easier to drive over time with their commitments. I once had a large global team at Google of about 200 developers. My director and I wanted to transform them into an Agile organization. It took us about two years and many trips to different work sites for me and my team of project managers to deliver the tools, processes, and coaching to bring the team up to speed on an Agile way of working. I approached that transformation very much like how I described here, and it worked. [MUSIC PLAYING] As the project manager or Scrum Master, you're in the position to help the team improve. In other words, you're the designated Agile coach. You're there to help the team recognize areas for improvement and help them implement solutions. In this video, I'm going to break down your role as a coach into three steps similar to how you might approach being a coach for a sports team. First, you'll design the plays with the team. Second, you'll provide feedback to the team. And lastly, you'll celebrate and learn with the team. Let me elaborate on each area bit more. First, the Scrum Master designs the plays. Although the Scrum Master owns the playbook, it should be created with the whole team. The playbook should include how the whole team runs a sprint review, how the team works day to day, and how the team publishes plans to stakeholders. When updates are needed to the team's plays, it's important that you involve the team in any decisions. Take them through new processes together. Think through all the positions on the team, and make sure everyone notices the flow. A personal example of this was when I facilitated a brainstorm meeting with my team to discuss which parts of our process weren't working. We used sticky notes to organize our ideas for improvement and then prioritized the ideas to implement changes. Second is provide feedback. You should always provide feedback to your team and stakeholders as early as possible and on a day-to-day basis. Just like a coach gives directions from the sidelines, the Scrum Master needs to provide guidance all the time. In addition to feedback provided in the moment, the Scrum Master also takes in a big-picture view. This is similar to how a coach might watch a video recap of the game to find patterns that need improvement or plays that worked so well they should do it every game. Providing feedback shouldn't only be about fixing broken things but finding processes and activities that work really well and encourage the team to continue using the things that work. Third, celebrate and learn. Congratulate the team often on a job well done, a happy customer, or a big solution launch. If the team, quote unquote, "loses," meaning they weren't successful in fulfilling a requirement, acknowledge that loss as critical data that will help the team improve next time. It's important for the team to still feel positive about any disappointment and think of it as a learning opportunity. As Thomas Edison famously said, "I have not failed. I've just found 10,000 ways that won't work." As a Scrum Master or Agile project manager, you play an essential role in the team and you're a big part of why Scrum and Agile work at all. You're responsible for ensuring the team is always improving and becoming the best team it can possibly be. Awesome. Now you know the three steps of coaching your team-- designing the plays with the team, providing feedback to the team, and celebrating and learning with the team. Next up, we'll learn how to anticipate and respond to real-world risks with Agile and Scrum implementations. Meet you there. [MUSIC PLAYING] As the project manager or Scrum Master, it's your responsibility to help teams improve how they work and coach them on how to effectively adopt Scrum practices. So anticipating and understanding how to work through common challenges before they happen is super important. Remember the four themes of Agile principles that we discussed in an earlier video? To refresh your memory, the themes are-- value delivery, business collaboration, team dynamics and culture, and retrospectives. In this video, we'll focus on challenges you might encounter with an Agile team that are related to the first three themes. The first set of challenges are related to value delivery, which is about making sure the team is delivering working solutions frequently. Some signs that your team is experiencing value delivery issues could include things like-- the team has started missing expected delivery dates and is taking a lot longer than usual to complete tasks. Or you might notice that the team seemed burned out, is working long hours, and showing signs of exhaustion. Or maybe the team has too many items in progress at any given time, preventing tasks from actually getting to done. If you start to notice your team is struggling in these areas, there are a few things you can do to help. You can try doing more demos of the solutions with the team to ensure they're delivering on the value roadmap. When the team pauses to take in a big-picture view of the working product, they often notice areas where they can improve and speed up the work. You can also use retrospectives to ask the team if anything is slowing them down, like waiting on dependencies or communication challenges. It can also help to do a quick review with the team and make sure that everyone understands what done means. And finally, be sure to focus on only a few user stories per sprint. This ensures the team finishes an item together before moving on. Putting all this into practice can be harder than you might think. My current team is asked to cover a lot of ground in each sprint. So it can be tempting for us to try and tackle too much at once, but doing that usually just makes everything take longer. So it's not actually helpful. It's better to maintain focus and deliver fewer backlog items in one sprint than to deliver a lot of items in more sprints. OK, another set of challenges you might encounter relate to the business collaboration theme. To recap, business collaboration is about making sure the developers are collaborating with business people on how to build the right product. There are a few common signs that your team might be experiencing business collaboration issues. You might notice that the team is overwhelmed with critical feedback or change requests from business people after they reviewed the working solution. That could lead to people on your team avoiding asking for feedback or complaining about requested changes coming from the product owner or business team. Or you might start to detect an us-versus-them mentality between the team doing the work and management. I've sometimes noticed this manifest in negative comments from team members, like, oh, don't give a demo to the salesperson; it's not ready yet. And they'll just point out what's wrong. If you notice any of these signs, there are a few things you can do to help rebuild trust and collaboration between the developers and the business people. To start with, try addressing critical feedback and change requests by doing more demos. This ensures feedback comes in at a steady pace and that everyone involved has a shared understanding of what done means. Next, consider conducting a solution-designed sprint, which is an entire sprint spent working solely on the solution design. These are most effective when the working team and the business people actually sit together and collaborate on the solution. Finally, you can help your team focus by ensuring changes to the backlog are introduced only in between sprints. This prevents your team from getting distracted by possible changes, which could stress them out and lead to resentment. For example, I was once on a Scrum team where the engineering director loved to stop by the engineer's desk to ask for a quick dashboard, which is a web page that shows data. Asking the engineer to do this completely disrupted the team's focus and slowed down the team's velocity. We finally decided to ask the director to come straight to the Scrum Master when they needed something so that it could be planned properly and not interrupt the team's current workflow. OK, let's move on to the third theme, team dynamics and culture. Human beings are complex creatures with lots of different motivations and styles of working. So it's likely that you'll encounter at least a few challenges in this area. Here are a few common signs of team dynamics and culture issues to watch out for. First is low team morale. If people are super grumpy, irritated, or generally in a bad mood, then you might have some underlying team dynamics issues to sort out. Next, watch out for signs the team is experiencing lots of conflict. If people are arguing a lot and issues aren't getting resolved, the team probably needs some help. Not everyone is going to get their way. If team members feel resentful or are holding on to grudges, it'll negatively impact the team's performance. And finally-- and this might surprise you-- but low conflict can also be a sign that the team's experiencing issues. We're usually taught to believe that no conflict is a good thing, right? But if a team never has disagreements, it's a sign that they might be worried about starting a conflict because they don't feel like it's a safe environment. Being open and courageous are two of our Scrum values, but it's not always easy to put them into practice. As a project manager, part of your role is helping your team get comfortable being honest with each other and working through conflicts together. If you notice these or any other clear signs of team distress, here are some ideas you can try. You could run a team brainstorm session about how to work better together. Ask the team to identify some areas to improve on. An example exercise could involve asking the team to write down stories about the worst team they've ever worked on and the best team they've ever worked on, then sharing them in a meeting. Then you might have the team create a list of dos and don'ts for working together based on the stories everyone shared. Another idea is to change up the workflows. Try pairing up people to work together on a hard task or change up the way you run one of your regular meetings. It can also help to take a training class together or watch a video about team dynamics and discuss it as a group. You can also try a retrospective technique from the internet. There are a ton of great resources out there. One of my favorite retrospective techniques is called the six hats thinking technique. In this technique, each team member chooses a different hat to explore the subject of the retrospective. The different hats each involve a different objective, like discussing positives or negatives that happen during the sprint or sharing emotive statements. This helps ensure that the team takes a well-rounded approach to the retrospective. [MUSIC PLAYING] The three challenges we'll focus on are managing a stable product roadmap, incomplete implementation of Scrum, and experiencing a lack of stability within the team. First, let's discuss the challenge of managing a stable product roadmap. Agile projects almost always experience changes in the product roadmap. Being able to respond quickly and productively to these changes is a core Agile value. But it is possible to have too much change impacting the project, which can lead to an unstable product roadmap. There are two main causes of an unstable product roadmap, product ambition and product assumptions. Let's cover product ambition first. Product ambition poses a challenge when product leadership is overly ambitious about what the team can realistically deliver. The product owner is responsible for representing the project to customers and executives. Because the product owner wants to make the stakeholders happy, it can be easy for them to overpromise what the project can deliver. For example, imagine that our Office Green CEO notices that the Virtual Verde business in North America is doing really well. In a meeting, they say to the product owner, this is amazing. I'd love to launch Virtual Verde in Asia in the next four months. What do you think? The Product Owner really wants to deliver. So they tell the CEO, sure. But the product owner won't actually know if meeting this objective is possible until they discuss it with the team, which means they might accidentally be setting an unrealistic expectation with the CEO. So how do you deal with this challenge? Here are three ideas to maintain a healthy roadmap management plan between you and the product owner. First, agree up front how to handle new opportunities. Define when they are reviewed and estimated and how customer or management commitments are made. Second, set up regular roadmap reviews with the entire team, at least quarterly, so that everyone knows what to expect. And third, promote sharing knowledge between the product owner and the development team so that the product owner knows how much effort the product takes to build, and the team is aware of changes as early as possible. The second thing that can cause an unstable product roadmap is making too many product assumptions. When there's uncertainty in a project, you be required to make some assumptions to move things forward. But making too many assumptions can jeopardize the team's success. Let's go back to our Virtual Verde example. Sending plants to customers' homes is a complex process. You need to consider a lot of different factors, like which plants will sell best, which plants will stay healthy in a wide variety of climates and settings, and what vendors to work with. The team does their best to study the market in opportunity, but they have to make some assumptions and move forward with decisions relying on less-than-perfect information. As a way to deal with product assumption issues, document the assumptions and make them transparent. This allows you to discuss the assumptions as a team and either agree that they're safe assumptions to make or decide to question and double-check them. If you do decide to double-check them, you can use unbiased user research. Unbiased user research gathers information about what users really want. It allows you to confirm or reject assumptions and helps you move forward with confidence. User research could involve conducting surveys, running focus groups, or using other methods to collect objective data about your users. The next big challenge might encounter relates to an incomplete implementation of Scrum. This happens when Scrum practices are only partially implemented or when Scrum practices are implemented without proper support and coaching. Scrum roles, artifacts, and activities are designed to work together as a set. If you only partially implement them, you might end up reducing their benefits. Incomplete implementation of Scrum can cause a lot of issues. First, it can lead to a loss of clear roles and responsibilities. To implement Scrum completely, you should define the roles for the team and then fill those roles with specific individuals. For example, if you try to have a developer also act as the Scrum Master, they might not have the bandwidth to do either role very well. Better to have developers be on the Development Team and you, the project manager, be the Scrum Master. You might also be tempted to skip some events or blend them to save time. But a lack of clear boundaries for sprint review, sprint retrospective, and sprint planning can lead to reduced transparency, inspection, and adaptation. And these are all essential to experience the full benefits of Scrum. And finally, not providing the team with the Scrum coaching they need would also mean that you haven't fulfilled your role as Scrum Master. It's your job to fully explain the Scrum practices and provide coaching so your team understands the reasoning behind the practices and can embrace their benefits. The solution to all of these challenges is to implement Scrum completely. Being the Scrum Master is a critical role. You're the coach, so you should reinforce the connections between the team's activities and the Scrum and Agile values. For example, if your team complains about daily standups, remind them that the purpose of standups is to gain feedback, unblock work, ask for help, and reinforce the importance of staying focused on the sprint goals. You can also make sure roles are well defined and properly fulfilled. For example, ensure that all team members understand their own roles as well as the roles of their teammates and how those roles interact. For example, the Product Owner makes sure we build the right thing. The Development Team ensures we build it right. And Scrum Master ensures we build it fast. And finally, the last big challenge might encounter with Agile and Scrum teams is a lack of team stability. When the team changes a lot, with people leaving and joining frequently, it can make things unpredictable and disrupt the flow of work. There are a few things you can do to address instability on your team. First, have a quick onboarding process for new team members to help them get to know the rest of the team and understand the project. Second, use a pair programming style where a new team member teams up with a colleague and starts learning on-the-job. This also helps if people leave the team, since a partner should be able to pick up where they left off. And third, if team composition changes because members keep leaving, try having shorter sprints. This way, team members can wrap up their last sprint's worth of work before leaving. To recap, the three main challenges we've covered in this video are managing a stable product roadmap, incomplete implementation of Scrum, and a lack of team stability. I've encountered each of these challenges and more in many of my teams. The wonderful thing about Agile is that there's a huge community of Agilists that are happy to help with any challenges you might come across. Even an experienced Agilist like myself asks for help now and then. Coming up, we'll explore how Agile is evolving and keeping up with the times. Now, that's an Agile way to be. [MUSIC PLAYING] Since its creation in 2001, Agile popularity has increased incredibly fast. One industry report showed that 85% of organizations have adopted a product-centric model which is associated with an Agile approach. The State of Agile Report describes how 30% of those companies using the product-centric model apply a hybrid of methodologies. This means that being able to blend methods will be a super useful skill to have as you start your project management career. Like we explained in an earlier video, one of the reasons for Agile's growing popularity is that we're in a very VUCA world. Businesses face a lot of volatility, uncertainty, complexity, and ambiguity. And they recognize that Agile and the frameworks that derive from it are a way to overcome those challenges. In this video, we'll discuss how Agile has already started evolving and explore some emerging ideas about how it might continue to evolve in the future. The Agile Manifesto as a mindset or philosophy hasn't changed much in almost 30 years. The frameworks it inspired, though, have continued changing and evolving to keep up with changing business environments. One emerging Agile framework is called DevOps, which combines software Development and IT Operations. Our Google Cloud Platform business defines DevOps as an organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders. Like all Agile frameworks, DevOps aims to shorten the product lifecycle and deliver software products continuously and with very high quality. DevOps emerged when software companies were faced with trying to figure out how to ensure their software products would run reliably for billions of people across the world, 24 hours a day, seven days a week. As someone who spent my first few years at Google studying product breakdowns, I can tell you how difficult this is. If a business has the ability to launch products and features fast and reliably to a global marketplace, that's a significant competitive advantage. DevOps is about growing and managing teams and organizations that can build and evolve large-scale systems at a rapid pace. These systems need to be both secure and reliable so they can better deliver value to customers and organizations. If you decide to pursue a project manager role in the DevOps framework, you'll venture into the future of Agile approaches and large-scale software systems that are literally changing the world. Pretty exciting, right? One of the next frontiers of Agile is called business agility, which involves incorporating Agile principles into the wide sphere of management so that the organization can thrive in high-VUCA environments. Organizations that want to become Agile in this sense often find themselves rethinking everything, from financial planning processes, governance and reporting structures, to hiring an HR practices, and much more. They're looking for ways to make Agile values and frameworks work for larger and larger organizations. As an Agile project manager in a larger organization, you might find yourself using frameworks like Scrum of Scrums or Scaled Agile Framework also known as SAFe. Check out the resources and readings for this video to learn more. It's also important to call out that Agile has reached a lot of industries beyond technology and software. Recently, I was asked to give Agile training to the Google sales team in Latin America. They experienced major changes in their market and wanted to develop the skills to react quickly to those changes and still deliver results. During the training, we had great discussions about the benefits of Agile. The team especially liked how Agile can help reduce risk at all stages of their sales cycle, through early feedback and frequent and thorough discussions with teammates and customers. Even the construction industry has started applying an Agile approach to their projects. An article published by the Project Management Institute describes how construction projects used Agile to deal with delays and budget overruns by translating the Agile Manifesto into construction industry terms, like silos are minimized and close cooperation is encouraged. And finally, Agile methodologies can also be applied to your own personal life. For example, I was planning a move recently and immediately set up a Kanban board to start planning my tasks. Have any projects in your life that could use a Kanban board? How about a garage cleanup or a family reunion or barbecue? Who's on your Scrum team? From DevOps and business agility to Agile methodologies in the construction industry and beyond, it's clear that Agile's benefits will be useful for a long time to come. The practitioners, project managers, and teams who live and breathe the Agile values are the ones that help Agile evolve and advance, which means that you can play an important role in contributing to the future of Agile too. Coming up, we'll explore how to approach your job search so you can find an opportunity in Agile project management. Meet you there. [MUSIC PLAYING] We just covered the evolution of Agile. And I shared how other organizations are adopting Agile practices. We also discussed the best mindset for delivering value to users as quickly as possible. Agile project management opportunities are everywhere. Whether you're looking for a new role in Agile or want to incorporate Agile into your current lifestyle or workplace, I have a few tips to help get you there. Let's start by discussing how to land an Agile project management position. These types of jobs might show up on job boards as Agile project manager, Scrum Master, IT Agile project manager, or a DevOps project manager. After taking this course, you'll be a great fit for any one of these. Look for a role that suits your experience level, complements your industry domain expertise, and offers growth opportunities. Also, look for a role that provides a culture that would be a good fit for you. And I can't emphasize enough how important it is to find an employer who supports your goals and personal growth. I'm a hiring manager at Google. I've interviewed and hired many project managers here, both Agile and non-Agile. And I'd like to share how I approach interviewing and searching for an excellent Agile project manager for my team. Even if a candidate doesn't have Agile on their resume, one of the first things I ask them is, what's the difference between Agile and Waterfall project management? Their answer usually tells me instantly if they know what Agile is about. And it's a great launching-off point for more follow-up questions. In the candidate's answer to that question, I look for a few specific things. I want to know whether the candidate knows that Agile is more than just Scrum, sprints, and standups. Do they know it's also about founding values that include customer collaboration, value delivery, self-organizing teams? I'm also interested to know whether they make Waterfall out to be the worst solution, or do they know that all projects benefit from certain types of approaches, including Waterfall, like clear requirements, risk management, stakeholder awareness, and more? I also ask, how do you know when to use an Agile approach or frameworks on your project? Their answer helps me know if they understand how Agile or Scrum can help a project manager with specific challenges and what those challenges are. And finally, I ask, if you are facing resistance with your team following a Scrum or Agile practice, how do you convince them to give it a try? Their answer helps me understand how they use communication and influence skills and whether they truly believe that an Agile team can be self-organizing. At Google, our teams sometimes resist being told what to do, especially because this can diminish innovation and creativity. So I always want to hire project managers who work with the team and don't try to force them to do things a particular way. An important part of every interview is when the candidate gets to ask the interviewers questions. These could be questions about the job, about the interviewer's experience in project management, about the culture, and about the job expectations. This is a huge opportunity for you, as the candidate. As an Agile project manager, you now know how crucial culture is to the success of an Agile project. This is a great time to ask questions that will help you determine if you'll be happy with this job or not. Some questions you should ask, are, how supportive is the management here towards blending project management approaches? What's the first thing I should know about the culture here? And how often will I get to hear about the needs of our users or customers? And what would a typical day look like for me if I were to take on this position? Maybe you're not interviewing for a new role, but you want to bring what you learned in this Agile course back to your team. How would you go about that? As we discussed, bringing Agile or Scrum to a new team is often challenging if their culture doesn't support it. Here are four things that helped me bring Agile to my teams. First, start small. You may be excited by everything you've learned here. But your team might light things how they are. So introduce Agile practices in bite-sized pieces. Maybe start by using a Kanban board just to keep track of one workstream. Or set up a retrospective after a major milestone. Second, listen to feedback. The most powerful tool a project manager has is the ability to listen to their team and meet them where they are. When you introduce changes, ask the team how it's going. Get their ideas on how to make it better, and include them in your approach. This will amplify your small changes into big results for the team. Third, be strategic. Target your improvements to challenges your team has today. Introduce new ways of working that address, head-on, the biggest issues your team's experiencing. For example, maybe your team has trouble estimating effort predictably and always ends up in crunch mode. Maybe relative estimation techniques would help with that. Or maybe you have too many people chiming in on what the product should be. Introducing a single person who acts as the Product Owner to help ensure consistency in prioritizing features. Lastly, find allies. You may have setbacks or need to lean on supporters to bring these ideas back to your team. Find Agile allies in your organization or network. These allies will give you advice when things get rough and help you stick to Agile values and principles. We built up a network of about 60 volunteer Agile coaches here at Google. And we're always leaning on each other for ideas and solutions. SPEAKER: Congratulations on finishing this video in the Google--

Channel: Google Career Certificates

Views: 51,007

Keywords: business intelligence, dashboarding & reporting, visualizations, business analysis, communication, project management, business process, data analysis, agile, Agile project management, project life cycle, career certificate, career certification, google certification, certification, career certificates, google career certificates, certificates, google careers, certificate, careers, career searching, job searching, job search, career courses, career course, scrum, agile scrum

Id: WDAQq5vCMME

Length: 98min 50sec (5930 seconds)

Published: Tue May 30 2023