Sunday, March 15, 2020

Newsletter #45 : Role of a Scrum Master in LeSS


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:

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

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?

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.


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.


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 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 for further details.

Sunday, March 01, 2020

Newsletter #44: Lean, Systems Thinking and Other articles

Interesting Articles

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:

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.


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