🎯 Definicja
🔑 Kluczowe punkty
📚 Szczegółowe wyjaśnienie
💡 Przykład zastosowania
📌 Źródła
👽 Brudnopis
Waste is the quintessential devil in lean. But what is waste? It’s easy to look at something, like deferred commitment, and identify transitional forms that are later abandoned as waste. But this is only true in light of the final product. Looked at in a process context, it’s not waste. It’s just a link in the chain that leads to the final version. So it’s important for us to thoughtfully consider what we mean precisely by waste. The Poppendiecks identify seven primary wastes for lean development. Partially done work probably means something at first blush, at least to a programmer. But the definition here is broader than you think. If you’re a programmer or if you’ve worked with one, you’ve probably heard that a feature is 90% complete only to learn eventually that half of the work to bring the feature to production still remained. The programmer is delivering an honest estimate, but only of the work to create the logic involved, which is only a small part of the total work. One of the things I was trying to explain to the manager who was resistant to test‑driven development was that having code completed without tests only gave you the illusion of completion. Completion really happened after a bunch of painful and expensive human testing. An extra feature is a feature that was produced at the wrong time. What the right time might be is immaterial. The right time might be later, or it might be never. A feature created just in case is an extra feature, and it is waste. Again, the fact that it might be needed later is immaterial. An early feature is the equivalent of an overproduced part sitting on a shelf, taking up real estate, time, and money. If you hear this and you think, well, we have to create early features that might be needed because it would be difficult to retool later on, there is your problem. Features created just in case instead of just in time are a smell that your situation is not as agile as it needs to be to react to changing conditions later on. Relearning is the acquisition of knowledge, which has already happened before. This can be the relearning of something you did before, or it can be the necessary knowledge transfer due to turnover. This is a form of waste that’s difficult to eliminate 100%. Even the greatest organizations in the world are going to have some turnover, and reality often means that you have to shift your attention away from a particular domain and return to it later on. The solution to this is the principle we talked about, create knowledge. This knowledge can exist in the form of documentation, it can exist in the form of a human being, but it can also exist subtly in the form of a design, which is simpler to comprehend, reducing this kind of waste and friction. I worked for a company I loved for a long time until I decided I needed to move on for growth reasons. I had an enormous amount of domain knowledge that I had worked hard to get into documents, videos, code comments, and most of all by transferring it to another developer before I left. I left and I came back at an hourly rate a couple of times to help the struggling developer out with what we’d covered. But after not too long, he threw up his hands and quit. Not long after that, the projects I’d worked so hard to document and transfer foundered and were cancelled. This is an appalling example of waste. What could we have done to prevent it? We could have recorded those handoff sessions. That would have been a pain frankly, but then a lot of the knowledge that wasn’t composed correctly in those documents and videos I created could have been captured. Secondly, we could have been more deliberate about cross‑training all along. A big part of this was a series of complex data imports that weren’t entirely automated. If we had a rule that each time we did it it had to be a different developer, we’d have been in much better shape with this. But above all, the company could have worked harder to hold on to both of us. These projects, net of my salary and some minor infrastructure costs, conservatively made the company a few $100,000 per year. They would have run for at least another 5 years. You do the math. The company was clearly not calculating the real cost of losing these two particular employees. It would have made sense to give either one of us a huge raise to stick around. Task switching. Okay, I’ve beat this drum in other courses, so I’ll just cover it briefly here. People grossly underestimate the cognitive cost of task switching, particularly for deep intellectual work. People think that they’re good multitaskers. They are not. No one is. We just don’t work that way period, full stop, no elaboration or qualification needed. The elaboration or yes, but to the statement humans cannot multitask is entirely composed of the reasons why we falsely believe that we can multitask. In short, the best scientific estimate is that the penalty is 40%. If you have two tasks that performed in serial take you an hour each, switching once in the middle will make the incomplete task take 40% longer. And that’s assuming that you only switch once. If you’ve been paying attention, you’re starting to get the sense that each of these wastes relates to the absence or underemployment of one of the principles. Delays happen primarily because authority is concentrated at the wrong level, an implication of respect to people. Delays can also happen because of siloed communication. You can’t just walked over to the DBA or pick up the phone and get a question answered. Delays can happen because a team failed to defer commitment and cannot now pivot to adjust to a change in circumstances. Defects. Above all, like we’ve talked about, defects derail your processes. And in a sense, defects are kind of all of these different kinds of wastes combined together. Finding a defect late in the process means the developer has to task switch from their new work, relearn what it was that they intended when they wrote it, and complete the partially done work that led to the defect. And that’s assuming that the developer who wrote it is available or even at the company anymore or even alive. If they’re not, we’re back to the handoff waste. It’s not quite true that you can have no waste when you have no defects. But defects are a sign that you’re not managing the other wastes.