This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@lbmkrishna @genek putting your question and my answer here. I’m curious what others have to say. Attaching, below, the chapter from my book (#10) in which the learning to lead case is inserted. Very best, Steve How are you doing? With reference to your post on “Learning to Lead at Toyota” - I have few questions. Relating to Software Teams in typical enterprise, what is your take on - a) How many improvement that we could do in a day or week? b) How do you expect these improvements are supported by Leadership teams? c) How someone would measure these improvement impacts on the whole system? [5:26 PM] In manufacturing the variability of the changes well controlled, is n’t it? because it is clearly visible, we could see and witness. But in Software system, often some of our improvements are hidden or better word - blind spot. We do not understand to the effect that how one change in one area (code or configuration, policy) could impact other parts of the system. sorry to bother you with my question (may be very basic level), but curious to learn and understand Thank you
@lbmkrishna @genek Sorry for the delay in replying. Some thoughts below. Couple of key takeawys from the Bob Dallis experience on boarding at Toyota. 1: You need to observe the system to understand the system—e.g., the sitting and watching till the machine failed and then swarming all over it to figure out why. There must be a DevOps IT analog. 2: Disciplined problem solving vs. trial and error. Everything is framed in terms of examination, diagnosis, corrective action, prognosis, implementation and followup, from the smallest micro changes (e.g., in Japan for that three day wind sprints) to the longer cycle time and qualitative (e.g., the meeting pattern he had with Ken Fukanaga: Monday—establish current condition, develop action plan) from Monday to Friday (execute action plan) and Friday (debrief on action plan to see what Monday expectations were refuted. 3: Incrementalism of problem solving: rather than load several variables into the same change (eg, move the parts picture) isolate the variables to action-outcome feedback is quicker and clean (e.g., raise the fixture x inches, tilt the fixture y°, distance the fixture z inches, etc.). That, I think is agile applied into the physical world. If you think about these various tactics—try to get more observability, refutable hypothesis versus winging it, and incrementalism of fast feedback trials—it’s not obvious that anything Bob Dalllis did was limited to the physical environment. In fact, these tactics sound like good agile practice, and, the more ambiguous the system is, the more value these have in reducing ambiguity. Does that seem reasonable? Steve