In this video, we will discuss Agile Principles. We will start by discussing the Agile Manifesto value statements. Here's the manifesto for Agile software development, commonly called the Agile Manifesto. We will go through it piece by piece. First of all, notice that the copyright statement is from 2001. The authors agreed at the time, not to change it moving forward so it is a static historic document. Having a static document related to Agile Software Development is a bit ironic, because continuous improvement is fundamental to Agility. The document is static, not because the writers thought it was perfect, but because this is what they agreed to at the time. The Agile Manifesto represents the commonality of some of the different Agile approaches at the time. If we step back and look at the title of the Agile Manifesto, you can see that it was intended as an approach to software development. Agility is broader than that, so the scope of this document is limited. However, we will see that many of the ideas apply to Agile projects in general. The Agile Manifesto starts with a bit of context saying, "We are uncovering better ways of developing software by doing it and helping others do it." The we in that sentence refers to the people who authored it. They had a lot of experience, and they described in general what they found to work well in developing software. By uncovering better ways of developing software, they are basically saying that, in their experience the plan-based or Waterfall approach does not work well for software development, compared to an Agile approach. At the time they wrote this, Agile approaches were not as common as they are today. This was an attempt to help transform the thinking of the software development industry. Next to the manifesto contains four value statements. The first one is, through this work, we have come to value individuals and interactions over processes and tools. Using the word over in the value statements helps clarify what they are talking about. In the context of trying to convince an industry to change from Waterfall to Agile, this approach makes more sense, they are placing high value on individuals and their interactions. This is related to empowering the team, and encouraging collaboration. They are placing lower value on processes and tools. An empowered team can choose the processes and tools that work best for them. After the four value statements, they further explain the structure of value statements. That is, while there's value in the items on the right, we value the items on the left more. Again, in the context of trying to convince an industry to change, this makes sense. In an agile approach, the team is empowered to make decisions. The processes and tools that this team uses is secondary to that. The next statement is, we have come to value working software over comprehensive documentation. This places the value on continuously building things that work over heavy upfront planning. This is similar to the lean principle of focusing on value and eliminating waste. A large upfront planning document is likely to be quite wrong and or misunderstood, and therefore, is a source of waste. The next statement is, we have come to value customer collaboration over contract negotiation. This is basically saying that the customer should be a member of the team, realizing that building the project is a continuous learning process on all sides. You don't want to have an arm's length relationship with your customer that is bound by an inflexible agreement, as is common with Waterfall projects. When an upfront agreement is made, the true nature of the project is not completely known, and the team and its customers should realize that and work together. The last of the four statements is, we have come to value responding to change over following a plan. This is basically acknowledging that, especially for complex one-off projects, you cannot predict the future, and instead of heavy upfront planning, a better strategy is to embrace change. So, that is a look at the value statements in the Agile Manifesto. They were basically saying that, for software development, they have experienced that Agile processes work better than traditional Waterfall processes. These ideas seem straightforward and almost common sense now, but many projects that should have been managed this way were not and in some cases, that is true for current day projects. You can see that most of these value statements have nothing to do with software, and can apply to many types of projects. For example, if you change the words working software to something like incremental planning and development, the ideas are more generally applicable. To simplify things, we will convert the Agile Manifesto value statements into principles. We will then build an organized list of principles as we continue. The first principle is to empower the team. This comes from the individuals and interactions over processes and tools statement. The second principle is to embrace change, this comes from the responding to change over following a plan statement. The third principle is to partner with the customer, this comes from the customer collaboration over contract negotiation statement. The fourth principle is to plan, develop and deliver incrementally. This comes from the working software over comprehensive documentation statement. Next, we'll discuss the 12 principles described in the Agile Manifesto. After creating the four value statements, the group created 12 principles related to Agile development. We will take the liberty to organize, simplify, and re-word these to allow us to end up with a single set of simple Agile principles. We will also make the principles generally applicable rather than focused only on software development. The first principle states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." In other words, plan, develop and deliver incrementally. This is very different from the Waterfall approach where a big plan is created and the entire product is built in stages. Also, a main benefit of early and continuous delivery is that you are obtaining fast feedback. This is one of the key benefits of using an Agile approach, since early feedback can result in much less wasted effort. This principle is also highlighting the need to focus on value. The second principle is, "Welcome changing requirements even late in development." Agile processes harness change for the customer's competitive advantage. In other words, embrace change, it provides a competitive advantage. The third principle is, "Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale." This is an example of the Agile Manifesto getting a bit stale. Today, many teams deliver multiple times a day. To cast this statement in other words, plan, develop, and deliver incrementally, with a preference to a higher frequency. Also, when you are delivering frequently, you are obtaining fast feedback. The fourth principle is, "Business people and developers must work together daily throughout the project." In other words, collaborate to create shared understanding. You want all team members to work together often, communicate in a way that everyone understands, and have a clear understanding of the project. The fifth principle is, "Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done." In other words, select motivated individuals and empower the team. The sixth principle is, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In other words, prefer conversations for conveying information. Whenever people communicate, part of the information has a chance of not being accurately conveyed. The best chance of being understood is with the conversation. You can contrast this with a plan-driven approach, where the people reading the plan have a higher likelihood of misunderstanding what the people writing the plan met. The seventh principle is, "Working software is the primary measure of progress." In other words, completed work items are the primary measure of progress. The eighth principle is, "Agile processes promote sustainable development." The sponsors, developers and users should be able to maintain a constant pace indefinitely. In other words, maintain a sustainable pace. It is a by-product of the proper use of Agile processes. It's important to trust the team to make appropriate commitments. Most Agile organizations encourage working at a sustainable pace. The ninth principle is, "Continuous attention to technical excellence and good design enhances Agility." In other words, don't compromise on quality. It can be tempting to take shortcuts in order to deliver, but it is much better to develop with high-quality continuously. Also, continuously refactor to maintain Agility. Refactoring basically means that you are improving the product without changing its functionality. This often involves simplifying and increasing the quality of the product. The result of this is that the product can be easily adapted to changing conditions. The tenth principle is, "Simplicity, the art of maximizing the amount of work not done is essential." In other words, continuously strive for simplicity, and focus on value, eliminating waste. By the way, in many contexts, that is a debatable definition of simplicity. Achieving simplicity is often not easy, and is not about minimizing the amount of work done. Here are some quotes related to simplicity, that seemed to contradict a literal reading of the 10th principle of the Agile Manifesto. Steve Jobs said, "It takes a lot of hard work to make something simple." Pascal said, "I would have written a shorter letter, but I did not have the time." Leonardo da Vinci said, "Simplicity is the ultimate sophistication." The 11th principle is, "The best architectures, requirements, and designs emerge from self-organizing teams. In other words, teams should self-organize. It results in the best outcomes. The 12th principle is, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In other words, continuously inspect and adapt. Things like daily stand-ups and retrospectives are used to adjust the behavior of the two. This is a combined list of principles from the Agile Manifesto value statements, and 12 principles, rewritten for general project use. The main principles are to empower the team, embrace change, plan, develop and deliver incrementally and focus on value. Next, we will discuss Lean versus Agile. We have discussed Lean and Agile principles. Lean is a term used at MIT by John Krafcik. It was used to describe the ideas of the Toyota Production System. The ideas apply to any type of project, even personal projects. Agile is a term used by participants who created the Agile Manifesto in 2001. Agile originally described a lightweight alternative to plan-driven or Waterfall Software Development. Over time, Agile has taken on a broader meaning that can be applied to any type of project. The Toyota Production System could have been named Agile, it's just that Lean was chosen. Similarly, Agile could have been named Lean. The terms Lean and Agile are often used interchangeably to describe an adaptive approach that focuses on value. Many of the common principles are found in Taiichi, Ohno's 1978 book called Toyota Production System. Here is a combined list of Lean and Agile principles. These are all good principles to understand well, and to use where appropriate. The main principles are to empower the team, visualize work, experiment using the scientific method, plan, develop and deliver incrementally, improve the flow of value, and build quality in.
