A Refresher on AGILE Basics

Speaker A: Welcome back, my friends, to the process domain for the PMP exam. This is our, uh, fast track and we're getting into the world of Agile now. So when you hear the word agile, my question to you is, what does it mean when someone says Agile? See, in my mind, when someone says Agile, Agile is up here. It's in the brain first and foremost. See, agile is all about what is in your mind. So I often say Agile is a mindset that enables you pivot. To the ever changing world around you. So all around you you got change, right? And agile is a mindset that enables you act. It starts off with a mindset and it translates into actions. So it enables you pivot to the ever changing world around you so that you can get to a desired outcome. Okay, because I know the skeptics are going to say, well, it's not just the mindset, you got to act. I agree, you got to act. But it starts off here, because if you don't have the right agile philosophies, you are not going to be agile. So agile is a mindset that enables you pivot to the ever changing world around you. What are the origins of Agile, someone might ask. Well, agile has been around for a very long time and you see Agile all throughout the hallmarks of time, even before we branded it as Agile. You see, Agile is all about pivoting. Mike Tyson said, everyone has a plan until they're punched in the face. And Mike was right. Everyone has a plan until they need to be agile, until they need to pivot. So what I want you to take away is the philosophies that I espoused in the Agile Manifesto. Okay? So the Agile Manifesto was put together by 17 individuals who said, enough is enough. We developed software following that big old process and we get to the end. And by the time you get to the end, the goalpost is moved. It's now obsolete. By the time you get to the end, technology has changed, the things have evolved. We got to be more agile in our approach. So the 17 anarchists who had said enough is enough, they got together at the Snowbird Resort in Utah. And when they got together, they were able to come out with what we know today as the Agile Manifesto. If you go to agilemanifesto.org you can check out the Agile Manifesto, but I want to give you the four values that make up the overarching thought. Like when I say mindset, you got to understand the values. What we value in the world of Agile and in the world of Agile, we value certain Things over others. Now let me ask you this. Which one would you rather I gave you if you were in the Arizona desert? This or this? Water. Liquid or food? And I know what you're going to say. Those of you who want to be smart, you're going to argue that it's this. But for those of you who are realists, you're going to know that it's this one. Why? Because you can last longer with this than this. This is good. Everyone loves food. I mean, this is lean. This is not the unhealthy stuff. Right? Although I know that the fitness aficionados, uh, are going to say, it's not pure beef, let's leave that alone. You get the idea. Food or water? Water. So when you value water over food, are you saying that you don't like food? Are you saying food is useless? No, it's not. But we value water over food. You get the idea. So the Agile Manifesto says we the 17 individuals, but we can now include ourselves in it because we're aspiring to be more agile, right? We are uncovering new ways, better ways of developing product by doing it and helping others do it. You see? So let's go over to the Agile Manifesto page for a quick second because there's a, um, misnomer about this one right here. I want us to go there together. So if you go to the page, the very first page where you meet the, uh, values, we are uncovering better ways. There's always a better mousetrap until you find it and then there's a better one, right? We're uncovering better ways of developing it says software. But I want to correct this. In the world today, everyone and their grandma is using Agile as a mindset. They understand agility. So in 2001 it started off with software, but it has evolved into the world of product. I have some of my clients, they're into construction, oil and gas and they are pivoting to Agile. So we can say we're m uncovering better ways of developing products. We can even say deliverables, product, service, result, right? By doing it and helping others do it. Through this work we have come to value. So when you take a look at their values, you begin to see the individuals and the interactions. So I want to give you some things to think about. Think about these things. We got people to people interaction going on, Right? Just think about that. Individuals and interactions. This is what we value. Number one, individuals and interactions over processes and tools. Number two, we value having a working product, Working product over comprehensive documentation. So Imagine documents and documents and documents and documents that are not necessarily useful on the project. We value this over this. We're not saying this is bad, but we're putting a value on working product over tons and tons and tons and tons and tons of documents. And then at the end of the day, you, you don't have a working product. What good is that? You get the idea. We value this over this. We value individuals and interactions over processes and tools. Right? Again, we could have binders and binders and binders, reams and reams of paper, of do's and don'ts, and these are okay. But if we don't get this right, this is no good. Right? Working products over comprehensive documentation. Again, I'm not saying comprehensive documentation is not bad, but the documents are useless if the product isn't working. And this is really referring to the redundancy in a lot of heavy documentation in the world that exists outside of Agile. A lot of times we're not honest to just tailor it and say, hey, wait a minute, why are we using this document? Do we really need it? A lot of times we just got to be brutally honest and we just got to be lean and mean. We got to cut out the fat. In the world of Six Sigma, we call it Muda. Cut out the Muda. Too much Muda. Too much waste overhead. We spent 10 hours on these documents and we now have a product that doesn't work versus we have a product that works and then we have documentation that is value. You get, get what I'm saying? It's a mindset. Good. All right, so individuals and interactions over processes and tools, working product over comprehensive documentation. The next one is customer collaboration and customer collaboration. What I think about here is that good old. You're working with your customer. Right? And teamwork makes the dream work. Right? Teamwork makes the dream work. This is where. We're on the same wavelength. See that? We're thinking about the same end goal. Success. We want to succeed. Customer collaboration versus contract negotiation. Right, contract. And don't get me wrong, there's nothing wrong in negotiation. I do it all the time. But when you're negotiating, what good is it if you don't go in there with a mindset to work with the customer? You got to go in with a mindset of collaboration and then it makes everything align. So customer collaboration over contract negotiation. And the last one is responding to change. Over following a plan. Following a plan is good. Up to a certain extent. Everyone has a plan, as Tyson says, until you're punched in the mouth. It's a very appropriate quote because when you think about COVID a lot of people had plans and the moment Covid happened, their plans went out a window. That firm that wanted to build a 10 story structure, what happened when Covid hit, rapidly changed their plan, they went from oh, we got to build a new 10 story structure to you best stay at home and work. You see how rapidly plans change. So the Agile Manifesto starts off with the values, the mindedness. The mindedness. That's why I said it's a mindset that enables you pivot to the ever changing world around you. Now when you have these philosophies valuing people over processes and tools, valuing a working product over big old documentation that doesn't even make sense on the project and even if it did, you still value a, ah, working product. I'll give you an example. I travel a lot and family members and friends, they know that I go to the chiropractor lot. So they buy me things for my back. And one of these father's days, I got a back massager, plug the back massager in, nothing. Crickets didn't come on. It had a big old document though, like big old manual, but it didn't come on. What good was the manual when the actual product didn't come on? You get what I'm saying? So when I think about these things, I think about experiences I've gone through and I'm like, wow, that's actually right. I had a product, but it didn't work. And the big old document that came with it, the manual, was useless. And it's a very good illustration of how we value a working product over the manual. You see what I'm saying? So what did I do? I took this thing, put it back in the box and sent it back to Jeff Bezos, Amazon. Got to Amazon, two weeks later, I got a new one, thank heavens, plugged it in, thing came on and now I could use the manual. Now it made sense, you get what I'm saying? So you should value a working product over comprehensive documentation because your customer values the working product anyway. They don't care about the manual if the thing is not working right. And then customer collaboration, you got to value that over contract negotiation and value responding to change over following a plan, because everyone has a plan until, until you're punched in the face, then you got to change, you get what I'm saying? Everyone has a plan until they punch in the mouth, then they got to pivot, then they got to change, they got to look for plan B. And honestly, for some people, it's too late. Look at Blockbuster, it was too late for them. Netflix came begging them. Biased. But they weren't Agile. Uh, they weren't thinking to pivot to the market. Oh, wait, I made a mistake. They actually did, but they pivoted the wrong way. They tried to do something with Enron to do online movies with Enron, and if it failed, the interface looked horrible anyway. So that failed. And before you knew it, they were out of business because the world had moved. It reminds me of the world of AI. A lot of people, I don't want to go into a, uh, is the demon in the basement. And honestly, if you don't pivot to these things, you're going to be left behind. Look at Kodak. Kodak didn't want to pivot to digital photography. They discovered the digital camera, but they said, let's keep it under wraps. If we don't keep this under wraps and it gets out, people aren't going to buy our hardware anymore, they're not going to buy our film, they're not going to buy our cameras. Let's not go into digital cameras just yet. And they try to quieten it down until the likes of Apple said, huh, huh, let's put this thing in the iPhone. Can you imagine a phone dethroned the camera? It's crazy. It's unbelievable. And that's why a lot of YouTubers and TikTokers, they ain't got no camera, they're using a phone. You see how agile, uh, flips things on its end. So you've got to be able to pivot. And the Android people, they got on that wave. And, you know, it cost Samsung a lot of money. Steve Jobs was very displeased with the Google boys, but now, uh, they made peace. And, you know, now everyone's pivoted to where the world was going. You get what I'm saying? There's so many examples over time of people and companies that didn't pivot. You got to be agile, my friends. Okay? So this is just the very beginning. These are the values. On top of the values, we've got principles. So I'm going to go over the principles with you. I'm just going to give you a few words to remember the principles. We're not going to go too crazily deep into it. So I'm going to get rid of this, but I'm going to talk about my very first principle here, and it's my favorite. I love this principle. You know, it started helping me understand my obsession with customer satisfaction. If the customer is not happy, quality has not been met. Justice has not been served. You got to make it right with the customer, for the customer. And the Agile Manifesto, the very first principle, it just says our, uh, highest priority is to satisfy the customer. So I'm going to show you all 12. This is, number one. Satisfy the customer. Customer. You got to be obsessed with the customer. Our, uh, highest priority. Everything else is not as important as this. It's, uh, our highest priority. That's a big statement. If only every organization had that mindset. Highest priorities to satisfy the customer through early and continuous delivery. Early. Give them what they want. They're hungry. Give them food. They're craving. Features, Give them features. And then early and continuous. Don't stop the love. Keep it flowing. Give us value. We're going to eat it up. It's a lovely mindset, my friends. Highest priority. Wow. Through early and continuous. Why early? Because if we're in a world of agile. You see, in the world of Agile, we do things in what we call iterations or sprints, and they're very short bursts. And we get this done and then we deliver, and then we get some feedback and then we go do something else and then we build on what we delivered and we deliver more, and then we go back and build and deliver and it's a continuous flow. And that's why you stay with Apple. Or maybe not. And that's why you stay with Samsung. Oh, now we're getting into territory I didn't mean to go into. Maybe that's why you stay with Microsoft. Let's keep the Microsoft people happy. But jokes apart, early and continuous delivery is all around you. When you go to your favorite restaurant, what makes it your favorite? It's the value. Early and continuous delivery. Continuous. Don't stop the love, don't stop the value. Okay, you get it. Number two, open up to the Agile Manifesto page. This one says, going into the principles, welcome changing requirements, even late in development. Wow. Welcome. Changing requirements. Changing requirements. You asked, uh, for this item A. Why are you asking for item b at the 99th hour? How dare you. It was already etched in stone. You can't do that to the development team. It's not fair. We're going to sign a contract and we're going to lock down scope and schedule and cost and, um, bad, bad customer. No more changes. Well, thank goodness Agile isn't like that. Let's read it together. It's right there. Welcome. Change in requirements. Even late in development, Agile processes harness change. Think about that. You grab, um, change, you harness it, you bridle it, you write it, you use it for the customer's competitive advantage. Wow. Wow. If only companies and people and developers could truly have this mindset. Now. You know what I get from a lot of people? People say, well, Phil, why would this happen? It shouldn't happen in the construction industry because it won't fly. There are other ways of dealing with this, but let's not miss the very first word. What's the first word? Read it, read it. Welcome. It didn't say accept all changes, but it said you welcome the change. Like, oh, let's see what this is all about. And when you welcome it, it's a mindset shift as opposed to, oh, that dog on customer again, asking for changes. Instead you're like, oh, oh, a change. Okay. Because you're looking to harness change. You are team customer. I have a lot of people, they're solo. Oh, the contract said, uh, you see the problem there? So that's why we said customer collaboration needs to be the mindset. So it says agile processes harness change for the customer's competitive advantage. Don't you want your customer to be advantageous in the marketplace and competitive? Don't you? I want my customers to kill the game. I want them to dominate. You get what I'm saying? So it needs to be a mindset. All right, let's go to number three. I'll try and be a bit quicker. Number three. Deliver working product frequently. Deliver frequently. Deliver working product frequently. I'm, um, paraphrasing the word software because these days the world of agile permeates industries. So I want you to think about this. Deliver working product frequently from a couple of weeks to a couple of months, with preference to the shorter time scale, which means a couple of weeks is preferred, not a couple of months. Couple of weeks. Now why would we do that? Because couple of months is a long time when you think about it in the agile world. So the shorter the better. A couple of weeks is pretty much the norm in industry. And you got developers doing things in these two week sprints and then delivering. They do things and then they hand over and when they hand it over, it goes into production. The customer is able to get value quick, they're able to give feedback and you're just applying great value on your customer. Whether it's internal or external. You. It's a good thing. It's a good thing. Okay, I hope that makes sense. So when we say deliver working product frequently, you know, there's a difference between having a release versus having a PSI, potentially shippable increment. You could have like tons of PSIs, but it may not be featured enough to release. You get what I'm saying? So when we say deliver it frequently, couple of weeks or a couple of months, we actually mean as much as possible. Let it get into production, let them begin to use it, because that's where they're going to get the value. All right, let's move on. All right, number four, business people and developers should work daily. That's the key word. Business people and developers, should it say should. It actually said must. Uh oh, this sounds like you got no option. Now when you boil it down, this is the world of agile. We do things in sprints, in iterations. Think about it, a two week iteration, you got 10 days. No wonder it makes sense to work together daily because 10% of the work is going to be done in a day just if you average it out. So it does make sense to say you must, you must have access to the stakeholders, you must have access to other team members. You shouldn't just be in your little silo in a den saying, okay, I'm working alone. No, time is of the essence. So we got to collaborate, we got to interact on a daily basis. And that's what it says. Business people and developers must work together daily throughout the project. Okay, that's a memo you don't want to forget. Number five. Number five says build projects around motivated, motivated people. It didn't say build projects around motivated teams. It's a motivated people, which means there's an expectation that we hire people who are emotionally intelligent. Emotionally intelligent. And they got a mindedness of accountability, they got a mindset of autonomy. They're not waiting for their boss to come and wind them up. Oh, let me pump this person up and get them motivated. In the mood. No, you got to motivate yourself, you got to inspire yourself. Motivated people, people who, when they understand the greater good, they're ready to go. Get what I'm saying? So motivated people build projects around motivated people. Give them the environment and support they need, give them what they need, give them the team space, give them the tools and boost their morale if you need to. There's nothing wrong in being an inspiring leader. Give them all that stuff, water the team, feed the team, help the team, give them what they need. But, uh, trust them. You see, that's what's missing in a lot of business. They ain't trusting the team, they're Micromanaging the team, they're dangling carrots and sticks and those are all core approaches. So when we hire the right people, we got to put them in the right place on the bus and we're going to leave them alone to do their job. Hire the right people, hire the right fit, give them the environment and support they need and get out of their way. Be a servant leader. Remove the roadblocks. That's what it's saying. Okay, so build projects around motivated individuals. Okay, let's move on. Going into number six, the most efficient and effective method of conveying information to and within a development team is face to face communication. Face to face communication. Satisfy the customer, allow requirements to change, deliver frequently, work together daily. That's your calendar. Motivated people, happy and pumped team. All right, motivated individuals. And then this one is face to face communications, right? It says the most efficient and effective method of conveying information to and within a development team is face to face conversation. Conversation, uh, what is conversation? It's like it's an exchange, right? And then the next one says working product. Working product is the primary measure of, of progress. We want a product that works, a working product. That's how you're going to remember the working product. A radio that actually can get stations and play music and entertain you. Working product is a primary measure of progress. You see, in the world of Agile, it's no good saying, oh, we're 88% done, we're 99% done, we're 88.9% done. Um, that's all well and good in the world of predictive, but in this world of agile, we don't get bogged down by percent completes. Why? Because remember, we're working in these two week iterations and you're either done or you're not. And if you ain't done, you ain't done. So the promise is at the end of two weeks, we're going to deliver a working product, a potentially shippable increment. And if you don't deliver it at the end of the sprint, you know you didn't meet your goal. And that's the question. You either did it or you didn't. And that's how we look at it in the world of agile. So working product, that's the primary measure of progress. You're either done or you're not done. All right, number eight, It says agile processes promote sustainable development. Sustainable development. I like to think about it like this, even though it has nothing to do with a plant. But I want to think about it like humans need to be fed and watered, right? Humans need to recover when things have gone crazy. You see that? So I'm going to use this metaphor of a plant because it's green, right? Sustainable. And honestly, I call this one the don't kill the team, don't kill the team principal. Don't kill the team. You got to allow the team recover. You got to think about growth. You got to think about the team being able to recover from tough times. You got to think about the team being able to sustain their work. So think about it. If you are making a team work 80 hours every single week and they sustain that pace, someone says, yeah, Phil, that's the story of my life. That's not quite right. You shouldn't make humans around you work 80 hours a week. That's. That's crazy. Now, now, if the team is working all that time, daily, what good is it? A very sad story of an individual, a friend of a friend who was at his desk working hard and he just slumped. And that was it. Is it worth it? It's not. It's not worth it. Remember, you are replaceable. My mentor, John Maxwell, he jokes that the very next day they're passing the potato salad at the funeral and trying to get drinks. It's a sobering thought, but it reminds me of don't kill the team. Sustainable development. So let's read it in full. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. Can you maintain a pace of 80 hours a week indefinitely? I, uh, want to wager that you can't. And if you say you can, that's sad because you really shouldn't be doing that. Now, I know that a lot of people say, well, I've got a business, I'm doing that. And proceed with caution. Okay, but don't kill the team. The measure that you make for yourself doesn't mean you should push that on people. Not everyone's cut out for 80, 90, 100, 120 hour weeks. Okay? So I want you to keep that in mind. Very good. All right, so the sponsors, developers and users should be able to maintain a constant pace indefinitely. The next one. Number nine. Number nine. We're doing very well. Number nine says continuous attention to technical excellence and good design enhances agility, technical excellence, continuous. Which means you don't give up on being technically excellent. You know your stuff, you know your subject matter. If you're a coder, you know your coding. You know the rules of coding, you know the rules of the Game. You understand how you're going to share work, and you got it down. Technically, technical excellence and good design. Good design. Steve Jobs would say, design is not what it looks like. It's not what it feels like. Design is how it works. You got to understand the big picture, the inner workings. That's what design is. It's not just saying, oh, design is how it looks or how it feels. Uh, that could be part of it, but that's not it. That's not the ultimate. The ultimate is high works. Right? So technical excellence and good design enhances agility. How is that? Well, when you're technically excellent and you make sure that the flaws, the kinks are removed, you make sure that the bugs and the errors are minimized. What happens? What happens? You get leaner and meaner. There are less mistakes, you get better and better, and there's less rework. Right. When you're technically excellent, when your designs are good and it says it enhances agility, okay? This makes you more agile. It prevents a whole lot of fan cleaning. Like, when you're not technically excellent, it's boo boo after boo boo, mistake after mistake, cleanup after cleanup. You bring in the cleaning crew. They got to clean it up. We don't want any of that stuff. All right, number 10, let's read number 10. Simplicity. The art of maximizing the amount of work not done. What did you just say? Maximize the amount of work not done. Yeah. Simplicity. Maximizing the amount of work done, not done is essential. So what are we really saying? Keep it simple, sister. Keep it simple, sir. Keep it simple, students. Not the other one. You're used to saying, that won't be agile. There's no space for that one here. But what we're saying is you've got to keep it simple. So for this one, number 10, I'm just going to say kiss. Keep it simple, sister. Maximize the amount of work not done. So I'm going to say this. This is all the work that was not done, not done. You maximize the amount of work not done to get the same value. You get what I'm saying? Let me give you a visual. Okay? This is all the work not done. This is what we want. This is what we do not want. Like, on the flip side, you have people thinking, well, I guess I'm just going to do all this work. I'm going to do all this work, and this is going to be the not done work. Now, uh, that's not the assignment. The assignment is to keep it simple by maximizing the amount of Work you didn't do to get, you're still going to get the full value, but you're going to be, you're going to be smart with it. You're going to maximize the amount of work not done. You're going to find ways of delivering the value needed without doing bucket loads of work. Do you understand what I'm saying? Okay. You got to maximize the amount of work not done. Okay my friends, so you got that visual? We got two left. Okay, very simple. Let's take a look at the remaining two. All right, the best architectures, requirements and designs emerge from self organizing teams. What are we trying to say here? Well, what we're saying is if you leave the team alone to get this stuff done, get out of their way, clear the roadblocks, we find that the best architectures, the best requirements and designs, they emerge from self organizing teams. When the team is left alone to self organize, the results are mind blowing. I found this across teams that I've worked with and um, teams I've trained. When I give a team an assignment and I walk away and let them solve it, sometimes I actually give my students problems that I'm working on. And uh, you know the funny thing, even though they are students, when I leave them alone to think and I allow them to let that stuff marinate, you know what happens? Uh, at the end of the day they get a better result, a better outcome, a better idea than I even had. So the best architectures, requirements, which means knowing what needs to be done, right, features and functions, they come up with these great ideas and designs. Self organizing teams, it's, it's really mind blowing. Okay, so number 11, self organizing teams. I'm just going to use very simple language. Self. Self organize. All right, number 12, this one is definitely one of my favorites. Self organized. We just have a team self organize. That should give you an idea, reminder, technical excellence. We'll just use a basic flow to remind you about this. Okay, final one, number 12. Number 12 just says regular intervals, the team reflects. They spend time in reflection. So I'm just going to call it retrospect, team retrospective. Let's just call it a retrospective. But again, it doesn't have to be just a retrospective. It says as at regular intervals. You see what I'm saying? Regular intervals. It doesn't mean that it has to be just at the end of the entire sprint. Regular intervals could mean that daily you're taking account of what needs to be improved on. How well are we doing? What can be done better, what can we do better right now, today to improve. So, team retrospective. This is where the team is thinking, How can we do better? Right? It's a team think. The team is asking that question, hmm, what can we do better? How do we improve? What did we do well? What didn't we do so well, what can we repeat? What should we repeat? You know, so it says at, uh, regular intervals, the team reflects on how to become more effective than tunes. They don't just reflect on how to become more effective, they tune, they take action. You see that? They tune and adjust accordingly. There you have it, my friends, the Agile Manifesto. Values and principles. Now, it's anchored down, you got it in your head. So when you come across these questions on the exam, you're going to be like, I know which principle this is testing. I know what should be done. Slam dunk, easy peasy lemon squeezy. All right, now you can see, my friends, when I say that the PMP exam is a beast, you now understand why it is a humongous beast. We spent almost an hour covering the process domain first in part one. Now we spent almost that same time. Yeah, we've spent another 40 plus minutes covering just the agile philosophies. We haven't even started getting into the intricacies of any of the frameworks. So we're going to take a break here and then when we come back, we'll get into the world of Scrum. I'm going to show you scrum, the 3 5, 3 of scrum, and then we're going to wrap up the, uh, process domain, general understanding, and then we'll go into the business domain and we'll be done. All right, thanks for joining me. If you found value from this, smash the like button, I'll see you in the next one.