8 Wastes of Lean (for Software Developers)
ฝัง
- เผยแพร่เมื่อ 6 มิ.ย. 2024
- Applying the 8 Wastes (mudas) of Lean Manufacturing to Software Development helps us understand how to produce more value ✨, with less waste 🗑️. Check out the books below:
🚀 geni.us/iP1SF (Lean Startup)
🚘 geni.us/mgAIH8G (Toyota Way)
🎯 geni.us/BXDX (The Goal)
CONTENTS
00:00 Intro
00:16 What is Lean?
01:15 Overproduction
02:17 Overprocessing
03:33 Defects
04:36 Inventory
06:52 Transportation
07:51 Motion
09:01 Waiting
10:01 Untapped Human Potential
10:43 Outro
![[Teaser EP.2] “MasterChef Junior Thailand Season 3” วันอาทิตย์ที่ 9 มิ.ย. นี้ 6 โมงเย็น ทางช่อง 7HD](http://i.ytimg.com/vi/KojBzrifbWg/mqdefault.jpg)
Chris has really been leveling up his drawing skills 👨🎨
LOL! You beat me to it!
I loved when you said we don't have to do too much upfront design. I can't agree more. It's good to plan and design, but too much details will avoid implementing things and delivering.
I think this MUDA concept will have very big acceptance in Serbia.
Hi Christopher, here's a thought you might be interested in. Back in the 80's, when lean was gaining traction, there was this notion of the "Software Factory" and trying to apply manufacturing techniques to software development. That didn't work out. But here's a twist that does. The factory doesn't produce software, it produces user-experiences, like buying something on Amazon, posting a review, etc. The factory is fully automated; software developers aren't the machines that make products. Rather they are the folks who build and maintain the factory. The lessons from TPM (Total Productive Maintenance) are then the ones that apply. Also from the Toyota tradition. The five S's derives from that for example :) Love your content btw! :)
You guessed right 😊 I absolutely found that very interesting! Thank you for sharing. Will dig deeper into this 😊 Thank you 🙏
My good lord man you’re the bestest
A key point often missed in these principles is the "over" in over-architecting. (And in over abstracting)
We certainly need a vision and architecture to work towards. Or the result is that infamous ball-of-mud. And we certainly need abstraction. But always "just enough". Hitting that sweet spot takes years of experience and countless failures. And even then, something of a crystal ball to predict what abstractions and architectures will prove over engineered and which ones will prove to be life-savers. In years.
Thanks for sharing your time and knowledge,
I feel very relevant to the context switch scenario. I find that good architecture really helps in this situation because you can write code in isolated domains.
Awesome video! So many of these principles ring true!
Thanks for taking time to create inspiring videos
Thank you 🙏😊
Great content, thanks Christopher!
I like this a lot! For me it's not only about what can you do to keep our startup lean. It's also a list of dilemmas (ex.: producing well structured code vs fast introduction of feature, working on all the requested features vs introducing features... ), that impact different departments (business, developers, testing, etc) of company that produces software. Most of the time the separate sections are focused on their own goals, and hard to convince that something should be executed in a to them sub-optimal way. If you manage to explain the tradeoffs of these dilemmas, it's more likely to find a middle-ground, thus having a better work environment, that eventually yields maintainable level of production. So yea, this is one of those lists to keep in mind :)
Beautiful and practical.
man ==> u are amazing , keep the good work up.
i see all of them honestly, and the worst is the inventory one.
That was a beautiful video.
Great perspective
Great video.
I think that the main issue is the gap which exists between product and development. Product gas huge dreams while development lower their expectations to reality.
Btw, good job on the drownings 😊
Living Legend
That was hell of an entrance at the beginning :))
Swoosh 😊
The man's a dynamo!
Amazing
Lean waste can be a real MudaFaka
makes sense makes sense
In my professional life, I have seen them all. Mainly because I worked in manufacturing for a bit over 11 years. But I have DEFINITELY seen it in software as well in the approximately 19 years I have been on this field. They are all annoying and wasteful. BUT, the one that grind my gears the most is context switching. This is the one that is most recognized by management as a real issue. In every organization I have worked in, I have brought this issue up and it mainly falls in deaf ears or is recognized but then management shrug their shoulders stating that is a necessary evil.
To managers and execs that might be reading this, if your employees look for ways to get out of meetings, or hide to avoid being pulled into them, then perhaps your meeting is not needed OR the scope of the meeting needs to be narrowed a bit. Not all those fifty people you invited are really needed. Give it some thought...
I disagree with over architecting argument of lean. What this leads to is a never ending saga of expensive reworks, forced contract renewals, and takes off the responsibility from leaders to think things through or be accountable for decisions. Having a vision is a quality and it needs support from implementors. Last time when they said just enough documentation, 90% of implementors stopped documentation. That's how things work. In my 20 years of experience, I have repeatedly seen projects spending billions because they never had a tunnel vision. If someone had it, the implementors screw up and the vision is lost midway because of buggy and inefficient implementations which is a result of hundreds of short sighted features implemented as patches. Inshort what lean promotes is short sightness in order to show quicker deliveries. This is a fraud idea.
Any successful product or business is built on a well architected framework. You can apply lean principles to architecture if that framework is already in place. Otherwise you are doomed. You project will never be over and you will keep paying the vendors year after up in a year caught build - demolish - build cycle.
Thank you very much for sharing your detailed perspective 😊🙏 I don’t actually think we are disagreeing. Spontaneously I agree with you on all accounts. It seems to me that most of the time I actually find myself on your side of the argument 😊 I am usually the one arguing that it’s very important to find sensible abstractions. Nevertheless, I think it is important to recognize that overarchitecting is a real thing and that opportunity costs can wreck us. Especially small companies and startups. See what I mean? I think it’s an incredibly difficult balance to strike. Thanks again for sharing! 😊🙏
@ChristopherOkhravi Yes, it's useful for startups. Thanks for your reply. I didn't mean to argue. Sorry 🙏 if the comment sounds argumentative.
@@zfold4702 No worries at all. I appreciate the alternative perspective and can see how it would have been valuable for me to be more nuanced in the video 😊
In contrast to other industries, Software relies more than thought on social and psychological conditions of people who create Software.
Yes, you get better gear and tools by the time. That is easy: just order.
Gathering software people to an idea or a customer’s vision is far more difficult.
Then - as aspect of no wasting talents - responsibilities are not well shared in both extremes: you find yourself with too much or too little: by too little I don’t mean nothing to do, but doing only one thing the whole day, and after finishing a task you give back responsibility to someone else.
We need more please
The video just came out, give him a break! Lol
😆
Brilliant. Now how do you put it in a language that product people speak? 🙃
I love lean
"Customers don't care about how beautiful the abstractions are" - I would love if you can do a video on this please. Ie how to navigate this trade off practically, how to decide if certain code is worth rewriting or not? Is it OK to release teriible code to a customer if it works? Are there any heuristics you recommend?
Thank you for the very interesting question. I need to ponder this a bit but I think you are spot on with this question. Thanks. 😊🙏
😎
Does everything have to be about efficiency, though? Barrelling forward to squeeze out every last drop of perceived value without ever stopping to reflect and never having any margins built into the system for when there is real, unforeseen crisis leads to failure and burnout. Not all short-term supposed value creation is actually meaningful or sustainable in the long run, is it?
It's very frustrating that these proven engineering practices still have to be argued for on a weekly basis. I did it today.
Just curious -- do you apply Lean principles for production of these videos? :D
Sensible question. I try to streamline as much as possible. Generally, in life, I try to embrace minimalism. Simple tools and simple solutions. Focus on delivering value with as few distractions as possible. I try to always remind myself that technology is a means to an end and never an end in itself. It's very easy to get stuck trying to optimize. But I'm trying to operate based on the idea that 80% of the results come from 20% of the work. So most details don't matter. Whether I succeed in this or not is a different matter😊. Thank you for the question and for watching 😊
Is it bad if I have seen every single one of these at my job?
Unless you’re the only one in a software department taking care of those wisdoms, it’s almost impossible to change mindset and process related issues in your company.
Of course from a „head quarter“ lead principal you get many announcements for improvements.
Managers are good in making announcements of change but poor to deliver the success of the change.
Ah! Thanks! ❤ Another video, another reminder to move my lazy ass😂
labour reductions = TOTAL PLUS.
Miscommunication leads to wasting time on doing wrong thing and delivering less value
I bet author of books "How to be great/productive/positive/bla bla bla" can write about anything - even about how to poop properly
I am happy to report that I indeed own a book that also discusses how to poop properly 😁😁
I have never seen any waste in my professional or personal life.
😊😊😊
@@ChristopherOkhravi excellent channel btw! Since the new format I watch every single episode.
So, my ex company might have not failed first item on this list, no wonder everything looked like pooop.
MUDA on serbian language (slang) means BALLS
Oh no 🫢
And other balkan colloquial languages 🇷🇸 🇭🇷 🇸🇮 🇲🇪 🇲🇰 🇧🇦 😂
mudak
I think it's absurd people are not machines for example while waiting humans can think and reflect. Software is all about humans. Whether end users or developers. Software creates the lean for automotive industry based on need created by thinking and reflecting, you cannot bring back lean to Software
Very interesting perspective! Thank you for sharing. I suppose there is a balance to strike. One way to think about this is: why do people read books on productivity? Because many of us would like to be able to move faster. I think of this application of Lean Manufacturing to software in sort of the same way. Either way, I completely agree with you. We should not strive towards turning humans into machines. That would be sad. Thanks again 😊🙏
I think scope is important to the concept of lean. My understanding from this video (not having known much about lean before this) is that lean is not designed for individuals, but for organizations. People are not necessarily inefficient or wasteful by nature, but the difficulty is in coordinating the actions of a group of people to avoid these wastes. These 8 areas that are the primary sources of inefficiency and thus deserve more attention.
While it might be the case that an individual can stay productive within an inefficient organization, perhaps that individual can be *even more* meaningfully productive within a smoothly-operated organization.
@@mistral___ Makes sense. But I do think that we definitely can use these 8 wastes as a way to structure our thoughts around how to increase our productivity as individuals. Assuming that we want to increase our productivity 😊😊
Waiting other, is the most wasting our time
I hate Agile, Lean and everything between or after or before that
😊😊
"Muda" in Serbian means "balls" 😬
😎