 Well, we've covered off on our basics. It's now time to introduce our first meat chapter, third chapter of our course. In this chapter, we're going to introduce the agile principles and mindset. We're going to cover a lot of ground. In fact, it's the largest single chapter in the course. For most people, it's also the single most difficult. Unlike other tests, as has been previously mentioned in the agile world, PMI's ACP exam does not focus in on a single agile methodology. In fact, it requires you to know a number of them. That means we've got to introduce all those methodologies to you. Everything from foundational agile concepts to Scrum, extreme programming, feature-driven development, dynamic systems development, the different crystal methodologies, the concepts of lean and can bond, test-driven development, and the list goes on and on and on. It's a lot of ground to have to cover, but if you're ready to get started, let's go ahead and introduce our first topic here now. Let's begin our discussion of agile principles and mindset by examining the domain tasks here. First, we must advocate for agile principles by modeling those principles and discussing agile values in order to develop a shared mindset across the team as well as between the customer and the team. Secondly, we need to help ensure that everyone has a common understanding of the values and principles of agile and a common knowledge around the agile practices and terminology being used in order to work effectively. Thirdly, we need to support change at the system level or organization level by educating the organization and influencing processes, behaviors, and people in order to make the organization more effective and efficient. Fourthly, we need to practice visualization by maintaining highly visible information radiators. A key term we'll discuss a little bit later on and showing real progress and real team performance in order to enhance transparency and trust. Fifthly, we need to contribute to a safe and trustful team environment by allowing everyone to experiment and make mistakes so that each can learn and continuously improve the way he or she does their work. Sixth, we need to enhance creativity by experimenting with new techniques and process ideas in order to discover more efficient and effective ways of working. Seventh, we need to encourage team members to share knowledge by collaborating and working together in order to lower the risks around knowledge silos and reduce bottlenecks. Eight, we need to encourage emergent leadership within the team by establishing a safe and respectful environment in which new approaches can be tried in order to make improvements and foster self-organization and empowerment. And finally, our ninth domain task is to practice a concept called servant leadership by supporting and encouraging others in their endeavors so that they can perform at their highest level and continue to improve. With those tasks in mind, we can now turn our attention to diving into our agile principles and mindset to figure out exactly what these terms really mean and how we're going to achieve them. We begin our dive by discussing the relationship between the PIMBOC guide and the agile movement. When we look at the PIMBOC guide, it's a book published by the Project Management Institute who also owns the ACP certification as well. When you look at the PIMBOC guide, most certified and trained project managers, as well as most people knowledgeable in the industry of project management, consider that to be the standard for the profession. It is a true framework. It establishes sets of rules and guidelines that projects and project managers are expected to follow. However, it is not the same thing as a methodology. You see, within the PIMBOC guide are a wide range of differing ideas. And as you go through the book, it is actually impossible to manage a project only by following the PIMBOC guide. There's just too many different contrary ideas in there. What the PIMBOC guide actually represents is what we refer to as generally accepted practices, tools, and principles. When we look at agile development, it represents a family of specific methodologies. Now, for many of those methodologies, they like to refer to themselves in many cases as frameworks as well. So that means we need to differentiate between a methodology and frameworks. When we talk about a framework, we mean a guiding set of principles. Think of it almost like a scaffolding, helping to hold up a building or walls as we're going through the process of construction. A methodology, on the other hand, represents the specific steps that that particular set of projects or that organization are going to use in order to deliver the product service or result of the project. It's do this first, then this, then this, and you do them in a particular way. That is a methodology. And to some extent, it's prescriptive. Now, as we'll talk a little bit later about methodologies like Scrum, which likes to refer to it as self as a framework, it does so because its set of rules, while pretty strict, you must do several things. It's not a huge set of rules and it offers a great deal of flexibility. So long as you do those basic things correctly. However, when we come back to the Pembach Guide versus Agile Development or an Agile methodology like Scrum or Extreme Programming, it's important that you realize that almost all of the Agile methodologies fit inside the Pembach Guide. They are not contrary. Now, for those of you who come from a development environment or background and have been formally trained probably first and foremost from an Agile perspective, that statement might seem incredibly contrary. How can this be? We've been fighting against traditional project management for so long, yet nothing could be further from the truth. You see, the Pembach Guide is not the opposition to Agile Development. The opposition of Agile Development are very stagnant, poorly run projects. The best trained project managers are open to many different methodologies and ways of thinking because there is no one size fits all. There is no one perfect methodology. It's about alignment, finding the right methodology for a particular organization, a particular group of people, and a particular project. That's how we find success. When we look at Agile Development, the Pembach Guide and Agile go together. The Pembach Guide provides our far-reaching umbrella that describes how things on general work and then our concepts found within Agile Development give us our very specific rules of how we're going to do this particular project. So what is Agile Development? Well, there are two aspects of Agile Development that are absolutely critical. The first is what we call incremental development. When we discuss incremental development, we're discussing a staging and scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed. We then talk about iterative development. Now, iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. These definitions are offered by Alistair Coburn and what exactly do we mean here? Well, the first thing is that we're going to develop the components or the features of the application at different times throughout the project lifecycle, not all at once. This means we're not going to have a single release or time at the end of the project, which is the only time we provide our customers something that's working. The second is our iterative development, which contends that we are regularly going to schedule in some way, shape, or form ways of revising and improving our system and our product that we're creating, both the process and the product. So that's key here. When we look at Agile Development, it provides a set of tools that ensures we're always iterative and incremental. The next major concept is something called WIP or Work in Progress and we have to differentiate WIP from another concept called best resourcing. Now, many project managers are pretty familiar with the idea of best resourcing. Best resourcing occurs whenever we try to find the absolute perfect resource to do a task. Let me give you a simple example. Imagine that we have three deliverables, deliverable A, B, and C. Now, each one of these deliverables also has a resource within our organization that would be absolutely the perfect resource to do that task or deliverable. And so, of course, the best resource to do A would be resource A, and the best resource to do deliverable B would be resource B, and the best resource to do deliverable C would be resource C. Here's the problem. Imagine you're like most projects and you have a limited amount of time and money. Let's just say for the sake of argument that you only have six time money units that you can spend to get this particular amount of work accomplished. If it's like most traditional projects, what happens is you assign the best resource to get the work done, so A begins working immediately on deliverable A, resource B begins working on deliverable B, and resource C begins working on deliverable C. As they get two thirds through their work, each of them has spent two time money units trying to get their deliverable accomplished. Unfortunately, we're out of time money, and we have nothing of real value to show for it. This is the fundamental problem that many projects face. Unfortunately, we, by using the perfect resource to get the work done and not effectively managing how much we have going on at any one particular time, we position our sponsors, product owners, whatever we're going to call that person leading the organization and making decisions into a corner. You see, in order to get anything of value, they're stuck. They have to finish off all the work. Otherwise, they spent all this time or money on trying to get some work done, and they have nothing of value to show for it. Let's take another way of solving this problem. It's taking into account our idea of work in progress. And as it says, what we're really talking about is how much do we have going on at any one particular time? Like a water main in your city, WIP needs to be managed very carefully. You see, the water going through the water main isn't at maximum pressure. It's an inefficient way to try to deliver the water. In fact, an engineer would tell you typically, we only put a significantly less amount of water than what the pipe is capable of handling. You don't fill it to 100%. You see, if there's not a pocket of air, unfortunately, the water doesn't travel as quickly as it could otherwise, and there's lower pressure. And it's the same with work. We want to make sure that we are always as quickly as possible, maximizing the output we deliver to our organization. So how are we going to do that? Well, instead of assigning the absolute perfect resource to get work done, we want to assign resources that are at least capable of getting the work done. So imagine we have our same scenario, deliverables A, B, and C, and resources A, B, and C. Only in this scenario, we're taking into consideration WIP. So in this scenario, we assign deliverable A to resource A. It really is the best and it's important. So we want to make sure we get it done. We also have the same situation going on with deliverable B. So we assign resource B to that one as well. Now it's resource C where we make the change. You see, when it comes to that third deliverable, we're not going to start it yet. Resource C is capable of helping out A and B. And since A is the most important deliverable, we assign C to help out resource A and get that done. As soon as they are done helping out resource A, they're going to shift gears and help resource B. In the same six-time money units, we're able to deliver two fully completed deliverables. And we have absolutely no waste. And this is a critical aspect of WIP. You see, no work has been done on C. This puts our product owner or project sponsor, the person making those key decisions again, in a much more advantageous situation. Because now they can look at that third deliverable and say, how important is it really to me? Do I really need it? Or am I satisfied with the first two deliverables? If I need it, we then can go ahead and we will end up going over that six-time money units that we have for our project. But now it's a very conscious decision. I'm not forced into the corner. And if we've done our process efficiently, as defined in our agile framework, what we're going to see is that we are delivering those deliverable A and Bs that are out there much quicker. And because of that, our organization, our customers, have been able to use the product much longer than they would otherwise. So that's the concept of WIP. Before we get too far in explaining what agile is and how it works, let's take a step back for a moment and look at where agile actually started. The agile frameworks, methodologies, whatever it is you want to call them have an interesting background. You see, unlike a lot of the project management frameworks and methodologies, theories, concepts that exist out there, agile development came from the developers within the IT community specifically. Those software programmers who were writing the code and, in many cases, were very frustrated with the way their projects were going. They lacked, in many cases, an expert understanding of project management, but they knew what they didn't like about the way projects were going. And in the mid 1990s, there were a lot of different ideas. Remember, this was the early days of the internet. So you had a lot of people posting up information on bulletin boards, comp, you serve, that kind of thing. And this is the perfect audience to do that kind of thing. Remember, these are the software developers who helped create the internet as well. And so these people have the knowledge and expertise to be able to use this new medium of communication called the internet. So a lot of stuff gets posted out there. And there are a lot of conflicting ideas. Eventually, a group of leaders in the agile movement decided to get together in February of 2001 in Snowbird, Utah. I often like to joke that they were a bunch of ski bums looking for an excuse for a good ski weekend. Now Snowbird is a ski resort outside Salt Lake City. And they got together and the story goes that they weren't initially having a lot of success. There was a lot of conflict in terms of the ideas and thoughts about what agile should be and what the correct framework or methodology around agile should be. And that frustration was finally broken through when they were able to create a series of core values that we'll talk about in a few minutes. Now, the leaders that are especially important at this meeting were people like Ken Schweber and Jeff Sutherland, who are the founders of the scrum methodology we'll discuss. Jim Heismith, who is one of the best known authors in the field. Martin Fowler, known for his expertise in refactoring and the testing process and concepts. Alistair Coburn, who is one of the thought leaders in use cases and several other key concepts. As you look at these ideas and these leaders, it's important to recognize that many of them are still very active in the agile movement. When you look at Jeff Sutherland, who still participates with the scrum alliance and Ken Schweber that created scrum.org and still engages with those associations. Martin Fowler, who is still very active in Chicago. And Alistair Coburn, who is regularly writing and posting on the internet. Jim Heismith and Kent Beck, who still regularly engage. These thought leaders and many others are still out there, still pushing forward and trying to extend the envelope in terms of what agile is and how it's supposed to work. The key there is that they came to an agreement on some basic commonalities. And let's take a moment to review and understand those commonalities now. Today there are more than 16 different agile methodologies that are fully compliant with the standards expressed in the Pembach guide and many others that are birds of a feather pretty close, but maybe not exactly. And what these methodologies or frameworks or whatever they're called have in common are a series of values that the agile community deems critical. And as we examine these, it's important that you stop and think for a moment. How many of these ideas do you disagree with? Do they go against the culture of your organization? Or are they also beliefs that you personally have and your organization tries to express in their daily work as well? We begin by looking at individuals and interactions and valuing them over processes and tools. It's about people and actually engaging with them rather than using a particular set of tools or a specific process that we follow wrote without thinking. Our next core value is customer collaboration over contract negotiations. It's about engaging with our stakeholders, you see, as opposed to simply following the letter of the law. Our third core value is that we respond to change over simply following a plan. Again, this is a value expressing the importance of people using the gray matter between their ears. It's about thinking about what's going on. Is this the right direction or have we gotten off paths somewhere? Do we need to keep going this way or do we need to make some changes? Regardless of what the plan says we're supposed to be doing has the situation changed in some way and we need to adapt. Finally, working software is valued over comprehensive documentation. We could rephrase this a little bit in project management parlance to say working product service or result is valued over comprehensive documentation. And this is a push against a mindset of administration that many of the people involved with the agile movement perceive is a common problem with many traditional project managers. You see it's not about simply filling out a bunch of pieces of paper. It's really about ensuring that we deliver something that has great value to the organization. And if we're incapable of delivering that working product service or result, we probably shouldn't be doing the project. Now these four core values are absolutely critical and central to the agile movement. Every single agile methodology complies with these four core values. Individuals and interactions over processes and tools, customer collaboration over contract negotiations, responding to change over following a plan, and working software over comprehensive documentation. Now though realize this doesn't mean that we don't have any documentation or we don't have a plan, we have those things. We also might have contracts if that's a particular type of project that we're leading, and we're going to have a number of processes and tools that we are going to make use of. The key is that we don't value those things over the four things that agile believes to be most important. So think about your own experience again and what you really value. Do you value people and the interactions that you have with them? Do you value engaging with your customers or stakeholders and your ability to respond to change when the situation warrants? And are you all about delivering something of real value to your customer? Well if all of those statements are true then maybe you've been an Agilist all along. But agile even extends these concepts further from these four core values into something that we call the 12 principles of agile software development, which we'll talk about next.