What did I read today ? AntiFragile, Queuing theory, Learning Theories

I do most of my readings at home or on the train. Thought would write a short post about my reading habit.

While heading to work(today): I learnt about the "Learning Theories". @Edmund O'Shaughnessy had shared the following diagram. The author of this diagram Richard Millwood has taken a lot of effort in capturing the different learning disciplines and its applicability in various fields.

It is a great read to understand various sectors, disciplines and the techniques that could be applied to each area.

Somehow I didn't see Peter Senge's learning organisation and Systems Thinking.

While returning home: I saw this big queue during the rush hour in the Flinder's street. My mind wandered towards solving the issues around Queuing and applying Queuing theory.

It also reminded me of what Reinertsen says

• cycle time is a trailing indicator
• queue utilization is a leading indicator

It is a bit of shame that organisations focus more on measuring Cycle time ignoring the importance of Queues. It is too late by the time, you understand and analyse the Cycle time. Measuring and managing queues is a better risk management strategy. This is one of the key reasons LeSS has incorporated this as one of the 10 principles.

After reaching home: Generally, I pick up some random book to read. Today I was in a mood to read Nassim Taleb's Anti Fragile. 

Taleb refers to Maxwell's research that tightly controlling the speed of engines leads to instability.  Any system that is not used to instability or volatility for a longer duration becomes vulnerable to fluctuations in the longer run. 

To build a resilience organisations, one needs to inject a controlled instability or chaos into the system to learn the behavior. Such experiments are extremely crucial for organisations, such as financial corporations running under tight risk management. 

However, these are the same organisations, shying away from such experimentations run the risk of head-on collision when the Sh*t hits the fan.

Last but not least

My upcoming Sydney, Melbourne and Brisbane courses details are as below and you can buy the tickets using the links below: Feel free to reach out to me for group discounts or questions.

• March 26th-28th '18: Sydney: Certified LeSS Practitioner  From Principles to Practices
• April 23rd-25th '18: Melbourne: Certified LeSS Practitioner From Principles to Practices
• May 21st-23rd '18: Brisbane: Certified LeSS Practitioner From Principles to Practices

Do more with LeSS!

Join the LeSS Course now with the trainer Venkatesh (Venky) Krishnamurthy. Check the Course Schedules and click the link to register!

Sydney Course: March 26th - 28th 2018 

Melbourne Course: April 11th - 13th 2018

Brisbane Course: May 21st - 23rd 2018

What is missing in the Agile world ? Thinking in models, LeSS

Our Agile practitioners are pretty good with Scrum ceremonies, Kanban, WIP limits, Cycle times and even building the self-organizing teams. However, I feel that the important thing that is lacking from the vocabulary of agilists is "modeling."

You might be questioning, What's modeling? Why is it so important?

Remember, we live in a complex world. Every conversation, actions and interactions are producing new behaviors and consequences impacting the system at large.

Modeling enables us to organise this complex information in a meaningful manner for further analysis, brainstorming, and forecasting.

One must also remember that models are as good as the data at hand. That's why it is said that, 

"All models are wrong and some are useful".

There are researches which prove that people who model the system are better at making right choices and better decisions.

For example, consider a group which is keen to model the decision about hiring developers quickly(even though low skilled) to increase the feature velocity.  

Teams and leaders who can model the idea before implementing it can see that, in the longer run, this decision of hiring low skilled developers could work against the intended goal of increasing the velocity.

As seen in the systems model below, the low skilled developers could end up creating more defects in the long run and thus reducing the feature velocity.

Modeling decisions, ideas, and observations will enable the team to make conscious choices rather than being driven based on instincts or past experiences.  

Every day, the leaders, team members are making critical decisions without really modeling their impact on rest of the system. I feel that modeling skill is a crucial gap in the Agile world as of now.

This is one of the key reasons, why LeSS has embedded "Systems Thinking" as one of its principles and encouraged teams to Systems modeling during the retrospectives.

I spend quite a bit of effort teaching Systems modeling during my Certified LeSS Practitioner course. If you are keen to learn more about Large-Scale Scrum(LeSS) and modeling, you can register for my upcoming courses. The details about the Sydney, Melbourne and Brisbane courses are below:

• March 26th-28th '18: Sydney: Certified LeSS Practitioner  From Principles to Practices
• April 23rd-25th '18: Melbourne: Certified LeSS Practitioner From Principles to Practices
• May 21st-23rd '18: Brisbane: Certified LeSS Practitioner From Principles to Practices

Amazon spins a giant roulette wheel every week - But don't copy this

Today, I came across this article on Business Insider about Amazon introducing a new idea of spinning the wheel as part of managing their meeting scheduling chaos.

The spinning wheel seems to look like this

The first thing that came to mind while reading this article and looking at this wheel was OMG, the agile coaches, leaders from various organisations might copy this idea to manage their meetings. 

My suggestion, please don't copy this practice.

As agilists say "Every practice is context dependent."  The above idea from Amazon, seems to have taken birth as a need to make their leaders come prepared irrespective of the presenter.

Unless your company has the same meeting related challenge as at Amazon, don't copy blindly. 

Somehow in the agile world, it is a common practice to pick up ideas from popular publishing companies (HBR, BusinessInsider, InforQ, etc.) and implement the same.

I like experimentation, but copying because a popular company is doing it is a mere ignorance.

The most popular copied idea in the recent years has been the "Spotify model." The model, as far as I know, emerged as part of various experiments/ideas tried at Spotify.

Spotify has ingrained the culture of experimentation in their employees. I am not sure if they are still practicing the so called "Spotify model".

At one point, organisations copied the Google's 20% idea forcing employees to spend a day innovating. Even though Google abandoned this idea long back, it looks like it is still lingering around.

Many have attributed the innovations at Google to this 20% rule. However, according to Eric Schmidt, his plan was more towards changing the culture.

Group Vs team

I have seen many “Agile teams” working quietly without talking to their teammates. Every day they are at work sharp 9 AM, pick up a user story from the backlog, finish it and go.  Their interaction with other team members is limited. But each one is really happy as the are achieving something. This is where the line separating the “groups” and “teams gets blurred.

A team is a group of people who cannot work without depending on each other. That is, they have high interdependence on each other. However, a group need not have interdependence.  A good example of a group is a call center.  Typically in call centers, each attends the customer requests on their own and solves the problem. If one of the individual’s in the call center group is blocked with an issue, the rest are not affected. They could still continue working.

However, a team has shared the responsibility of delivery, and their work should be interdependent. In other words, team members have an agreed goal and the only way to achieve the goal is to work together. My thumb rule is, a user story cannot be moved to “Done” without the help of at least four other people :-)  

I believe that if your team room is very quiet you might want to check if there is anything wrong there. You should ask why teams are not talking to each other ? do they have shared responsibility of work ?  do they have a common goal to achieve or individual goals?  How many people do you need to complete an user story?

Photo courtesy: http://www.teams-forsuccess.com/working-groups-and-teams-are-they-the-same/

How to build resilient Scrum teams ?

Some time back I attended a session on raising resilient kids. I learnt that building resilience is all about building the ability to bounce back and learn from all kinds of adversity—including setbacks, threats, stress and trauma.   

Here are some notes from the session.

How to build resiliency in kids?

1. Providing unconditional love and acceptance
2. Trust them
3. Provide safe environment for them to fail
4. Trust their problem-solving skills
5. Encourage independence and let the child solve its problems
6. When they are hurt, listen to them calmly and provide them comforting feeling
7. Let the child know the consequences of bad behavior
8.Set the expectations and rules of the game
9. Provide enough freedom to be creative
10. Accepting your kid as he/she is the key to making them resilient

In fact as part of coaching engagements, this is exactly what we encourage Scrum teams to be.  A Scrum Master should work towards building resilient Scrum teams. 

How do you build resilient Scrum teams ?
Just replace “kids” with “scrum teams” :-)  in the above section and you have the answers.
Bottom-line is, a Scrum team should be trusted and encouraged to solve their problems.  

There is a huge misconception in the Scrum world that “Scrum Master”(SM) is there to remove the blockers/impediments, and I would strongly discourage this characteristic. 

As long as Scrum Master is solving all the challenges, the team stays crippled and dependent on SM. Sometimes the SM must consciously step back and allow the team to struggle to solve their problems.

With the right environment and boundary conditions in place, the team should be allowed to work on the goal. The team should be trusted and encouraged to figure out the solution. When they fail, instead of punishing them, they should be comforted, and support should be given.

Before I conclude this short post, What other characteristics have you observed in resilient teams?

Photo courtsey: https://flic.kr/p/qwbDN

Are you building product for the customer or the PO ?

One of the biggest challenges facing the Scrum community is understanding the role of Product Owner(PO).

Most of the Scrum teams believe that  PO is a mediator between the customer and the teams. That is, there is a strong belief that PO gathers requirements and passes it to the team. This way of working is the most ineffective way of doing software development. Any hand-off creates wastes and also, PO would end up becoming a bottleneck.

Instead, the most effective way would be for the PO to facilitate the conversation between customers and the teams as much as possible.The direct conversation is not only effective but reduces ambiguity,delay and avoids wastes.

Yes, I understand organizations say it is difficult to get customers on board and spend effort, time, money to engage teams. I guess this is where the organizations need to make a call, whether they want to build great products for the customers or the product owner !!

Stop following the successful companies

It is a common practice to look at successful people and learn the “best practices” as much as possible. The belief is that, by copying the successful practices, we become successful as well. My question is, does that really work ?   Can you become successful investor like Warren Buffet by reading every article/book written about him?

Even many organizations are obsessed trying to copy the practices from Google, Facebook, Amazon, etc. There is nothing wrong with it. However, I believe that one could learn more from failures than successes. So, focusing on the stories from failed companies would be more valuable than popular/successful companies.

There are couple of other reasons why I believe it is time to stop following successful companies:

1. Successful companies became so while they learned from many failures during their journey. Each failure would have enabled them to build some kind of structure to support from future failures and making them resilient. The media in turn focuses only on the “final” state of the company rather than the journey.

One would never get a chance to understand the “resilient structure” that has been built in place to withstand failures.  That’s why, copying only the “practices” from the final state without having a proper resilient structure in place will cripple companies even with a small tremor.

2. There is always a third dimension that you would never get to see.  In another research, the scientists found a pattern of increase in ice cream sales to increase in deaths due to drowning. They were baffled until they realized the 3rd dimension to this data/research.

The ice cream sales increased mostly during the summer, and this is the time where most kids would like to relax and enjoy swimming in rivers/pools as compared to winter months. This increase in swimming proportionality increased the fatalities as well.  As a researcher, if you ignore the 3rd dimension, in this case, the seasonal impact on ice cream sales, one would end up banning the ice creams.

Similarly, the success of every organization would involve some kind of 3rd dimension which is difficult to know/understand. Trying to copy simply the practices could be more harmful than helpful.

Toyota is my favorite example. 1000s of books have been written about Toyota Production system, Lean thinking, etc. Even Toyota allows people to visit their factories and learn from them. The question is, can you become like Toyota by copying their practices?   One would never be able to replicate Toyota or any other successful company. The success comes only from learning that typically happens through failures.  One should try to build their own set of practices based on their context/experiences.

That is; it is very important for organizations to build safe to fail and fail-fast/fail-often culture.

Going forward, start chasing the stories from failed companies and stop following the successful/popular companies.

Its high time that we stop using Velocity

Velocity in an Agile environment is the most misused-used and misinterpreted word/metric.  The key issue is, teams and stakeholders interpret Velocity as a productivity measurement rather than capacity of the team.

I don’t blame the team or the managers. But the “word” itself. If we look at the synonyms for Velocity(see the screenshot below), all of them point to quickness, momentum, acceleration, which naturally encourages people to connect this with “productivity”.  

 

Google for Acceleration or Velocity and one would find following images… These images push people to think more of a competition, race and winning rather than a team work or a capacity.

I think we should stop using the word velocity and start using the word that creates some mental image to show the “team’s capacity”.

Do you think this is a fair call ?

Coaching intervention during a team conflict

Every team goes through some stages of conflict before they stabilize. Leaders need to be conscious of intervening during such conflicts.  The knee-jerk reaction of a typical leader observing a conflict is to jump immediately to “fix” the problem. It is highly recommended that they avoid it and take a step back to monitor the situation first.

The leaders need to find the appropriate time and context to intervene for coaching. Here are some examples and contexts.

1. Self-organizing teams are in the process of learning. They are trying to check the boundaries and positioning themselves in the team. Conflicts in such situations are imminent. The leader or a coach assigned to the team should avoid intervening in such contexts. 

These teams are like butterflies emerging from pupa. Yes, there is a bit of process, pain and time involved to emerge out of pupa, and one needs a bit of patience. Trying to expedite the process could actually kill the butterfly. 

2. Research suggests that creative and innovative work actually needs healthy debate and conflict. Intervention is needed to help the in understanding the differences. There are many times a person or a small group within a large group might be thinking tangentially. This could lead to conflicts and it does not mean that there is anything wrong here. In fact, such conflicts avoid groupthink.

For example, an engineer embedded in a marketing team obviously think differently. The engineer could be considered as a trouble maker as he/she is different than the rest of the marketing team. In contexts like this, the leadership or coach intervention is essential to assist the group.

As a leader one needs to drill down a little bit, get rid of the noise and study the type of work before intervening. The diversity of the team needs to be taken into account while dealing with a creative team as well.

3. If the team is working on a routine and repetitive kind of work, coaching intervention trying to facilitate discussions could backfire. Instead, a root-cause analysis with a management intervention is critical for smooth functioning.  

To conclude, if you see or hear a conflict, don’t jump to fix the problem. Try to understand the context first. Many a times, the conflict is actually good for the team, and the organization in the long run.

Overcoming the Obstacles to Achieving Agility and Delivering Business Value

I am  excited to say latest version of  Cutter IT Journal  has published my article “Overcoming the obstacles to achieving agility and delivering business value” .  I  authored this article exclusively for Cutter. 

In this article, I have articulated various issues that hinders agility in the organization. I am proposing the Systems thinking approach to solving the organizational and agile challenges.In order to achieve true agility, it is not sufficient to blindly follow the agile practices but to think beyond Agile. One should look at fixing the organization structure, focus on uplifting the relationship between business and IT and last but not least, fix the funding model.

I have shared some practical tips and solutions to achieve true agility beyond practicing Agile. The article is exclusively available for Cutter IT members and could be downloaded from here.

Here is the abstract of the article:

This months issue covers the following topics, including mine (highlighted)

IN THIS ISSUE

Vince Ryan and David Putman open the issue by exploring several common difficulties experienced by groups moving to an Agile approach. These range from cargo cult behavior -- blind adherence to the what of Agile without knowing the why -- to the technical abilities of people to work in an Agile environment. The authors delve into key issues such as empowering people to actually make the changes required to support Agile, as well as ensuring that they have the proper skills to be able to thrive. The authors explore such areas as training, the recruitment of new people, and offshoring/outsourcing with respect to the changes that may be needed for an organization to truly reap the promised rewards of an Agile approach.

Our second article, by Cutter Senior Consultant Lynn Winterboer, examines one of the less traveled paths of Agile -- the implementation of Agile approaches in the DW/BI space. Winterboer addresses the challenges of breaking this type of work down into small slices, when it has traditionally been an "all or nothing" deal. She describes what is perceived as technical inefficiency in the small slice approach and how that is balanced by the business efficiency. Winterboer shows not only the advantages gained by earlier delivery of value, but also the effort required and "instability" incurred during the transition. In the end, both organizations in her case studies found ways to deliver smaller aspects of the total solution, providing more value sooner to their stakeholders.

In "Overcoming the Obstacles to Achieving Agility and Delivering Business Value" Venkatesh Krishnamurthy dispels the myth that "Agile is a tool" that can be discarded when you're "done,"much as a hammer is put away once a construction project is completed. He asserts, correctly in my opinion, that simply following Agile practices does not make an organization Agile. The use of systems thinking to view the transition in the context of the whole organization shows how the organizational structure, funding models, and business/IT relationship must change in order to support true business agility.

Finally, Alan Shalloway speaks of how Agile and Lean have "lost their shine" as the result of misapplication. My experience certainly supports this assertion. Shalloway proposes the use of a Lean-Agile hybrid approach that leverages both the organization-wide strengths of Lean and the team-level strengths of Agile. Like Krishnamurthy, he recommends the use of systems thinking in order to take a more holistic view of the context in which the Lean-Agile transition is taking place. Shalloway describes this ecosystem and the unexpected effects that can result when you don't consider groups outside of the development teams.

Read more about this issue here

Do you have an Agile Testing mindset ?

Here is my recent guest post for Zephyr…

Performing Testing in Agile projects is not termed as Agile testing. Agile testing involves whole different mindset.  Then, how do you know your team has Agile testing mindset?  As a coach, I start this by asking testers the following few questions:

- Do have to wait until the development is done to start testing?

- Do testers feel there is a lack of time at the end of Sprint?

- Are testers blamed when defects are identified?

If testers answer “Yes” to some or all the questions above, then the team still has “Waterfall” mindset in guise of Agile. 

Another litmus test to try is to check the team’s wall which is popularly called “Kanban” wall. If you see a wall like the one below, where the “Test” ing is a separate column, then this is a smell.

Read the rest of the article on Zephyr

Need for dedicated testers in Agile environment

Here is a short article for Zephyr’s guest blog

Scrum recommends 3 roles, the Product Owner, Scrum Master and the team.  There is no dedicated role as a tester (or QA) if you are following pure Scrum.

Agile also recommends that the team members are expected to be cross functional with T-shaped skills popularly known as “Generalized Specialists”.

However, the challenge I have seen in many projects is how “generalized” one could be while performing the role. Most of the projects are, so budget and time constrained that everyone is part of the rat race. They just want to get things done, and there is hardly any time for the team members to learn from each other and building generalized skills.

Building cross-functional and T-shaped skills is not easy. It needs a dedicated attention, time, effort and $ is involved from the organization to enable this. One cannot ask a developer to sit with a tester for a few days and learn testing. Personally I believe that testers mindset is something that comes with passion. In addition, mindsets of developers and testers are different.

There is one more reason behind having dedicated testers, and this is due to “IKEA effect”. The Harvard article concludes that,

“When people use their labor to construct a particular product, they value it more than if they didn't put any effort into its creation, even if it is done poorly.”

In the context of this article, when developers create the code, they value their creation more than the testers. The developer doesn’t like someone finding fault with their creation. This is one of the reasons why one gets to hear all sorts of excuses from the developers.

Read rest of the article here

Melbourne: Upcoming Agile trainings and conferences

The Agile community is getting ready for a new and exciting year ahead.  Several interesting and fascinating Agile trainings, conferences and workshops have been scheduled.

Here is the first list:

February

1 - Advanced Agile Master Class with Alistair Cockburn. 17-19 February

2 - Certified LeSS (Large Scale Scrum) Practitioner with Bas Vodde. 24-26 February.

March

3 - 1st Conf, 16 March 2015. For people starting out with agile. Alistair Cockburn keynote.

4 - Workshops for 1st Conf, including Introduction to Kanban, and Management 3.0 … with more coming.

July

5 - LAST Conference 2015. Friday 24 July. Submissions open now.

NB - The code POBA will apply a discount to all of those events :)

Scrum Australia 2014 : Build great products with Scrum + Design Thinking + Lean Startup

I had the privilege of speaking at Scrum Australia 2014 conference couple of months ago. It was a fascinating experience to stand in front of such an energetic and knowledgeable audience and share ideas.  Scrum Australia team had put a lot of effort and energy in getting good speakers not only from Oceania but from abroad as well.  I enjoyed every bit of this conference for 2 days.

The title of my topic was “Building products that customers love by strengthening Scrum with Design Thinking and Lean Startup methods” .

I believe that we need to combine various methods, and use their strengths to build the products. Scrum has its own strengths, and similarly Design Thinking and Lean Startup as well.  However, none of these methods on their own can be used on their own to build great products.

First of all one needs to ensure that any new product idea is viable, desirable and technologically feasible.

It is very important that one has a good understanding of the problem one needs to solve.  Most of the products fail mostly because of lack of understanding of the problems.

Design Thinking comes handy in articulating the problems, and Lean startup could be applied with product testing, pivoting.

I would like to thank  Lynne Cazaly for beautifully depicting my session with the following “Visual Note”

I had put together this idea of bringing the 3 methods together (Scrum + Design Thinking + Lean Startup) long ago. This idea was published by Cutter as an Agile advisor.  Cutter was also gracious enough to make this article public. The entire article is available here if any one is interested in getting  into a detail a bit.

I have been attending Scrum Australia conference without fail since the last couple of years, and return with a load of new knowledge and experience. I am already looking forward for the 2015 conference :-)

Correlation does not imply causation

After every Agile conference, agilists return back to work with tons of new ideas.  They get excited about these new ideas and would be looking forward to roll them out sooner than later. However, based on my past experiences, I have realized that many ideas could do more harm than being helpful.  This is not because ideas we hear at conferences aren’t good, however, what we assume as the “idea” behind success may not be the “one” causing the success.

Popular ideas being borrowed in the Agile community include the Spotify’s  tribes/guilds, Google’s 20% innovation time and many more. In this advisor, I am challenging the readers to think before they act and understand the hidden secret’s of success.

Here is link to the complete article.

This advisor has been written to enable the Agile conferences attendees to look deeper about the “causation” aspect rather than the “correlation” .

How to make wall-related decisions in Distributed Agile projects

I authored the following article for Cutter which got published today. So, it is hot out of the press.

The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter

If you are start up, think beyond one user

As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.

• All start up founders are really enthusiastic and dream of becoming rich –> Nothing wrong with it
• All start up founders have a strong idea in mind ---> Nothing wrong with it
• Most start up founders believe that their idea would take over the world, even though they have never tested beyond one user   ---> Something wrong with it

Recently read a story about startup failure “Patient Communicator”.   The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.

As the founder shares his experience, PC began as a product for my father’s medical practice.  Plain and simple, I never assessed the market need for a patient portal.  It’s extraordinarily difficult to take a product that was built perfectly for a particular user and commercialize that into a broader market.

If you are in start up journey, think beyond one particular user !  

Large Scale Scrum (LeSS)

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram

Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).

In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:

LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.

If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

What is Loyalty ?

No one plans to fall sick isn't it? Similarly, when I caught some flu couple of years ago, we were eager to see a doctor. Being new to our suburb, googled around to find a nearby medical center. Took an appointment with "any available GP," visited and got better.

After some time, it was my wife's turn. When she wasn't keeping well, she too called the medical center, took an appointment with "any available GP" and felt better.

Apparently she visited a different GP than mine. She recommended me to see him next. Over the course of time, we noted his name and started getting appointment specifically with him when needed. Suddenly one day we heard that he moved out of this medical center, and the receptionist wasn't eager to share his new coordinates.
We felt a bit sad as he knew us well, and we had a built a good rapport over the years and now we don’t know his whereabouts.

Later due to circumstances, we moved to a different suburb and once again started the search for "any available GP". We weren't so happy with the GPs we had seen compared to our earlier one. We used to remember our earlier GP once in a while.

One day we casually thought of searching our earlier GPs name on google, and some names came up. We called a few and one of them actually turned out to be our earlier GP. Everyone was elated, and we went and met him as well. He was not only surprised to see us but was beaming with a big smile.

I would call our selves as the loyal customers for this GP as we did everything we could do get the services only from him even when several options were available.

Loyalty is something when you chose a specific service inspite of having many options in available to you. Of course, a more formal definition from Wikipedia would be “Loyalty is faithfulness or a devotion to a person, country, group, or cause.”

On the other hand, repeat business is something where customers use existing service as they don't have an alternate option.

It is shameful to see that many companies measure "repeat business" rather than "loyalty." Loyalty is much more powerful than getting a repeat customer. Loyalty is something that will enable the company to grow during downturns and fierce competition. Repeat customer will leave you and go when they find better options.

Nowadays companies rollout the so-called "loyalty program." Big shopping malls and airlines have this loyalty program. I feel that this is a bit misnomer. People tend to go back to these companies not because they like the service, but because they get some discounts or redeemable reward points. I don't call such programs as a "loyalty programs", but as "carrot programs."

Couple of things I liked about our family GP has been his relationship building skills, his frankness, his specialty, customer service and respect for us.

Here is another personal example, while I moved to a new suburb, I was scouting for an electricity provider. I was calling each provider and gathering various details. As one could see, each one was tried their level best to sell a service by sharing their discount program, except one of them who explained their weaknesses as well. She not only suggested alternate but better options. I genuinely got connected with this company. Lesson learnt, being truthful and genuine breeds loyalty.

To conclude, It is very important for a business to evaluate if the returning customer is a loyal one or a repeat.

Even though we have tools like NPS, it won't clearly tell you the difference between loyalty and repeat. It partially helps to understand the situation though.

Always try to build a loyal customer base and work towards converting the repeat customers to loyal ones.

I have also posted this article on LinkedIn