Agile Fundamentals for the Workplace: Agile Project Management and Agile Delivery Essentials

1. Promo video Agile Crash Course: Hey, guys, in these agile crash course, I'm gonna teach you everything you need to know about agile project management, agile delivery and agile in general. So think of this course as agile for dummies or agile for anyone and agile for everyone. I'm a discourse, a crash course. So I kept it purposely on deliberately short, simple and very valuable. So all the information that you're gonna learning the scores will help you in your agile projects and anywhere where you need to work with the agile methodology. You learn everything you need to know about it from the basic concepts, terms, tools, tips. And I'll even provide you with templates and links so you can continue to practice your agile skills on further develop your agile knowledge. But beyond that, I'll even share with you pre adult courses so that you can continue to enhance your knowledge about agile product management and agile delivery. Man is more issue, and I'm a senior project manager and also a serial entrepreneur. I'm also the founder off the agile Knowledge Base or agile kb dot com, and they created the scores after traveling the world and doing agile training in different countries. And with that in mind, I said myself to create a course that would actually help people in the world not only understand what agile is and help our abilities and how they can use it in the projects, in any industry, across any region and in any country, but also that it would actually get a certificate for completion of the course. I would become agile, certified so that they could actually put it on their CV and start applying for roles in which agile was a requirement or right. Guys, I hope you enjoy it. And I'm sure you're gonna learn a lot of indie scores. See you on the next one by 2. Intro and The Definition of Agile: welcome to the actual crash course he scores will cover the most important concepts and tools off agile development and agile project management. But I should note that Agile is not on Lee for the I T industry, nor just for developers or project managers. Actually, anyone can apply agile across different industries in almost any project. But I'll go over which projects are better suited for agile later in the course. For now, let's just go over the basics. So let's start by answering what is probably the most important question in this course. What is agile? You probably heard the term a couple of times, and we're wondering what it meant, how it was different to what you were already doing on whether it was actually good or not . Well, I have good news for you. If you are able to understand the pictures you are seeing on your screen right now, then you're already going through the learning process of understanding what audio means, because it's pretty much what you're seeing there seriously. It's just that simple. The summarizes what agile is, and what it means is a methodology for delivering projects, and I wanted to give you an analogy because I know it will help you understand it better. So let's start with the left side. At the top, you have the process or traditional project delivery. As you can see, we start to build the whole car. Right. The Ferrari, the best product that has everything, all the requirements and all the bells and whistles. And we don't consider a project done on to reach that stage, so the actual delivery can take many months on, sometimes even years on. The customer might not be happy along the way, since he's just waiting and waiting to get something. But agile is quite different. Look at the pig below that. Do you see it? Agile is an interrogative process in which you deliver value through a basic solution and then enhance it. Over time, you deliver quickly, and you deliver often on throughout the whole process. You have constant communication and interaction with a customer to ensure he's happy with every product you give him. He can actually start using even your first iteration, the skateboard, to go from point A to B. Sure, it would be nice to have a car, but isn't escape or better than nothing. Isn't it better to have a skateboard while you built the car? That is precisely what agile does. So let's put this into a real Web development example. Say you were building a website to sell products from different categories, flavors and colors. In agile, you wouldn't spend months building that website. Instead, you would create a basic first generation may be just the home base, should get started and to get the concept out there, and then you would enhance it over time and start adding to it. Maura and more pages to the website Mawr on more product features over time. In Agile, we call the Pier of Time sprints and springs less generally two weeks. Now let's shift our attention to the right. Do you see the sofa? The analogy also explains a key concept in Nigel. Keep it simple. Build the minimum. You really need to deliver what the customer expects. And that relates to another key concept in Agile, which we call the M V P or a minimum viable product. So what's the minimum you can deliver? Which satisfies the basic requirement. So, like the tire with rope? So let's recap about the concept of agile, agile is a methodology to deliver incrementally. It's interrogative on time boxed, and that period of time, which is generally two weeks, is what we call sprints. And what you work on during those two weeks, which are basically features that value to the customer, are what we call user stories. But don't worry about the terms. You're learning them over time, and I'll go over these in more detail later in the course. For now, I just want you to start getting familiar with the concepts and terminology we're using agile, such a sprints and user stories. And if you ever hear the war iteration and get confused, don't be iteration is just another word for Sprint, which, as you just learned, is disappear of time to do something generally two weeks. But some things, even three or four. That is something for the project team to decide 3. How is Agile Different?: So how is agile, different to other methodologies or ways of doing things well, it's different in many ways. For example, in traditional project delivery, you would start off with an analysis space, which would take a couple of weeks or a couple of months. Then you would move to a design and spend again a couple of weeks or months, and then you would actually develop or code. After the process, you would pass it on to the Q. A team for testing on you would move to production at the end after testing so traditionally in a lot of product management and project livery methodologies, you wouldn't move on from one place to the other until that faces being completed until milestones and deliverables. Having met and signed off, you would also ensure that scope doesn't change and keep. That has constrained. It's possible, since various cope would actually translate in the product they can even longer than originally planned. And finally, in traditional development, you would work in the final solution from the very beginning de Ferrari, the long term vision, the product with all the bells and whistles. But you wouldn't do any of these in agile in agile you would actually test from the very beginning, not just at the end. You would also plan and analyze every two weeks or every time you finish your sprint, and you would deliver it charitably often and quickly. You would also embrace changes in scope when reasonable and required. Since you're working interrogative lee and building products along the way, you are able to provide more flexibility to your end, user and customer and involve them in the development process. From the beginning. This is one of the most important advantages of agile and a reason why so many business owner stakeholders and customers love it. They have direct input in the development process, and they do it from the beginning, and they do it often, not just at the end. Another thing that makes agile different is that agile focuses more on the actual work than on documentation. Now, please don't misinterpret this and leave this course with the misconception that Agile doesn't involve documentation. Agile also requires documentation by documentation is not the main focus. It's got short and simple, says the team needs to focus more on the work than on paper. In agile rose blur on. By that, I mean that, for example, everyone in the team can be involved in testing not just the people that would normally do it, because that's their official role tester or test lead. So, since in agile your testing and planning every step of the way, well, mostly members getting both that doesn't mean that Aaron has to test or their agile dictate that it doesn't. Some adult projects still use the official roles for team assignments in tax, and that's fine. The point you need to understand is that agile can allow for Rose to blur and overlap or complement one another. And that's okay. People embrace these in agile and support each other to ensure the team's success. Now, in terms of planning, will planning is adaptive and agile. I'm priorities can change for its sprint, depending on where the team defines and finally in agile requirements can change, and the team is open to those changes. That doesn't mean that agile dictates that that you should change requirements is just means that the team considers something no longer a priority. Well, it could be the sculpt, for example, say you're working on that e commerce website and after spring to you show damage the product owner, which is your customer or a person who represent him or hair. And that person now says that they no longer want to have a product displayed vertically but now horizontally in traditional project delivery, you might say, Well, you signed off on vertical at the beginning, and now it's too late to make a change. But in Agile, you would say to your customer, Sure, by the end of the next point, we will have another demo on show you the changes. The improvement divan scope is varying. You might negotiate with a part owner about some of the user stories off the next print on , moved into the next one, or maybe remove them so that you can actually deliver and meet their expectations. See the difference. That's agile. And that is why people love it. It's powerful 4. Agile Principles and a Little Bit of History about Agile: What you see on your screen is what we refer to us. Agile principles. No, I'm not going to go over each and every one of them because I know you can read, and I'll also create an article about them. But let's go over some of the key ones. Let's reflect on number three. This relates to the concept of sprints on delivering quickly and often in agile you delivering weeks, not in months or years. If you're taking many months to live or something, you are not doing agile. If you're taking years to deliver something you are not doing agile. These audio principal has to do with the speed of delivery, which, in the agile terminology we called the team's velocity. I will explain that concept later, but keep it in mind. The speed of execution is called Velocity in Agile on. Let's now reflect on number 10. Do you remember the example of building a skateboard to get from Point A to B instead of building a Ferrari? Simplicity is one of the most important, agile principles on one of the reasons why an agile you can deliver so quickly you build basic and simple solutions which satisfy the main and most important requirements. You build a skateboard instead of a car you then iterating and iterating on. Over time you build the Ferrari over time, not a one goal or from the beginning. Over time you build up as you go, and you enhance improve on release in has improved and release. People prefer getting improvements quickly, even if they are minor but valuable than waiting a whole year to get something done. Think about the mobile app in your smart phone. Have you noticed the automatically update frequently and that sometimes the improvements are minor but cool. That is agile. See, you have been surrounded by agile for a long time. You just didn't know it. But now you do. At the end of this course, you will be familiar with agile concepts and tools. So a lot of people think agile is new and that it's mainly for writing projects. And for developers and project managers, well, that is a huge misconception about agile, and nothing could be further from the truth. In reality, agile dates back to the fifties, but the real game changer was the release of the agile manifesto in 2001. I won't go over the manifesto in detail, but I'll add a link to the resource is so you can read about it. The manifesto is basically the essence off, agile. Think about it as the Bible off, agile And yes, it came out of the I T industry on from a group of developers. But no agile is not on Lee for developers and project managers. And it's not only for I T projects, Joe is actually applied to all industries and too many types of projects. I have personally applied agile to commercial projects, operations, projects and even personal projects. And I can tell you that agile works and it works well. Try it yourself and learn from the process. Reflect for improvement, which in agile we would call a retrospective that is basically the process of reflecting on your mistakes and how you can improve and do things differently. I'll talk more about that later, but for now, retrospectives is just another agile term 5. Agile FAQs: So let's go over. Some of the typical on frequently asked questions about agile. I've been doing agile for many years now, and I've worked with agile across many industries, many projects and different organizations. I've also worked with different teams, different team sizes and different applications, right? So let's look about some of those common questions that I get all the time because people ask me these questions, and I know you might have some of those questions. I thought maybe we should just go over them, right? So one of those questions is is agile Onley for developers and Onley for project managers. And the answer to that question is, no ideal isn't on Lee for developers, nor just for project managers. There's people using agile across very different industries and across very different projects, people in very different roles, working with agile. So you have, you know, testers. You have business analysts. You have architects. You have, you know, people working in financing Hey char in sales and operations and procurement in marketing. So pretty much anyone comply, agile to their projects as long as they understand how it works and how to apply. Now I'm not gonna say agile. It's suited for every type of project, because that's a different question, but actually certainly suited for the vast majority of projects. So if you want to do something that you want to deliver quickly, deliver often on, you want to work collaboratively that you're probably suited for agile. If you're an organizatio