4 ms·

I worked in automotive manufacturing at a tier 1 supplier. I think this is easier to read than the “Enriching Production” book: http://research.engr.oregonstat

• eesmith 6y ago
  That summary was much easier to understand, thanks! One of my complaints about "agile" is that it's nearly all-encompassing. If it isn't strict waterfall then it's agile, in one way or another, so "agile" becomes a pretty useless term. And I don't much like agile because many of the features seem to have the goal of (to re-use your apt language) removing craft from software development. I get the same feelings about what little I know of "lean". Everyone loves and claims to use it, one way or another. Which med me wonder about alternatives that aren't followed. So I was receptive when I came across mention of the Uddevalla approach. I would really like to have seen that approach developed and tested further.
  • stevegalla 6y ago
    You’re welcome! I don’t think there is such a thing as strict waterfall. Waterfall vs agile (or even spiral, or V shaped development) arguments don’t make much sense to me. IME, everything ends up being “iterative” in practice. Everything is a tool, use the tool that works for the given situation. I think principles are important and when evaluating different approaches it’s great to see what’s common to them. Even the paper[1] that is credited (or blamed) for “waterfall” advocated iteration. Maybe I was aware of agile before reading this and that caused me to interpret it differently? That’s possible, but there is mention of prototypes, looping back, and even involving the customer! I think it's better to think of it as the Toyota Production System (TPS) instead of lean. Lean comes from the MIT study of Japanese manufacturing where they specify 5 steps [2]. This is really the just-in-time pillar of TPS [see the "house" in 3] and there is a lot needed to be able to get there. TPS is an entire philosophy to run an organization. Everything from annual planning at the executive and leadership level all the way down to problem solving at the machine operator. The goal of TPS [shown across the roof of the "house" in 3] is “highest quality, lowest cost, and shortest lead time”. To me, the core of lean is about problem solving. This can follow anything from the Plan-Do-Check-Act cycle[4], OODA loops, six-sigma's DMAIC[4], Toyota's A3 method[5], and many others I am not aware of or am not including. The core of each of these is usually the scientific method. Again, these are all tools. Sometimes these are not needed, sometimes they are overkill, sometimes they are useful. Everything else in “lean” / TPS is either specific tools (e.g., 5-whys) used to identify problems or best practices (e.g., kanban, SMED) aimed at solving problems. To give you an example of how we focused on problem solving, we introduced a daily production meeting to a department at the manufacturing plant. The production meeting took 5-15 minutes at the beginning of the shift. The focus was on SQDCME (safety, quality, delivery, cost, morale, environment) metrics. The leads and production planners check-in more often to hit their production targets. After instituting the production meetings and starting to track data more closely, we taught the production team the 7 QC tools[4] along with the A3 problem solving process[5]. We had really good results using these basic tools to solve production problems. These production meetings were driven by numbers, as we had to hit daily targets. If we didn't hit production numbers, it becomes why didn't we hit them? If we are producing too much scrap, it becomes why is there too much scrap? The team is cross-trained on different processes and machines. Often we would grab some cardboard from the recycling bin put it up beside the production board and start going through the A3 process. We scraped 5 of part ABC, here are the physical pieces to inspect that we took from the scrap cage. The work order said it was scrapped at machine 123 in process X, what could have caused this? From there, we can quickly note down a bunch of the hypothesis generated by the group, then we can develop experiments to test these, again, these come from the group. After that we can develop ways to correct and prevent these issues from coming up again. This isn't about "management" telling what they thing the problem is, or how to perform the process. This is about finding a better way and continuing to improve the current knowledge. Good ideas can come from anyone. Without the ability to solve problems you're not able to start building the foundation of the Toyota house. The foundation refers to stability. This is often stability in the 4M's (that's the old literature): material, method, measurement, and person. How can you ensure stability if you can't solve problems, which is why I try to focus on that and build up the rest as needed. I'm not sure what you mean by craft of software development. I am currently working as a business analyst in a team that develops in-house business automation software. From what the developers have told me, craft is making nice interfaces, writing clean code, writing reliable and fast software, solving business problems, and making the user of the software happy. When requirements are always changing, or edge cases are not covered, that leads to changing architecture, throwing away code, or software that crashes and users say it doesn't work. To me, structure reduces some of those problems by focusing on the process of creating software. The process of moving from requirements, software architecture / design, development, testing, and deployment should be somewhat structured. My approach is not to design and document the entire software project before any code is written. I like to at least see, to the best knowledge at the time, the high-level of the project. Who will use it, what are the use cases, what systems do we need to interface with, where are the data sources, what are the outputs. This stuff needs to be documented and preferably reviewed with the team before development starts. From here, you're able to prioritize which use case has the most value, you're able to see what is risky, and what if it changes will cause lots of re-work. I can't count how many times I've seen people change their mind as soon as you show them some simple documentation, or say that's not what I meant, or start developing something to find out that they are solving 10% of the entire problem. Apparently there is a manifesto of software craftsmanship[6]. If that's what you're referring to, I think it aligns with what my coworkers have told me, and I think (hope) the structure I've outlined above helps to allow my coworkers to achieve that. [1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... [2] https://www.lean.org/WhoWeAre/LEINewsStory.cfm?NewsArticleId=17 https://www.lean.org/WhoWeAre/LEINewsStory.cfm?NewsArticleId... 1. Specify value 2. Map 3. Flow 4. Pull 5. Perfection [3] see page 5 for the Toyota Production System "House". This document is what I recommend when someone wants to learn about lean. http://artoflean.com/wp-content/uploads/2019/01/Basic_TPS_Handbook.pdf http://artoflean.com/wp-content/uploads/2019/01/Basic_TPS_Ha... [4] https://www.sv-jme.eu/?ns_articles_pdf=/ns_articles/files/ojs3/1589/submission/1589-1-1920-1-2-20171103.pdf&id=4956 https://www.sv-jme.eu/?ns_articles_pdf=/ns_articles/files/oj... [5] http://a3thinking.com/index.html http://a3thinking.com/index.html [6] http://manifesto.softwarecraftsmanship.org/ http://manifesto.softwarecraftsmanship.org/