Newsletter on Product Development, Agile, Innovation and Large-Scale Scrum.

Blog | LinkedIn | Twitter 
Welcome to newsletter 47.  

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.

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



Large-Scale Scrum(LeSS)
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.

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 or check this link

Many might not know that I also offer Certified LeSS Executive training. This 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 for further details.

About Empirical Coach

If you are interested in Agile coaching, mentoring and training services, please reach out to me ( 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 

This email was sent to <<Email Address>>
why did I get this?    unsubscribe from this list    update subscription preferences
The Empirical Coach Pty Ltd · High Street Road · Glen Waverley, VIC 3150 · Australia

Email Marketing Powered by Mailchimp