Reddit reviews Toyota Production System: Beyond Large-Scale Production

TPS predates Six Sigma and Lean Production. Lean actually came out of TPS. As they show in the video, Lean can be applied to pretty much any process. Toyota uses it for manufacturing, here they apply it in a food bank, and it is also widely used in software development.

Notice how they apply Value Stream Mapping. They start by looking at what is happening, and listing all the steps that add value, and those that do not. Putting food in a box adds value, running around to get the stuff does not add value and is waste. By eliminating waste they can reduce the takt time from 3 minutes to 11 seconds.

Another important aspect of TPS is respect for people. In its entire history, Toyota has never laid off any (salaried) workers during hard times. Instead it uses the free time to invest in kaizen.

In this case, respect for people means giving back to the American people, because the USA helped rebuild Japan after WW2.


If you want to learn more about TPS, go read Toyota Production System: Beyond Large Scale Production, written by Taiichi Ohno, the father of the Toyota Production System.

I can also recommend The Toyota Way and The Toyota Way To Lean Leadership. These are a bit more recent and an excellent insight in the Toyota way of working.

Time to immerse yourself in the world of Lean manufacturing and production. Good reading includes The Goal, and Taiichi Ohno on how Toyota learned to really manufacture efficiently, and anything written by Shingeo Shingo. Don't think "manufacturing" reduces quality, in fact if anything modern manufacturing concepts increase quality while reducing waste, and are optimal for small scale production such as roasting.

https://www.amazon.co.uk/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143

>Problems arising in development for which we have trouble finding or creating a good solution. This may take a few extra hours but in some cases it has taken days to figure some things out, and this is time that is 'unaccounted for' because these tasks have specific hours/points assigned to them.

This is an issue with planning. Things can and do happen, but if they are happening frequently you have an issue with planning.

One thing you can try to do is assign a 'champion' to each ticket during the first discussion. (backlog grooming usually) The champion is responsible for gathering all the needed information and essentially the go-to person for understanding what needs to be completed and all of the dependencies. This person should also work with product to break an epic or story into the appropriate scope and subtasks. If a problem does arise, this is the person responsible for working with relevant stake holders to come up with a potential solution to take to the group.

>Time spent going back and fixing previously-completed components when new components break them. Our app is comprised of many components that work off of each other and sometimes changes to one either break another one or require some further changes to other ones to prevent breakage.

This is another planning issue. if you have to frequently go back and fix stuff that was completed then you didn't accurately capture the dependencies. (or someone else released something without checking your dependencies. still an issue with planning, just maybe not yours)

This is harder to fix. a champion can alleviate this to a degree, but it depends on the nature of the dependency. either way, not enough communication is going on.

>From the UI side, going back and fixing/updating/improving components that were functionally in a completed state. This one doesn't take up much time, but it is still not 'tasked' time.

Then task it. you should be capturing as much of your work on paper as possible.

if UI is outside of your team, it should be accounted for as a dependency the team is responsible for.

Again, not enough communication is going on. UI people should be part of your planning and you should be accounting for this time.

>The biggest problem comes when we have to make changes to multiple components simultaneously because they share functionality or work together, and this appears to cause a delay because 'neither of them are being completed on schedule'.

guess what I'm going to say. :p

sounds like you need to work with your SM to re-establish communication chains. they aren't there.

>We are all talented developers and we know what we are doing, but the seemingly 'results-driven' approach of SCRUM is not making a lot of sense to us right now, and morale is low.

your SM doesn't know what he's doing, sadly. Sounds like a converted PM that hasn't crested the learning curve yet. It sucks that Morale is low. You can do things to help him out and keep morale high. unfortunately this also depends on his willingness to accept the fact he doesn't know what he's doing.

You should really sit down with your SM and talk to him about this. It's his job to remove impediments. low morale is an impediment. how do your retro's go?

One of my favorite stories to tell, is one of the first retro's I was observing. (normally only the team should be present, but we made an exception for training purposes. I was there to observe, not to add) The company I was at was in the middle of a transition to Agile. They weren't prepared to hire dedicated SMs, so we were training within and having volunteers be SMs on teams temporarily.

Anyway, during the course of the retro, the team talked about how the current SM was not meshing well with the team, and wasn't really embodying Agile/Scrum as everyone else understood it. They decided in the Retro that the SM wasn't right for the team, and they needed a new one. So that's what they did, switched SMs right in the middle of the retro.

>Sometimes unexpected and time-consuming shit happens, and tasks cannot be completed 100% in one sitting. It just doesn't make sense to me. Can someone please explain how to handle these scenarios?

This largely depends on the group and the environment. if things are changing as frequently as you say, and they always will, then you should explore other models than Scrum. Specifically lean/kanban is better suited to volatile environments.

Within Scrum, when an event occurs that drastically changes the scope of a sprint you're supposed to bust the sprint. This is, by design, a painful process. you should immediately go into retrospective. talk about what went wrong. go into planning and re-establish baseline. figure out what the team can get done with this new information and restart the iteration.

Again, this is painful by design because it is a last resort. if these events happen frequently, then there's something else going on that needs to be addressed and talked about. mostly because you lose two days every time you bust a sprint. it paints a giant target on you that screams 'we didn't have our crap together. so now we have to go back and get our crap together' and no-one likes that. This is the main mechanism used to 'force' a team to fix their problems. granted, most SMs and most companies don't bust sprints even when things are going very poorly. but this is what scrum has in place for what you described. (so start doing it.)

In reality, Scrum tries to prevent these scenarios by enforcing better habits around planning and commitments. if you're new to scrum, or don't understand it yet, this can be extremely chaotic as Scrum assumes you have certain things already worked out. Scrum training generally does a woefully inadequate job of explaining this. the point is to highlight your main problem areas so you can fix them.

It's doing that very well. you've identified your time sinks. have some problems. Scrum's job is done. now it's your turn. talk about the issues as a team and figure out a solution based on the context of your environment (team/project/company/organization).

-------------

Recommended reading:

Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509

Crucial Conversations: https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/0071771328/

Lean from the Trenches: https://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

When you're ready for something more advanced:

Tribal Leadership: https://www.amazon.com/Tribal-Leadership-Leveraging-Thriving-Organization/dp/0061251321/

Toyota Production System: https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143/

Lean Software Development: https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/

Note: This last book is 'advanced' mostly because of price. It's worth it.

This book is pretty good. Very direct, compact, written by the guy who implemented lean production at Toyota https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143/ref=sr_1_13?ie=UTF8&qid=1542149684&sr=8-13&keywords=toyota+manufacturing