Why did the coffee shop fail ? : Systems Thinking

Once upon a time, there was this tiny coffee shop that attracted a lot of crowds. Just like any other shops, they offered sandwiches and muffins apart from the popular coffee. The owner was becoming prosperous day by day. 

One day, a bit of greed kicked in and while looking at his profit/loss statements, realised that he is not making much profit from sandwiches but a lot from the coffee. So, he decided to focus only on coffee and stopped selling sandwiches. 

https://flic.kr/p/9vPTLW

Astonishingly, over a period of next couple of weeks, crowd not only reduced but many stopped as well. His business declined and almost reached a stage to shut down his shop.

Upon detailed analysis, he realised that people came to his shop to buy the sandwiches. However, while waiting, they used to order the coffee as well. Since the owner decided to stop sandwiches, the crowd stopped turning up. 

Even though he was not making a profit from the sandwiches, but it was generating profit elsewhere through coffee. Without really understanding the whole system, the owner looked at individual departments in his shop and started optimising them. 

By the way, the above one is a true story.

We live in a complex world, and making decisions purely based on numbers shown in the spreadsheet won't help. One needs to understand the overall system and their interactions to make effective decisions, which leads us to learn about Systems Thinking. 

In most of the organisations, leaders/teams make decisions just like the coffee shop owner. That is, they don't look at the overall system but individual subsystems and starts optimising them leading to sub-optimal results. 

Some examples include:

• The product owner prioritising the delivery work over the technical debt. As Delivering software produces revenue faster !!  

One doesn't realise that, over a period, increase in technical debt decreases the software delivery cycle and costs more. 

• Developer directly jumping to write code rather than following the TDD approach as TDD is time-consuming.

Developers don't realise that TDD can help in catching defects earlier and creating a better quality code. 

• Enforcing the distributed teams to use video conferencing facility by cutting down the travel costs to save $s

Letting the people travel to other locations builds trust and relationship thus reducing communication gap. Leaders don't realise that lack of trust costs most to the company than the travel costs. 

One of the Large-Scale Scrum(LeSS) principles is Systems Thinking. It's knowledge and practice enables the organisations to make better decisions in every step.

Before I end this post, here are my upcoming Certified LeSS Practitioner trainings in Sydney and Melbourne. You can register for these courses using the links 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

Why can't you replicate Toyota? You can't copy thinking

There are hundreds of books written about Lean Thinking, Toyota Production System and much more detailing the quality initiatives within Toyota. However, no other company has been able to replicate Toyota till date.

Personally, I believe that no matter, how much ever practices one tries to copy from successful companies, one can't replicate the success. The secret sauce lies in "thinking" behind the practices rather than the practices itself. 

Thought would detail out some of the popular practices the organisations try to copy ignoring the original thinking...

Every practice at Toyota has emerged from Thinking. Copying the practice won't help. You need to replicate the thinking. Things like "Respect the customer," "Stop and Fix" are not just practices but the thinking that needs to become part of the DNA.

https://flic.kr/p/drziYW

Another popular trend is copying the "Spotify model." Mostly organisations get carried away with the buzzwords of "Guilds," "Tribes," etc. They are not aware that, Spotify came up with a model due to their culture of experimentation based on many years of thought process. Copying Guilds, tribes won't make them Spotify. 

Organisations need to focus on building a "thinking" culture rather than "copying" culture. This is one of the critical reasons why Scrum/LeSS took the framework approach. You can start with the simple set of rules and build your method based on the proven principles. 

If you are keen to learn more about Large-Scale Scrum(LeSS), you can register for my upcoming courses. The details about the Sydney and Melbourne 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

Leader as a designer, teacher: LeSS, Systems Thinking

One of the most overrated roles/positions in this century has been that of a leader. The Hollywood's, fortune 500 companies and the media frequently uses the word "leaders" symbolizing someone with influence or authority. 

Looking at the online etymology of the word "lead," it dates back to 1400s. Initially, it was tied to the metal "lead," which meant "flow" due to its low melting point. Over a period, it took various shapes/forms to represent someone with the ability to lead one's life.  

Interestingly, the modern etymological synonym of "leading" closely resembles the above definition with a slight modification. Instead of "guiding" one's own life, the leader will lead the way for others.  

Nowadays leadership means a position to many, class, a lifestyle(people with bungalows, playing golf), charismatic personalities with power, influence, and authority. 

How many of your leaders are actually "leading the way"? If you go to work and look around, most of the leaders are busy with spreadsheets reviewing the reports, numbers, doing performance appraisals, a tool to find faults and in turn, fixing the employees' salaries.  

How many of them are leading the way or pursuing a vision inspiring you to follow?  

Peter Senge encourages people to look at leaders as designers rather than captains of ships. If you assume, organizations are like ships; then captains can sit in an air-conditioned cabin and command the ship to turn 6 degrees. What if the ship itself is not designed to efficiently make the maneuver? 

https://flic.kr/p/iNcaEU

Senge encourages leaders to get their hands dirty and help in designing efficient organizations that can withstand tides and storms. 

Robert Greenleaf, who popularised the concept of "Servant leadership" encouraged leaders to ask if those served by them are growing wiser, healthier, freer?

Leaders as teachers and coaches is not a new concept. A practice that is successfully demonstrated at organizations like Toyota. 

Combining the ideas of thought leaders like Senge, Greenleaf, etc., it is clear that leadership is all about designing a system creating a space for people to follow a particular vision and purpose. 

Based on extensive research and experiments, Large-Scale Scrum(LeSS) thus recommends managers to work in creating the right structure, in turn, the culture to build agility and deliver the highest value to the customers all the time.  

As one could see from the picture below, managers are not at the top, directing the teams or assigning the tasks. They are busy in building the organisational structure, improving capability.

Following diagram provides further details clarifying responsibilities of managers in a LeSS organisation.

If you are keen to learn more about Large-Scale Scrum(LeSS), you can register for my upcoming courses. The details about the Sydney and Melbourne 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

LeSS coming to Brisbane - May 2018

Happy to announce the Certified LeSS Practitioner(CLP) course in Brisbane. After many successful trainings in Sydney and Melbourne, we are expanding to Brisbane.

The exciting part is, I would be conducting this course in collaboration with my good friend James Hayes(director AginicDS).

James and I know each other from our Suncorp days, and excited to continue the collaboration with LeSS trainings in Brisbane.

My upcoming Sydney and Melbourne courses details are as 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

Trip to India in Jan and Potential LeSS knowledge sharing sessions

Booked the flight for my next India trip in January. I would be in and around Bangalore for couple of weeks starting 1st week of Jan.

I know the Agile and LeSS community is very active in Bangalore, Pune and Delhi regions. I am happy to spend some time with the Agile communities and probably do meet ups, knowledge sharing sessions (if time permits).

Incidentally, my friend Satish Agarwal who is in Melbourne is visiting Pune during the same time. He is considering scheduling a LeSS meet up/potential CLP.

Feel free to reach out to me if you are keen to set up a knowledge sharing sessions or workshops in Bangalore or Pune.

Is your Product owner, owns a project or product ?

The Scrum Guide says,

Scrum is a framework for developing, delivering, and sustaining complex products.

The role of the product owner says,

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.

Now, when you get back to work next week ask the following questions.

1. What is your Product?

2. Are you applying Scrum to Product development or ad-hoc projects?

3. Is your product owner, owns the product or a business person who has been given budget to build some ad-hoc features?

I have been observing for the last several years that, organizations who "say" are applying "Scrum" have no clear definition of a "Product."  Pretty much any work that CEO or the senior folks decides is added to a so-called "Product Backlog." Since there is a Product Backlog, they will catch hold of a business person, giving him/her a title "Product Owner." 

Since each department is given a budget to burn every year, each business person chooses a bunch of ideas, stuffs them into a "Jira" board calling it "Product Backlog."  

I know purists might scream at my above statements and say, we are doing agile, and we can customize in whatever way we want. This reminds me of Larman's laws(especially 3rd one below)

1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.

3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.

4. As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3).

5. Culture follows structure.

If an organisation wants to apply Scrum or LeSS, then they need to follow Shu-Ha-Ri . Without really following the rules(SHU), don't customize(HA). In order to follow the rules, you need to understand the rules first.

I have shared this in many forums. I have started gathering the data since several years about the number of CSMs who have actually read the Scrum guide. My stats has shown that, on an average it is 10%. That is for every 10 Certified Scrum Masters, only 1 has actually read the Scrum guide.

If the above trend continues, people will keep failing at applying Scrum, and they will never realise the benefits and values of Scrum.

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

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.