8 Wastes of Lean (for Software Developers) 

Chris has really been leveling up his drawing skills 👨‍🎨

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.

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! :)

I think this MUDA concept will have very big acceptance in Serbia.

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...

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.

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 :)

man ==> u are amazing , keep the good work up. i see all of them honestly, and the worst is the inventory one.

Thanks for taking time to create inspiring videos

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!

Great content, thanks Christopher!

Beautiful and practical.

That was hell of an entrance at the beginning :))

Lean waste can be a real MudaFaka

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 😊

Great perspective

That was a beautiful video.

Great video.

Amazing

Living Legend

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.

makes sense makes sense

Brilliant. Now how do you put it in a language that product people speak? 🙃

We need more please

I love lean

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.

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?

"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?

Is it bad if I have seen every single one of these at my job?

😎

Just curious -- do you apply Lean principles for production of these videos? :D

labour reductions = TOTAL PLUS.

Ah! Thanks! ❤ Another video, another reminder to move my lazy ass😂

It's very frustrating that these proven engineering practices still have to be argued for on a weekly basis. I did it today.

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.

I have never seen any waste in my professional or personal life.

Miscommunication leads to wasting time on doing wrong thing and delivering less value

MUDA on serbian language (slang) means BALLS

mudak

I bet author of books "How to be great/productive/positive/bla bla bla" can write about anything - even about how to poop properly

So, my ex company might have not failed first item on this list, no wonder everything looked like pooop.

Waiting other, is the most wasting our time

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

I hate Agile, Lean and everything between or after or before that

"Muda" in Serbian means "balls" 😬

😎