Another helpful piece of content that I found when I was on this journey, to help dispel the myth about Lean not being applicable in software delivery, is work that Mary and Tom Poppendieck did, to take the Seven Principles and wastes of Lean, and translate them into software development. In this video lesson, I'm going to go over these, so that by the time you finished it, you should be able to, identify and describe the Seven Principles, and wastes of Lean as they pertain to software development. One of these principles is eliminating waste. Which is making sure that you're not coding more features than needed. You're minimizing handoffs, and really not producing anything that is of low or no value. This also means making sure that you're making decisions at the right time. Sometimes, organizations will delay decisions, waiting on additional information, and worrying about being wrong. In my experience, it is more important to make progress, and start learning versus trying to be precise. As long as the organization is set up with a structure to learn and adjust, as new information becomes available, it is much better to get started and move forward, versus waiting to make a decision which often can translate to cost of delay. The second principle is building quality in, and this is tied also to the Deming quote. "Quality is everyone's responsibility". This principle is about making sure that you have quality built into the product and into the process. The third principle is creating knowledge, which is also known as amplifying learning. This is really where Lean software delivery differs from the manufacturing industry. Development is constant learning. We know that there are going to be issues, and we need to learn from them and make adjustments. Feedback loops are extremely important to address this principle, and we'll discuss those in more detail later in the course. The fourth principle, is differing commitment, which is about making sure that decisions are made at the right time, after analysis and considerations have been made. Delaying decisions can be a valuable exercise, because it allows you the time to gather more information before committing to something. This is not intended to contradict what I said earlier, both types of decision-making are important. You need to balance paralysis with timeliness of decision-making. I recently learned from one of my colleagues at Amazon, that they use the concept of one-way door, and two-way door decision-making. If it's a one-way door, meaning you can't come back, then the criticality of having analysis and information is different, versus a two-way door meaning you can come back through. In a two-way door decision-making scenario, the behaviors I described earlier apply. Making progress is more important and enables faster learning. The fifth principle, is deliver fast, the idea of delivering fast is really to ensure that feedback is received early and often, to allow for course corrections in development. If you use smaller batches, which again we'll talk about a little later in the course, you should be able to deliver faster which will allow you to gather feedback at an increased rate. The sixth principle, is respecting people. People are at the center of DevOps and Lean. If you aren't practicing that then it typically falls apart. I believe passionately that people are an organization's number one asset. Often though, organizations don't behave that way. When I first started getting exposure to DevOps and Lean, I realized that fundamentally it's about respect for people. I became even more excited about applying the techniques and sharing that message more broadly. The final principle is called optimizing the whole. This again is a systems thinking approach. You want to make sure that you're not doing local sub-optimization, and that you are optimizing for the entire system. So, those are the seven principles of Lean as applied to software development. Mary and Tom Poppendieck, do a good job of encapsulating all of the major DevOps principles in an easy to understand framework, but they went further and then translated Lean seven wastes into a more applicable version for software development as well. The first waste, is partially done work. So, code that is completed but not checked in to the repository, undocumented code, untested code, or code that's not yet in production. This is a problem, because this is delaying the delivery of value. In the case of undocumented code, this will likely lead to quality issues or delays, and resolution of issues. The second is extra features which Scott mentioned earlier. It's like if you're building more than what your customer needs, then that is waste because ultimately no one will ended up using it at all. The third waste, is re-learning or revisiting decisions. If you're having a situation where you have to resurface the decision or information, then that is considered wasteful. Fourth, is handoffs, which is pretty straight forward. You don't want to have a lot of handoffs in your value stream, because each time you do a new team has to orient themselves to the work and what's done before. This creates delays. So, it's best to minimize the number of hand-offs. Included in this, is back and forth communication. I've seen a lot of situations where something is handed off and the team receiving the handoff, may or may not have the information needed to move the work forward. If they don't, they often hand back or to yet another team for information. Minimizing and ultimately eliminating all the back-and-forth handoffs, will accelerate software delivery. Speaking of delays, the fifth waste is in fact delays. So, that includes anything where you're waiting on someone or some part of the process before continuing. The time it takes for code to compile could be classified as a delay. For example, if you're waiting and there are delays then that is keeping you from delivering value as efficiently as possible. The sixth waste, is task switching. This comes up a lot in DevOps, where people are getting context switched or interrupted and they can't finish their work. Research has demonstrated over and over again, that task switching often referred to as "multitasking", is the enemy of all productivity, software development or otherwise. I think it's really only recently that people are questioning multitasking as a benefit. The seventh and final waste, is defects. Again, quality needs to be built into the product from the get-go, any defect is considered waste. As ultimately, it will create a situation where your customer will not use your product, and if rework is required that is keeping the team from delivering more value. So, those are the Seven Principles and ways of Lean as they apply to software development. Again, credit to Mary and Tom Poppendieck, for translating these concepts to something relatable to our industry. I highly recommend leveraging these translations as you introduce DevOps and Lean into your organization. Having a common vocabulary and definition is helpful, as you transition to this new way of getting work done.
