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.
Agile Transformation should not be your objective
Agile Transformation is often presented as the objective, when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed.
- Are your customers dissatisfied?
- Are your products missing the mark?
- Do you(or your clients) feel you are not getting value for money?
- Are you slow to market?
If you are changing to Agile because you have heard it brings good results and so want to change your processes but are unwilling to change your culture, you will likely struggle.
If you continue to measure your teams the same way you always have then you will get the same behaviours and the same results - likely the ones you are trying to change.
How do you measure?
The level of Agility you can achieve is determined by the behaviours you choose to reward or punish
Most small companies start out pretty agile, they have to, just to survive, failure and learning, adapting, evolving and reflecting are essential. We often find that the successful start-ups will describe how learning more quickly about failures helped them, and how they are all working to a common goal. But as companies become more established they "grow-up" they organise and divide responsibilities and failure goes from being a good thing to a bad thing. Goals shift from being shared goals to individual department goals and lack traceability back to company goals.
The department has goals that they are measured against, the team has goals, individuals have goals. I am not saying goals are a bad thing, but goals that cannot be directly tied back to a common goal of the organisation are a bad thing, they create conflicting behaviour and activities that do not take you towards your goal very likely keep you from it.
Take a moment to think how often in your organisation you have needed something to help meet a company goal - deliver a product, or hire more staff, but you were dependent on another team or person, and that team couldn't or wouldn't help. IT support (sorry for picking on you) is often a good example, a simple firewall change to launch a product which takes weeks to be scheduled or new PC that doesn't show up until a week after a new hire started.
Read the complete article here
The Number of backlogs the ultimate lever
The link to the original article
Constraints from specialization
Why do we create many backlogs? We want specialization. Why do we create a backlog for each customer domain? We want specialization in the customer domain. Why do we create a backlog for each technical domain? We want specialization in the technical domain.
The more specialization, the more efficiency and the higher quality. It must be good, right? However, it becomes a constraint over time, and harms our agility. When this happens, is it our conscious decision? Most likely not, it is just based on our fast thinking. Instead, we should do more slow thinking here, so as to see the consequences.
Having everyone able to do everything is a sufficient, but not a necessary condition to enable one backlog for a team. Similarly, having every team able to work on any feature is a sufficient, but not a necessary condition to enable one backlog for a product. The key is, there should be no constraints when we say that people or teams have one backlog. When we can not adapt to maximize customer value, we are over-specialized.
How do we reduce the constraints? We learn, and we cross-learn. When we are less constrained by our specialization, we are more agile. Learning effectiveness should become our focus in order to reduce the number of backlogs and to achieve agility.
LeSS or less
How much specialization is over-specialization? It depends on our need. How much agility do we need? It depends on our capability. How much broad learning provides the right amount of challenge for our people?
LeSS provides a reference point for our consideration, which is for roughly 50 people, we want to strive for one product backlog with multiple feature teams. Feature team means that we do not create separate backlogs for each technical domain/component; while one product backlog means that we do not create separate backlogs for each customer domain.
What if this step is too big for us? Our first step could be to combine backlogs for two technical domains/components, or for two customer domains, therefore, have one less backlog. That is the minimum step we could take.
When we reduce the number of backlogs, we increase agility. Indeed, the number of backlogs is the ultimate lever.