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.


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 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


Thursday, October 31, 2019

Newsletter #35 : Energy Investment Model

Join Mailing List by clicking here

Interesting Articles

Catapult: The fun way of doing a retrospective

The Catapult activity is great for planning and preparing for an upcoming challenge. With a simple metaphor, this activity guides the participants to look at the challenge from three perspectives: the person facing the challenge, the challenge itself, and the organization people engage in to overcome the challenge.
Running the activity
  1. Draw the catapult, with the person flying and the mountain ahead.
  2. Ask the participants to write notes for each of the three areas
    • The catapult: notes related to the organization preparing people to overcome the challenge,
    • Person flying: notes related to the person facing the challenge
    • The mountain: the challenge itself.
  3. Conversation about the notes. Consider guiding the conversation by connecting related notes from the three areas.

Read the rest of the article here

"Energy Investment Model" for team building and employee engagement

Came across Energy Investment Model created by Don Tosti and Fred Nickols.  I am yet to use this model and have posted it on LinkedIn to hear more from others. Possibly, I will post the details if I hear anything interesting in the next post.

Employee engagement is hot and for good reason. The payoffs are significant. But we think there’s an aspect of employee engagement that has not received the attention it deserves; namely, that in terms of engagement, employees fall into four basic communities: Players, Spectators, Cynics and Deadwood.

Players. These are the people you want. They couple a positive attitude with high levels of effort. They are the ones who make things happen, who take the initiative and who see things through to the finish. They are both competent and caring about their work, their company and their co-workers. The primary task in relation to this community is retaining them as players.

Spectators. These are good souls; their heart is in the right place and so is their attitude. They, too, are competent and caring but they rarely take the initiative, choosing instead to expend minimal amounts of energy. The turnaround task here is getting them to release what are essentially large amounts of energy reserves.

Cynics. These are the folks who, except for their attitude, would be players. They have high energy levels and are usually competent but, for various reasons, have become disillusioned and cynical about the workplace in which they find themselves. Owing to their competence and high energy levels, they can be especially troublesome and problematic. Yet, if their attitude could be turned around, they could make significant contributions to the organization.

Deadwood. These people have the deadly combination of a bad attitude and low energy expenditures. They often do little more than take up space and occupy slots on the organization chart. Turning them around is the most difficult turnaround task of all because both attitude and energy expenditures must be raised.

Read the complete article here.

There are no best practices while solving complex challenges 
If you have attended one of my LeSS courses, we discuss about different types of problems and the ways to solve each type. Complex and complicated problems cannot be solved through best practices.

Most of the product development activities fall under complex and complicated and thus best practices are futile.

Here are some snippets about this topic from the book "Practices of Scaling Lean and Agile". 
In Managing the Design Factory, a similar point is made:
...the idea of best practices is a seductive but dangerous trap. ... The great danger in “best practices” is that the practice can get disconnected from its intent and its context and may acquire a ritual significance that is unrelated to its original purpose. [Reinertsen97]
Since so-called best practices are ‘best,’ they also inhibit a “challenge everything” culture and continuous improvement—a pillar of lean thinking. Why would people challenge ‘best’? Mary Poppendieck, co- author of Lean Software Development, reiterates this point and draws the historical connection from best practices to Taylorism:
Frederick Winslow Taylor wrote “The Principles of Scientific Management” in 1911. In it, he proposed that manufacturing should be broken down into very small steps, and then industrial engineers should determine the ‘one best way’ to do each step. This ushered in the era of mass production, with ‘experts’ telling workers the ‘one best way’ to do their jobs. The Toyota Production System is founded on the principles of the Scientific Method, instead of Scientific Management. The idea is that no matter how good a process is, it can always be improved and that the workers doing the job are the best people to figure out how to do it better... Moreover, even where a practice does apply, it can and should always be improved upon. 
There are no best practices—only adequate practices in context.


Upcoming LeSS courses and Events

Recently  Perth Certified LeSS Practitioner course has been announced.  The registrations have started.. and appreciate if you could spread the word around.

Date: October 21st, 22nd and 23rd.

City: Perth

Link to register:


A bit 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 

Join Mailing List by clicking here

Monday, February 25, 2019

Announcing the first LeSS course in Hyderabad

Happy to announce the first LeSS course in Hyderabad. 

Certified LeSS practitioner: From Principles to Practices.

Here is the link to register 

Date: March 15th, 16th and 17th 2019

Are we running backwards agilists ?

There has been some discussions in the Systems Thinking community about the dilution of ideas. I see similar challenges in the agile world as well. The market is changing so fast that the companies are always trying to catch up.
This is exactly where the agility is needed.
Creating a nimble(agile) organisation in this complex environment is challenging and needs thinking. However, thinking is hard and needs time and energy. Moreover, the senior leaders in the organisation have short turn around time to produce results. They want best practices to be given rather than sit and discuss various options. In this whole process, the agility that needs to be handled from the complex domain, would be treated like a simple problem by applying the best practices approach. In addition, celebrity endorsed methods, practices with quick fixes are embraced rather than building something that suits the purpose of the organisation. I personally feel that, the current state of agile implementation is akin to hamster running on wheel. We think that by constantly changing frameworks and methods, we are making a good progress. Everyone is running fast, exhausted but staying wherever we are.. even worst.. sometimes I ask myself are we running backwards ? :-)
What do you think ?

Feel free to join the Linkedin Discussion here

Thursday, February 21, 2019

System Kaizen over Point

One of the popular ways to "manage" queues in product development is to set up WIP (Work In Progress) limits and it has its benefits. However, we also need to be aware of the fact that, WIP limits are effective when it is done keeping the overall systemic improvement in context. If the organisation is siloed with a lot of interdependencies across the teams, then setting WIPs in individual siloed teams, could create unintended consequences, possibly creating a bigger queue somewhere else. System kaizen should be encouraged rather than the point and eliminating the queues is preferred than just managing it. We will be discussing some of these concepts during the upcoming LeSS course in Sydney on March 4th, 5th and 6th. Reach out to me for further details..

is Hierarchical organisational model bad ?

Most of us say that hierarchical organisations are bad and not suitable for product development/knowledge related work. At the same time, I have started believing that, it is not the hierarchy as such that is causing the havoc but it is the way the organisation is structured within the hierarchy. Product development environment is supposed to be collaborative and cross functional. When the org structure doesn't support the collaborative nature, it leads to sub-optimal results. One can still have a networked model structure or a holocratic structure, but if it doesn't support the collaboration and cross functionality, product development would fail. Question is.. is it the model(networked, hierarchical, etc) or the structure that is driving the behaviour the outcome ? Just to clarity, the structure includes the way the model is organised, HR policies, etc.

Certified LeSS Practitioner: From Principles to Practices Sydney 4th, 5th and 6th 2019

The registration for the upcoming LeSS course in Sydney has started... the early bird closes 24th Feb. Hurry as we have limited seats. Please find the course registration details below. Please reach out to me if you need further details

You can register for the course here

Tuesday, June 19, 2018

“Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process.”
“We’ve come to recognize that Kanban is giving permission in the market to create a tailored process optimized to a specific context.
Kanban is giving people permission to think for themselves. It is giving people permission to be different: different from the team across the floor, on the next floor, in the next building, and at a neighbouring firm.” – David Anderson
#kanban, #softwaredevelopment #projectmanagement