8.2 Undestand key ideas of Agile - Video Tutorials & Practice Problems

<v ->And it was in this setting, this problem set,</v> that the "Agile Manifesto," at the turn of the millennium, the "Agile Manifesto was developed by 17 software developers, and the "Agile Manifesto," it's not my intention to go through the specifics of all these steps, I don't want it to go through it and grind it one at a time, but I do want to give us all a flavor of what the "Agile Manifesto" is attempting to do. The "Agile Manifesto" was based on some principles, and most importantly, four unifying themes, and I want to focus on the themes really here, and just so we can understand the flavor for what Agile was getting at. Because you see, these software developers who formulated the "Agile Manifesto," they didn't have a bone to pick with users, they didn't have a grudge, they weren't trying to just air out a bunch of anger and in this setting, they really wanted to understand what was going wrong and why it was going wrong, and they came up with some really important ideas. So the first theme you can see here is, and notice this, individuals and interactions. Now, interactions means talking to each other, understanding each other. Individuals and interactions are more important than processes and tools. Now let's think about that one for just a minute because it's an important idea. We need to be spending more time talking to each other and less time being dependent on a set of tools, no matter how useful they can be for scheduling or planning or risk management or all the other tools that are out there. We need to be more focused on the individuals and our relationship development than on all of these processes and tools that we can get blinded by. Waterfalls should never become our go-to situation at the expense of recognizing what users really need. Second, the second theme here they talk about is they call it working software. Working software over comprehensive documentation, it's more important that everything works correctly. Now, yes, is this set up in a software situation? Of course, you can see it on the screen, and some of us who work in projects in other areas would say, "Well that's for software." The underlying theme is an important one, folks. Think of it as a working system, whether it's software or it's a working product, or it's a working service that you're trying to develop, but the point is, develop a working system. It's more important than developing a bunch of comprehensive documentation about the system. Make it work, then document it. The third point is one of my favorites, because I've seen this so many times in my consulting experiences where what happens very quickly is that a partnership, at least at the outset, between the customer and the developer, or we sometimes talk about it between the contractor and the client or some sort of situation where you have the major stakeholder developing the project and the person for whom it's intended, the company. What happens is they start butting heads, and it happens relatively quickly, right after the honeymoon period where we've signed the contracts and we're all, we think we understand you and you think you understand us, and we all are playing happy talk. So we've signed the contracts, we've gone to our separate corners, if you will, and now all of the sudden, the problems start, and when the problems start, what happens? We start getting into legal issues, right? Think about the times that you've been involved in projects with organizations, and what happens is that at some point in the process, we start disagreeing, and you try and resolve the disagreements if you can as quickly and as expeditiously and politely as possible, but the fact is there are problems that are emerging, and under those circumstances, the fear is that now we're gonna push this into the formal stuff of contracts, and okay, let's talk to the lawyers, let's get them to iron this out. What did this language mean? And I've worked with many organizations, and that unfortunately happens relatively early in the process and if you think about it, you understand that the minute we start going this route, it clouds our relationship because we go from interaction and we go from collaboration, now to a much more formal setup, where it's like, "Well you told me this," "well, no I didn't," "well, what does that contract say?" "Well, I'll have my lawyer talk to your lawyer." Folks, this is not an atmosphere that's designed to make anybody happy. We get very guarded now and we protect our own interests at the expense of trying to make the project work for the other person. So you can see this third theme is the idea of customer collaboration is more important than spending time with contract negotiation. Getting to know the customer, working with the customer, relationship development, and that's really, if I want to, if I were to explain this third unifying theme, I would say it really focuses on this idea of relationship development. Let's make sure that we're on the same page and let's make our number one priority maintaining a collaborative, mutually beneficial relationship. That's a critical idea. The last point, the last theme is an interesting one, because this is in many ways where the Agile idea comes from, and that is the notion that we talk about agility, being agile or having agility as being responsive, or quick to pivot, or being able to make changes as needed, and indeed, if we look at our fourth theme here, we can see that this notion of the importance of responding to change is much more valuable than simply following a plan. Let me say that again, because it's a critical idea. We spent a lot of time talking about the importance of developing project plans, but we should never be so blinded by any plan, as to assume that once that plan is developed, we're done, we're clear, we're rid of it. You can think of any one of a number of famous people in history, Dwight Eisenhower, so many others in different settings who have said, "No plan survives the first contact with the enemy." One of my favorite quotes is by that other great philosopher, the heavyweight champion Mike Tyson, who said, "Everybody has a plan "until they get hit in the mouth." So think about a project as a series of blows, if you will, of getting hit with this problem and that problem and the other problem, that's the idea of responding to a changing environment and recognizing that a plan is fine, but a plan can't dominate and control us, especially in the face of a changing system, or a changing situation, or a changing commercial environment. Continuing to follow a plan blindly when everything else is in a state of flux is clearly a problem area to be thought of. So we have to make sure that we're responsive to change, and recognize it as an inevitable part of the process, not something that might happen, it probably is going to, and consequently, let's incorporate that. And you can see the point they're trying to make is please don't misunderstand me, yes, there is value in processes and tools. There is value in comprehensive documentation, in the contract negotiation, in the plan itself. There's value, but to the folks who developed the "Agile Manifesto," it's very clear that what really matters is those issues on the left-hand side there, those four ideas are more important than the other four.