Pages

Tuesday, February 04, 2020

Newsletter #43 : Taiichi Ohno and the Chalk Circle

Interesting Articles

Taiichi Ohno and the Chalk Circle

In “The Toyota Way ” and “The Toyota Way Fieldbook” Jeffry Liker describes “standing in the chalk circle.”

This, of course, is a reference to a legendary exercise where Taiichi Ohno would stand a manager in a chalk circle drawn on the shop floor. His direction would be simple: “Watch.”

Several hours later, Ohno would return and ask “What do you see?”

Usually, Ohno had spotted something earlier and wanted the manager to learn to see it. So if the reply to “What do you see?” was something other than what Ohno had already seen, his response would be “Watch some more.”

This would continue until the manager saw the same problem Ohno had seen.

Sources:
http://theleanthinker.com/2007/07/09/the-chalk-circle/

https://www.allaboutlean.com/chalk-circle/



Just-in-time:  The Story, the misconceptions and the real story 


How was it born?
This was slightly more than ten years after World War II, and Japan was still struggling to develop from the depth of post-war poverty. During that time, Japan regularly sent their managers and engineers to the United States to learn whatever they could from American manufacturers. The CEO of Toyota Motor Corporation, Kiichiro Toyoda, had travelled to America to tour around the Ford’s factory before the war, and was especially eager to learn from the American automotive industry. He returned to Japan with an understanding of conveyor-fed lines, a key element to Ford’s mass production system. He intended to implement the new technology on his own automobile factories.
However, Toyota faced some challenging obstacles. Factories in Japan had less floor space than American counterparts, so he could not simply copy Ford’s layouts. Another problem was the supply of raw materials. Although the entire world suffered from the Great Depression of the 1930s, Japan was far worse off than the United States.
Kiichiro therefore adapted Ford’s methods of supplying the manufacturing lines. Rather than stockpiling huge quantities of materials, Toyoda provided each manufacturing process with small amounts, often saying just ahead of the production schedule. The practice of providing small, frequently replenished quantities to a factory process is the predecessor of “Just-in-time-manufacturing”.

However,  JIT will not work, if there are no materials available as and when needed.  This is where the Kanban system was developed to address the issues that could cripple JIT.

However, Various companies  somehow termed  JIT  into Zero Inventory system(ZIPS)

Robert Hall, one of the first American Authors popularising ZIPS was not intended to say that you can run a production system by zero inventories.  Neither Ohno mentioned it as well.   The intent was more to encourage people for continuous improvement.


Ohno clearly articulated that
Kanban is a tool for realizing just-in-time. For this tool to work fairly well, the production process must be managed to flow as much as possible. This is really the basic condition. Other important conditions are leveling production as much as possible and always working in accordance with standard work methods.

Trying to do Kanban without any context of JIT or the continuous improvement is as good as doing any random things with a Japanese name.




Local Optimisation problems 
“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of local optimization—when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently believes they are making the best decision, but because ‘best’ is a local optimization, in fact, it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common organizational learning disorders.
In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—global optimization. Try to consider decisions in light of this goal. To develop and “optimize the whole” culture, challenge all decisions and policies with the question:
Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?
In Scrum, the Product Owner is responsible for choosing high-value goals that could lead to potentially shippable product (at the end of the iteration) and that maximize return on investment and delight the customer, while maintaining a sustainable pace and high engineering quality. That explicit Scrum goal is meant to orient the system toward global rather than local optimization.



Speaking at Scrum Australia 2020 about the LeSS ideas that confront organisations

Looks like I have been selected to be one of the speakers for the Scrum Australia 2020 conference.

Here is the gist of my thinking for the conference:

Large-Scale Scrum is based on several thought-provoking concepts and ideas, that challenge the existing organisational status quo. However, these challenges sometimes are met with resistance from organisations, who resist adopting the ideas from LeSS. During this session, you will learn various ideas suggested by LeSS, and why organisations resist them.
During the last several years of coaching and consulting, Venky realised several ideas from LeSS inherently challenged the status quo of current organisational design and thinking. During this talk, he would like to share his interesting findings.
Some ideas that he found profoundly challenging the current system include:
1. Owning vs Renting the idea
2. Systems Thinking over linear thinking
3. Product Definition vs projects/programs
4. Managers as teachers vs Traditional management thinking
5. Role of a PO in connecting the teams with customers
6. Decentralised coordination techniques  vs centralised meetings

Let me know if I need to cover any other ideas under this title.


LeSS : Feature Teams
Feature teams are not a new or ‘agile’ idea; they have been applied to large software development for decades. They are a refinement of cross-functional teams, a well-researched proven practice to speed and improve development. The term and practise was popularized at Microsoft in the 1980s and discussed in Microsoft Secrets [CS95]. Jim McCarthy [McCarthy95], the former development lead of Visual C++, described feature teams:
Feature teams are about empowerment, accountability, identity, consensus and balance...
Empowerment—While it would be difficult to entrust one functional group or a single functional hierarchy, such as Development, for instance, with virtually absolute control over a particular technology area, it’s a good idea to do that with a balanced multi-disciplinary team. The frontline experts are the people who know more than anyone else about their area, and it seems dumb not to find a way to let them have control over their area.
Accountability—... If a balanced group of people are mutually accountable for all the aspects of design, development, debug- ging, QA, shipping, and so on, they will devise ways to share critical observations with one another. Because they are accountable, if they perceive it, they own it. They must pass the perception to the rest of the team.
Identity—... With cross-functional feature teams, individuals gradually begin to identify with a part of the product rather than with a narrow specialized skill.
Consensus—Consensus is the atmosphere of a feature team. Since the point of identification is the feature rather than the function, and since the accountability for the feature is mutual, a certain degree of openness is safe, even necessary. I have observed teams reorganizing themselves, creating visions, reallocating resources, changing schedules, all without sticky conflict.
Balance—Balance on a feature team is about diverse skill sets, diverse assignments, and diverse points of view.

A common misunderstanding is that each feature team member must know everything about the code base, or be a generalist. Not so. Rather, the team is composed of specialists in various software component areas and disciplines (such as database or testing). Only collectively do they have—or can learn—sufficient knowledge to complete an end-to-end customer feature. Through close collaboration, they coordinate all feature tasks, while also—an important point— learning new skills from each other, and from extra-team experts. In this way, the members are generalizing specialists, a theme in agile methods [KS93, Ambler03], and we reduce the waste of underutilized people (working only in one narrow speciality), a theme in lean thinking. 



If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here



Upcoming Events

Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries.


Many might not know that I also offer Certified LeSS Executive trainingThis is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture. 


Please reach out:  venky at agileworld.com.au for further details.


No comments: