Pages

Sunday, May 17, 2020

Newsletter #47: Toyota Production System: An emergent system


Read this complete newsletter here


Interesting Articles
 
Toyota Production System: An emergent system

Recently, a short post on LinkedIn about Toyota Production System attracted netizens attention. Here is the actual post

During the earlier days, neither Taiichi Ohno or Shigeo Shingo or for that matter, anyone in Toyota had a vision of Toyota Production System.

As and when they came across challenges, they addressed by applying a set of rules and principles to create a flow and continuously improve.

More importantly, Taaichi Ohno focused on changing the underlying thinking of employees rather than purely building the product. This aspect of building employee's thinking seems to be the key differentiator between Ohno and Honda.

When you look around in organisations, there is more focus on processes, frameworks rather than actually uplifting employees ability to think.



Thought would elaborate this a bit more for the readers of this newsletter.   Fundamentally, the Toyota Production System (TPS) was not a designed system. It was an emergent system.  Neither Ohno nor other leaders at Toyota sat in an Air-conditioned room and drew it on the whiteboard.  Various tools and techniques emerged while trying to solve the problem. It is not the tools that are important, but the thinking that leads to the creation of the tools.

Even though the lean house distils into 2 pillars, respect for people and the continuous improvement, I still believe this is in retrospect.  Personally, I believe that Ohno and others were keenly focused on being at the "Gemba", ensuring that the value is delivered to the customers, teaching the employees to think rather than a specialist knowing everything, respecting the people by helping them on the ground rather than reviewing the reports.

Toyota faced several challenges both good and bad. The second world war pretty much gutted them. The survival made them to come up with practices to find a way to be productive with limited resources. The Korean war, created a good problem as they had more orders. They decided to be productive without hiring more people. The constraints of the war and economies of scale enabled the leaders in the organisation to be innovative.

I don't know if people know this, Toyota in-fact used to have a month-long batch cycle. Leaders called out the in-efficiency associated with the accumulated inventories and the variable queues. So, during each stage and in every different factory, the ideas emerged. It is the culture and the thinking that encouraged the people to think independently lead to the birth of the TPS. This was an emergent idea rather than a designed idea.

The introduction of the ideas was incremental rather than big-bang. The kanban system started only in a small group and within one assembly line. When it worked well, then it was introduced to others as they had dependencies as part of the manufacturing. 

Coming back to the modern world, in the 21st century, most of the western world has no dearth for money nor any constraints. This is not giving enough challenge for the organisations to make employees think.  If they want something, they buy a tool or a process or a framework in the market. As long as the organisations don't enable people to think, there will never be another Toyota Production System.


Further reading: The dagger and gift: Impact of Korean war on Japan

The origin of Lean Production
 

 
Interesting article: Why Managers Holding People Accountable Is A Waste Of Time, And What To Do Instead 

Link to the original article

Key snippets from the above article

How often do you hear yourself or someone else complain that this person or that person isn’t “being held accountable?” Or find yourself mustering up the gumption to “hold that person accountable?” It’s really a fool’s errand. At the end of the day, personal accountability is the only real accountability. So that means you can’t really hold other people accountable.

Own your role as a manager. When you take on the role and responsibility of being a manager of others, you have to own what happens on your watch. When a manager points the finger at their employees, they instantly lose credibility with their leadership and their team.

Help people face the reality of the outcomes they are producing. Instead of trying to hold employees accountable, focus on helping them deal with the reality that they are creating. Avoid the lectures that start with a list of “shoulds.” You should do this and you should do that only makes the person feel nagged or lectured. It rarely leads to higher levels of accountability.

Make it safe to surface issues early and often. As a manager, it’s critical to make sure people feel safe to discuss and learn from mistakes. Most issues get blown way out of proportion or are allowed to fester for so long the damage is irrevocable.

 

 
Interesting article: Transforming from Projects to Products

Link to the original article

Key snippets from the above article
 

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline, that we forgot to ask if what we are  doing is bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.
If you are considering an Agile Transformation it is likely that you have discovered that efforts to 'manage' projects are leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and 'lead' the way in product development.  Try to stop measuring output and to start measuring outcomes.
 

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


I have started online training for Certified LeSS Basics.   If you or your friends are keen, feel free to reach out to me or check this link


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.
 


About Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.


Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different.


I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.  

Blog | LinkedIn | Twitter 



Tuesday, May 05, 2020

Newsletter #46: Myth of Servant Leadership

Interesting Articles
 
Systems Thinking in the context of COVID
 
Everyone seems to be impacted due to COVID in someways or the other.  Whatever is happening around will have a deep and long-lasting impact on societies, technologies and the economy.

We could see many large companies struggling to survive and potentially could go bankrupt. At the same time, I am also hearing the government rescuing the economy in different ways. It is a piece of good news and a great gesture by the governments to jump in to save many drowning companies, it is also important to see if it is not "shifting the burden".

If you have read Senge's Fifth Discipline, you would have read about "Shifting the burden" Archetype. It usually begins with a problem symptom and someone attempts to rescue it.  This, in turn, gives an immediate relief however, it won't address the root cause of the problem. The problem stays hidden. The survivor is re-inforced with the belief that rescuer is always there to protect. This keeps weakening the system until it reaches point of no return.

Applicability in the typical product development scenario 

Here is a wonderful snippet from Senge

“Crisis heroism”: When a crisis (such as delays in a product launch) hits, the “crisis” manager is given enormous flexibility to “do whatever it takes” to get the product out. Ordinary roadblocks and formalities are swept aside. All this comprises the upper, symptom-correcting loop: the product is launched on time, and the crisis manager is touted as the hero of the day.

Meanwhile, several people have suggested the more fundamental solution of the bottom loop: redesigning the entire project management system, and rethinking the ordinary roadblocks and formalities. But this strategy would take longer, and less attention is given to it, so it has less effect on the problem symptom.”

“Most cases of “crisis heroism” include an addictive side effect: People see that if they want to be recognized for an accomplishment, they’ll have to be “heroes,” too. Gradually, the company becomes addicted to “heroically” creating crises at the expense of making fundamental long-term changes.”


Now coming back to the current COVID situation, if the government and the organisations jump into rescue everything without thinking through, they are just shifting the problem and creating an addictive behaviour which is harmful to the economy in the long run.


Further reading: https://blog.iseesystems.com/systems-thinking/shifting-the-burden/
 

 
Interesting article: Myth of Servant Leadership 

https://www.academia.edu/14264417/The_Myth_of_Servant_Leadership

Key snippets from the above article

Servant Leadership (S-L)

According to Larry Spears, a chief advocate of S-L who is responsible for marketing Greenleaf s ideas, the concept of S-L came to Greenleaf upon reading Hermann Hesse's short novel.  Journey to the East.

Hesse's story is an account of a mythical journey by a group of people on a spiritual quest where the recognition of the true leader of the group takes place as a result of his acts of service and self-sacrifice for the benefit of the whole group. As Spears tells it, upon reading this story, it seemed suddenly clear to Greenleaf that a great leader is first experienced as a servant to others, and this simple fact is central to his or her greatness . . . true leadership emerges from those whose primary motivation is a deep desire to help others(3).

Accordingly, for those who adopt its basic tenets, it means developing an overall attitude toward leadership that entails putting the needs of the company and employees first. It means seeing yourself foremost as a steward (Block) of the organization's mission and goals and then acting as a leader to help others coUaborativelyachieve those goals. Since its language explicitly promotes an approach to leadership that is essentially altruistic and idealistic, many proponents think it signals a turn toward the spiritual search in contemporary managerial practices 


The argument against S-L seems to be as follows:

The term servant connotes a subjugation of an existential subject that is dependent upon the presence of a master for his/her social location and organizational life. The term servant thus represents a state of submission, complete with various degrees of oppressive ramifications and power imbalances.

"To - serve" means to be self-sacrificing. The act of serving thus makes the organizational member subject to the whims and/or dictates of a higher order of discursive structures. To counteract this negative connotation of the term servant, Greenleaf paired it with the term leader, which entails and authorizes its opposite-the masterful position. The word servant thus inhibits whatever negative connotation leader evokes and conversely(Forward 145-165). From a semiotic point of view, the terms are mutually constraining, rhetorically. When organizational leaders attempt to implement this fluctuating logic within everyday organizational practices, it produces corresponding shifts in the discursive rules of the game 


Read rest of the newsletter here



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.


I have started online training for Certified LeSS Basics.   If you or your friends are keen, feel free to reach out to me.


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.
 


A bit about Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.


Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different.


I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.  

Blog | LinkedIn | Twitter 



Sunday, March 15, 2020

Newsletter #45 : Role of a Scrum Master in LeSS

Lean/TPS

Toyota Production System: Respect for People
 
As many might already aware, Toyota Production System was not a planned design. It was created in response to the need to survive the world war and to improve the profitability in a low demand environment.  The variable demand created a lot of waste due to unavailability of tools, skills and methods.

In the whole process of elimination of wastes, focus on quality lead to the discovery of ideas like JIT and in-turn kanban. However, Toyota also realised that without respect for people, things will fall apart.

So, if you are interested in applying the ideas from Toyota Production system, Kanban, WIP limits, etc form the tools part and their foundation lies in the respect for people.
As per the book "Scaling Lean and Agile Development" 

Broadly, the global or system goal of lean thinking at Toyota is to go from “concept to cash”  or “order to cash” as fast as possible at a sustainable pace— to quickly deliver things of value (to the customer and society) in shorter and shorter cycle times of all processes, while still achieving highest quality and morale levels. Toyota strives to reduce cycle times, but not through cutting corners, reducing quality, or at an unsustainable or unsafe pace; rather, by relentless continuous improvement, that requires a company culture of meaningful respect for people in which people feel they have the personal safety to challenge and change the status quo.

In the product development frameworks like Scrum, LeSS the respect for people is created through Servant leadership and Self-Management principles.

Continuous improvement and Respect for people are the two pillars of the Toyota house. Continuous improvement culture cannot survive without respecting the people. Respecting the people doesn't mean get along without causing any friction and not about following the orders. It is about treating people as whole and complete rather than a transactional relationship. Respect for people is to create an environment for people to use their complete mental ability to succeed, learn and grow.

My observation in organisations has been to use words like Kaizen(continuous improvement) but without any focus on respect for people.


Further reading: https://less.works/less/principles/lean-thinking.html
 

 
Interesting article: Why Net Promoter Score(NPS) is past it's prime 

https://www.strategy-business.com/blog/Why-Net-Promoter-Score-is-past-its-prime?gko=dc66a

Key snippets from the above article

The Net Promoter Score (NPS), which has long been used to measure the loyalty of firms’ customers, is under fire for becoming the false god of corporate America. In a searing article, the Wall Street Journal last week labeled NPS “a dubious metric” — one that is routinely cited by CEOs in earning calls and that somehow, magically, never declines.
There are at least three big reasons why.
1. NPS misses the employee connection. NPS says nothing about employee experience. What good is a figure that shows how many customers would recommend your company versus how many are unhappy if your employees — your prime ambassadors to customers — are unhappy themselves? If you’ve ever encountered a surly store associate or a hostile customer-service rep (and I know you have), you intuitively get the connection between customer experience (CX) and employee experience (EX).

2. NPS is obsolete because so much has changed. Since the introduction of NPS, customers’ expectations have soared and companies’ access to information about them has increased dramatically. Today, consumers expect next-day delivery of online purchases — with tracking and free returns. They use social media to publicize their favorite companies and brands, and excoriate those that deliver bad experiences.
3. NPS is a backward-looking “point in time” metric. Today, we have the tools to run dynamic, “living” metrics that spin up virtuous circles of benefits and keep them spinning.


Read the complete article here

 
Interesting article: Why great employees leave great cultures?

https://hbr.org/2018/05/why-great-employees-leave-great-cultures

Key snippets from the above article

Culture is often referred to as “the way things are done around here.” But to be useful, we need to get more specific than that. I’ve been working in HR for over twenty years, and the best companies I’ve worked with have recognized that there are three elements to a culture: behaviors, systems, and practices, all guided by an overarching set of values. A great culture is what you get when all three of these are aligned, and line up with the organization’s espoused values. When gaps start to appear, that’s when you start to see problems — and see great employees leave.
These gaps can take many forms. A company might espouse “work-life balance” but not offer paid parental leave or expect people to stay late consistently every night (a behaviors-system gap). You might espouse being a learning organization that develops people, but then not give people the time to actually take classes or learn on the job (system-behaviors gap). Maybe your company tells people to be consensus-builders, but promotes people who are solely authoritative decision makers (behavior-practices gap).
Gaps like these are never solved by turning culture over to a Chief Culture Officer or pulling together culture committees.
 
How, then, do we repair a flagging culture? A place to start is by reviewing the behaviors, systems, and practices in place in your company.

Behaviors

A common culture-building practice is the creation of value statements. But the real test is how leaders behave; how they enact these values, or don’t. People watch everything leaders do. If leaders are not exhibiting the behaviors that reflect the values, the values are meaningless.

Systems

Every process that is created, every system installed, every technology that is used, every structure that is designed, every job title that is given will reinforce or dilute the culture.
 

Practices

Practices include everything from company events, running meetings, feedback processes, to how decisions are made.
Do you have repeatable decision-making processes in place? Are meeting participants expected to be collaborative and consensus-driven, or is some conflict OK? What should managers talk about in performance reviews?
Practices need to change as the company changes — as it grows, reorganizes, or faces new threats. Once-useful practices can quickly become stale, meaningless, or even counter-productive. If the original intent of an off-site retreat was to help teams bond, what needs to shift now that the company has tripled in size?

Read the complete article here
 

 
Systems Thinking

A system is made of two or more parts. As we know a system is a continuum that is each system is hidden within a larger system and also, hides smaller systems. The idea of the system itself is based on our mental model. Most of the organisational system that we tend to address are made of both humans and technical interfaces.

Meadows and many thought leaders say the system is defined by the boundary we draw. However, the boundary is mostly a virtual boundary we draw to focus on a particular problem.  The boundary itself is challengeable as it is influenced by our mental model of the world.

When we tend to address the problems in the organisational systems, we tend to believe we know the answers or solutions. However, we forget that our solution is based on a certain mental model of the organisation.  Then the question is, how do you validate your mental models?  The best way is to expose it to the outside world and get it validated. This is where the culture of transparency and safety comes into the picture. I call this a foundation of everything at work. 
Our ability to achieve the results we truly desire is typically eroded when we hold thoughts and feelings that:
  • Our beliefs are the truth
  • The truth is obvious
  • Our beliefs are based on real data
  • The data we select are the real data
In my LeSS trainings, I use the Causal Loop modelling(Systems Modelling) as a way to expose the mental models of individuals to get it validated. Of course, there are various other tools that could be used.   It is important to ensure that models are exposed and shared with each other while making the decisions. In fact, many of the organisational visioning and discovery exercises are supposed to be the platform to share the mental models. However, these exercises fail miserably when there is no safety net and still run top-down.

Ladder of inference is another tool..

Below is excerpt from this wonderful article about mental models

The ladder of inference is a tool, first developed by Chris Argyris, that provides a structured way for us to reason as to why we don’t usually remember where our deepest attitudes or deep-seated behaviours came from.  These may include fear of the unknown or of something new.  Fear of trusting persons.  Fear of believing someone other than themselves would look out for their best interests.  The data is long lost to memory, after years of inferential leap.  Before long, we come to think of our longstanding assumptions as data, but we are several steps removed from data.

The Ladder of Inference describes the automatic thinking process that we all go through, usually without even realizing it, to get from a fact to a decision or action. The thinking stages can be seen as rungs on a ladder
Using the Ladder of Inference
You can’t live your life without adding meaning or drawing conclusions. It would be an inefficient, tedious way to live. But you can improve your communications through reflection, and by using the ladder of inference in three ways:
 Becoming more aware of your own thinking and reasoning (reflection);
 Making your thinking and reasoning more visible to others (advocacy);
 Inquiring into others’ thinking and reasoning (inquiry).


Fascinating quote 

We don’t see things as they are, we see them as we are. – Anais Nin
 

 
Large-Scale Scrum(LeSS)

Role of a Scrum Master in LeSS
 
Scrum Masters are responsible for a well-working LeSS adoption. Their focus is on the Teams, Product Owner, organization, and development practices. A Scrum Master doesn’t only focus on a team but also on the overall organizational system.
A Scrum Master is a dedicated full-time role. One Scrum Master can serve 1–3 teams.
The initial focus of a Scrum Master towards the team(s) is high, but it should decline over time. When the teams are formed, the Scrum Master spends a lot of effort educating and coaching the team(s) in self- management, inter-team coordination, and increased shared responsibility. Over time, the team(s) rely less on their Scrum Master as they take on all responsibility by themselves.
The maturing of teams is one reason many Scrum adoptions opt for part-time Scrum Masters. But in LeSS, the Scrum Master isn’t a part-time role. When the Scrum Master’s first Team has matured, then she may take up another team—in fact, up to three. Being a Scrum Master for multiple teams automatically shifts focus to the bigger picture of the organization and the Product Owner.
 
LeSS recommends the following five tools for Scrum Master
 
  • Question  As a Scrum Master, you act as a mirror to everyone to help them reflect and improve.
  • Educate  As a master of Scrum, you have a deep understanding of Scrum and need to help the team understand why Scrum is the way it is.
  • Facilitate  Show the teams how to do LeSS events, and have productive conversations by facilitating them.
  • Actively do nothing   You need to create space for people to take responsibility. 
  • Interrupt   Teams need to learn by themselves but when things do get out of hand, then you interrupt to avoid irrevocable damage.

Ref: Large-Scale Scrum

 
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.
 


Sunday, March 01, 2020

Newsletter #44: Lean, Systems Thinking and Other articles


Interesting Articles
 
Lean

Push or Pull: Origins and further details

If you have heard about Lean, you would have heard about the Pull system. Taiichi Ohno is considered as the father of the "Pull" system. The story goes, Ohno got influenced with the American Supermarkets, where the customer pulls the needs and in-turn signalling the order creation.

Since the kanban system was also originated at Toyota, and so, it became a synonym for the pull system. However, the concept of Pull system itself is much broader than kanban. Kanban system has it's own limitations.

The Pull system needs to be studied in a broader perspective.

Taking the original idea of a superstore, customers pulling the items from the aisles signals the procurement. This in-turn signals the production of the new items.  This signalling (kanban) mechanism, controls how many items need to be to released in the next batch. This control of production is nothing but the WIP limit.  WIP plays a crucial role in controlling the variability, thus increasing the predictability.

However, in the Push system, the products are manufactured out depending on the demands seen in the past. Accuracy of the prediction controls the manfucaturing.  Push system cannot handle the variability well unless a large buffer is kept aside or a system to improve the accuracy of predictability is created, which is challenging in a complex system.

Further reading: https://blog.trestlescs.com/what-is-pull-planning

https://edgeperspectives.typepad.com/edge_perspectives/2005/10/from_push_to_pu.html
 

T-shaped skills and one-piece flow

One-piece flow goal is achieved when the work flows like water from one end of the system until it's delivered.  In large organisations, one-piece flow is difficult but not impossible.  The major challenge in creating the flow is variability.  There are many reasons for variabilities, and one important reason is the individual capacity.

One of the ways, Toyota tackled this challenge the flow issue is by creating generalised specialists. If someone has obstacles, the others in the queue can step-in and help to remove the roadblock.  However, when this idea was introduced at Toyota, there was a d

At Toyota, when a new idea hits a roadblock, it is the leaders and managers, who will lead by example by joining the team. 

In most organisations, the lean initiatives fail as they copy only the tactical practices rather than the cultural aspects like leaders as teachers.
 

Systems Thinking

Systems Thinking and its uses

 
It is essential to understand the distinction between System and Systems Thinking. As per Meadows  A system* is an interconnected set of elements that is coherently organized in a way that achieves something. If you look at that definition closely for a minute, you can see that a system must consist of three kinds of things: elements, interconnections, and a function or purpose.

Based on the above definition, Systems Thinking is about understanding the elements, interconnectedness to achieve the purpose. If you want to call yourself as a Systems Thinker, probably this is the best place to start to focus while understanding the system.

In a complex system, it isn't straightforward to understand the elements and relatedness without being part of the system. This is one of the reasons that, a real systems thinker, is one who knows how to get the elements involved in deciphering the system (assuming we are dealing with socio-technical or social systems like organisations, societies, etc.) while solving the problems. 

How can Systems thinking help organisations:

1. It enables the people to focus on the interconnectedness and itself impact on the emergent behaviour
2. Any recurring problem is a symptom of a systemic problem that is hidden beneath the surface
3. Looking at long term cause-effect analysis and strategies 
4. Improving Collaboration increased shared language
5. Continuous improvement, respect for each other and being humble as there are no experts on a system
6. Avoid jumping into conclusions and getter deeper understanding of the unintended consequences 

When elements are not understood or identified, any improvement leads to local optimisation or unintended consequences. From the practical application point of view, when you are trying to solve a specific issue at work, one needs to consciously include the people who like the idea and who have differing opinions as well. 
 
Will try to write more and practical applications of Systems Thinking (ST) in the future newsletters...


You can read rest of the articles here and subscribe to my newsletter using this link




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.


Thursday, November 07, 2019

Individual outcome can be accountable and not the emergent behavior

Something that I am thinking about... In a predictable, closed system, nailing down the accountability of an agent is feasible. However, in a complex adaptive system, the outcome is due to the interaction of many agents. The individual agents are accountable for their own actions but not emergent behavior or outcome. Large organisations are complex systems, however, the processes and policies are created with an assumption of predictability and individual accountability which are tied to the outcome. When the individuals KPIs and salary are tied to the outcome of a system with complex emergent behavior, individuals start demanding more control so that the outcome can be predictable. This, in turn, creates more stress on the system.

Monday, November 04, 2019

Newsletter 37: Why Sprint 0 is a cardinal sin


 


Interesting Articles

Why using Sprint 0 is a cardinal sin for all Scrum Masters

A Scrum Master using Sprint 0 is just as strange as an astronaut believing the world is flat. Scrum Masters should know better!
Unfortunately, there still are many Scrum Masters who start their new teams with Sprint 0. In this article I will try to persuade you there is no convincing reason to use Sprint 0.
So let’s start by figuring out why Scrum Masters introduce the concept of Sprint 0 to their team.

What is Sprint 0?

There is no official definition of Sprint 0, as it is not part of Scrum.
 

Sprint 0 conflicts with the core of Scrum

Imagine you would strip Scrum of everything to reach the core of what Scrum is about. You would remove all the roles, events, artifacts and rules of Scrum to reduce it to its absolute essence.
Scrum boiled down to a single sentence for a software development context would be:
Deliver a working product every Sprint

Sprint 0 clashes with the Empiricism of Scrum

The foundation of Scrum is empiricism. Empiricism asserts that knowledge comes from experience and you should make decisions based on what is known. By doing you will learn more. You may use this learning to do better than you did before.
By starting with Sprint 0, you have no product increment to inspect at the end of the Sprint. Therefore, your team will not run into the challenges involved with doing a real Sprint.
Sprint 0 results in reduced transparency: you will not encounter the real obstacles involved with doing Scrum. This leads to worse inspection and less adaptation.

You can read the rest of the article here

 

 

Look at Capability, not Title.

Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team?
With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment.
This has unearthed strong opinions. Unfortunately, they don't converge on a single word or phrase.
A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create”  a “Done” increment.

Read the complete article here.
 


To read the rest of the articles and posts... You can subscribe to the newsletter here