Pages

Thursday, February 01, 2018

Why cultural change in organisations is hard ? : Systems Thinking perspective

Many enterprises create bold vision and mission statements. However, many hardly leave up to them. Sweeping changes created in the organisations with the intent of creating a positive momentum, many a time leads to failures. Why ?
Why is it hard to bring cultural or process changes in the corporates? Why is it hard to execute many well-intended plans?
The answer, according to me boils down to the availability of leaders who have the eye to see the leverage points in the system. We have many academicians who have in-depth knowledge about the system but are very few in numbers. We have umpteen number of leaders but lack the ability to see the details in the system.
When I say, having an eye to see the leverage points, I meant the invisible structure within the organisations in the context of this article. 
As we know, the senior management looks at the organisation as per the HR structure with lines and arrows reporting to one another. However, one needs to realise that, there are invisible structures in the system which cannot be seen through naked eyes and thus cannot be easily represented visually.
The emergent behavior and the culture in the system are hugely influenced by these invisible networks. It is paradoxical to note that, the invisible structure in the system are robust self-organizing systems. However, in the same system, when the scrum masters/leaders try to consciously create self-organizing teams, they fail miserably. 
Unless and until the invisible structure is identified, it 's hard to bring any change in the organisation. Because of the emergent property of the self-organizing teams, it tends to become a moving target. An experienced enterprise coach would be in a position to see and track, influencing the necessary changes. 
I would recommend some of the following steps based on my past experiences:
  1. Take time to understand the invisible structure without ignoring the visible one
  2. Set right expectation with the senior management about your hunt
  3. Many a times you might want to create a ripple by throwing stone in the perceived "calm water" to make underlying structure visible
  4. You cannot change the system until and unless you become part of the system
Image attributions: https://flic.kr/p/6pCiBa, https://flic.kr/p/6XSpXY
Please register for my upcoming Certified LeSS Practitioner courses in Sydney and Melbourne. I would be covering many concepts around Systems Thinking during these 3 days course.

LeSS conference London: Key snippets, announcements

LeSS conference is designed in such a way that, participants learn the large-scale facilitation techniques in addition to practicing many of the LeSS ceremonies. This is more of an unconference than a conference. I never felt that stiff-neck that I typically see in most of the conferences.
For example, the conference started with a Bas's keynote followed by Craig's playing his guitar

Continuing from last year's tradition, self-designing experiment was conducted with nearly 150 participants. Teams went through 3 iterations before forming their teams.
We did an open space, providing opportunity for participants to choose the topics of their own interest.
Several luminaries and thought leaders presented some of the deepest ideas around technical practices and product development. One thing which is different at LeSS conference, per my observation was that the speakers were not invited based on their popularity, but based on their deep knowledge in certain areas.  
Nowadays, in many conferences, I see the same faces again and again. Mostly, the popular speakers are invited. There is nothing wrong with that, but it ends up feeling like a celebrity show rather than a learning platform. 
Here are some additional pix of speakers presenting and various games that were played during the session
We also had a panel discussion with the LeSS trainers
a little bit of self-promotion :-)
The conference ended with Bazaar style reviews and retrospectives.
As I shared at the beginning of the post, LeSS conference is unique. Participants are not there just sitting and listening to the monologue of the speakers. But they really "participate" in every activity and learn the essence of LeSS during every minute of the conference.
Last but not least, a new video introducing LeSS has been created, and it is really awesome. Don't forget to check this out:

Looking forward to see you in the next one.
Before I sign off from this post, have announced my upcoming Certified LeSS Practitioner courses in Sydney and Melbourne. I would be covering many facilitation techniques, ceremonies with in-depth conversations on product development applying LeSS during the 3 days course. Hope to see you in my next one.
Here are the links to register for the course:

Why Agile implementations are failing ? three Musketeers

During my recent breakfast chat with one of my mates @James Hayes, we retrospected on the current state of Agile implementations across the industries. Of course, there are hundreds of reasons, but we also realised that three key roles in the industry play a crucial role in this entire process.
During the chat, we realised that most of the time we blame middle management in organisations for the failure of any agile implementations. However, the issue doesn't start there. The issue starts during the recruiting process.
As shown below in the picture below, we discovered that in-experienced Agile coaches apply for jobs through recruiting agencies. Recruiters who scan the profiles of these coaches may not have enough expertise to identify the right ones. The same profiles are forwarded to the inexperienced (in Agile) hiring managers in larger organisations, who recruit the in-experienced Agile coaches, thus resulting in massive failure in Agile implementations.
Again, this is just an observation and not based on any data or anything. Even though I picked coaching here, I am sure the same could apply to other roles as well.
How can we fix this?
My view is that upskilling the recruiters and the hiring managers could make some difference here. My theory is that, as long as we have a huge demand-supply gap in the coaching field, we will end up having many (inexperienced)coaches. So, we can't stop, until the gap is narrowed down. 
Before I end this post, I want to say that, the above theory is not a generalised one, I have come across many fantastic recruiters, hiring managers and coaches as well. However, don't you see we have some scope for improvement?

Honey, I will be home late, another deployment day !!

Do you call your spouse to let them know that you are going to be late again as another deployment is happening at work?   
During the daily Scrum do you hear your team members answer "I am working on Jira card 1078" in response to "What are you planning to do today?". 
Do you respond by saying you are a BA or a Java developer if someone asks "What do you do at work ?"
Even though there is nothing wrong with the answers as such, but it talks a lot about the organisational culture. My experience says that the language, the employees use on a day to day transaction is a reflection of the vision and the values espoused by its leaders. 
You might have heard the Janitor and the JFK story. While president JFK was visiting NASA, he saw a janitor carrying a mop and asked him what is he doing? The janitor replied that "he is helping to put a man on the moon." The janitor didn't see his work like cleaning or mopping the floor, but something that is contributing towards the broader goal NASA wanted to achieve. 
The point is, about the organisations inculcating the broader vision in every employee.  
https://flic.kr/p/XT6EdD
Many prominent and long-lived organisations around the world have ensured to consciously create a vision, purpose and empowering the employees to achieve them. 
Even though agile has become the defacto standard of delivering software, still employees are disconnected from the customers. 
You stop and observe any daily Scrum in your teams and observe their language. Do they keep referring to the Jira cards or Do they talk about the value being delivered to the customers?  What does it say about the surrounding system? What behaviors are being encouraged by the leaders around them?
Do you belong to a deployment team? Do you call your spouse that you are tied up and busy with deployment at nights and returning home frustrated ? what does it say about the system around you? Does that work empower and engage you with the broader vision your organisation wants to achieve ?
To achieve true agility in the organisation, employees need to be empowered, energized and engaged with the end customers. They should be made part of the larger goal and vision of the organisations. It is not good enough to do a great Scrum or Kanban and ignoring the human aspect of the system. 
Before I end this article, let me share about my upcoming Certified LeSS Practitioner trainings Sydney and Melbourne.

All models are wrong and some are useful

During my recent chat with @Kate R S about assessing organisation's maturity, we talked quite a bit about various models and touched about Dreyfus, Shu-ha-ri, etc. 
One thing that kept coming back to my mind was the aphorism, "All models are wrong, and some are useful." This is especially true while we are analysing a large organisation or a team. 
I see organisations like any other living systems as it is run by living organisms. The complex nature of the human thinking and their interactions keep creating emergent behaviors every minute of the day.  
Trying to capture the organisation's behavior and represent it in a simplistic model is a futile exercise. As I said before, the emergent properties of a system change due to the various factors. New people are joining, old people living the organisations, corporate politics, ego-war, protecting the turfs, threat from competition, etc. keep changing the dynamics of the organisations. 
Besides, the organisations are so complex that, there is no guarantee that the data that is gathered to assess the system is the right one. Even if we gathered the data is accurate, it still represents the snapshot of the system. Creating a two-year plan to fix the organisations based on today's information is as bad as doing nothing or may be worse!
Bottomline, if you are planning to assess an organisation, be aware that: 
  • The understanding the overall system as much as possible is the first step
  • Observe, listen and act. This could take some time. 
  • Remember that, the models that are constructed based on today's data would be stale by tomorrow. Be ready to throw it away rather than hanging-on-to it. 
  • Understand the leverage points to drive the change rather than static models.
Before I end this article, let me share about my upcoming Certified LeSS Practitioner trainings in Sydney and Melbourne. You can register for these courses using the links below:

Improving retrospective effectiveness - a Draft model

Retrospectives, one of the most popular ceremonies in Scrum, is also the most abused. As per the Scrum Guide, the purpose of the Sprint Retrospective is to:
  • Inspect how the last Sprint went with regards to people, relationships, process,and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work
As we know, the retrospective is all about the Inspect and adapt cycle, which is also the foundation for the empirical process control. 
However, my observation of a typical retrospective of many teams looks like the one in the diagram shown below:
Apart from the overall broken process, team members write a very twitterish description on the post-it something like the one shown in the screenshot below:
Even if you show the above post-it to the authors after a sprint, they won't be able to recollect what the hell was this about !! have you come across this in your teams ?
I understand that the description is supposed to be short/sweet, mostly for discussion. However, it shouldn't be too short that, you can't discuss it in the future!
Draft Model
Keeping the inspect-adapt cycle in mind, I have come up with a draft model(shown below) that could be experimented to improve the effectiveness of the retrospective.
Key changes in the proposed-model are:
  • Doing safety-check ins. . Check this article to learn more about Check-ins. I know most of you might be doing it already.
  • Additionally, I like people sharing their stories and narratives rather than just dumping twitterish words on the post-its. So, let everyone tell their stories, listen to each other and take notes. If I am telling the story, I would recommend someone else to take notes, write it on a post-it with points connecting the stories. 
  • Look at the patterns of challenges arising out of previous retrospectives and do a root cause analysis. 
  • Of course, as part of the adaptation, the improvement should not do quick fixes. The actions should look from the systemic perspective. 
  • Large-Scale Scrum(LeSS) recommends teams to do Causal Loop Modelling to understand the impact of their actions on overall system.
  • It is very important not to forget ask "Are we improving ?"
Feel free to share your thoughts and what did you like about the draft model ?
You can use the above model in addition to the info in these highly recommend books:
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:

Role of leaders in building high performing teams: Givers, Takers, Matchers

I was reading Adam Grant's Give and Take, and according to Adam, there are three types of people. Givers, Takers, and Matchers. 
  • Givers like to give more than they get, paying attention to what others need. 
  • Takers like to get more than they give, seeing the world as a competitive place and primarily looking out for themselves. 
  • And matchers balance and give on a quid pro quo basis, willing to exchange favors but careful about not being exploited. 

Adam's research also points that "Givers" are more successful in lives than takers or matchers, even though it comes with a cost. 
Imagine you are a hiring manager in a large enterprise and you have been asked to build a team. Question: Would you hire generous givers, selfish takers or transactional matchers?   
Good news is, we don't have to worry much about this answer as Adam shares his thought process in this HBR article. Givers are the best. However, organisational KRAs/Individual-based incentive system creates competition among employees and forces them to act like takers impeding the collaboration. 
Adam also suggests the solution:
Part of the solution must involve targeting the takers in the organization—providing incentives for them to collaborate and establishing repercussions for refusing reasonable requests
The article also has some good tip for managers/leaders to consciously create the right environment for building the high performing team.
There are three payoffs associated with teaching employees about the power of agency, boundaries on availability, and perspective taking. The first is saving your best employees—those who exemplify collegial generosity—from being taken advantage of and helping them to gain stature as successful givers instead. The second is enabling employees who fear the risks of giving to contribute more to others and to the success of the enterprise. The third is creating a culture of and reputation for generosity that attracts more givers to your organization and appeals less to takers.
The next question I would like to ask is,
Do you think that empowering the team to self-organize will ensure that all the givers, takers and matchers start collaborating automatically?  Or do you think that leaders intervention is still needed to handle the personality issues in self-organizing/self-managing teams?
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:

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:

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: