A Framework for Enabling Leadership at All Levels

#5Qs #5Questions

Whenever someone comes up with a suggestion or idea, we should ask them to put it in the following form. This way we understand the idea better and see if the idea owner has given a good thought.

⭐ The Outcome / Need / Why
The north star that shows us the way when we are lost.
(What is the expectation/purpose? Why are we doing it? What’s in it for me?)

🧪 The Suggestion / Experiment / How + What
The idea that we are going to execute.
(What/how are we going to do?)

⏱ The Duration
The time frame that we would like to see an improvement at the end.
(How long are we going to experiment?)

🚨 The Exit Condition
The indicators that let us know, soon, that this is not the right way to go.
(What is the condition to abort? Where is the last point to abort?)

🏁 The Reality Check
The objective proof/metric that we check against to decide the outcome has been achieved.
(How do we decide if we are there? How do we conclude that the outcome is achieved?)

If a colleague can detail the idea (that is the #2 in the list) into this context then we all know when to openly give feedback or ask for questions without being traumatized.

Enabling leadership with training wheels. Experiencing leadership with guard rails.

The Hero’s Journey in Evolutionary Change Management

During March 2020, at the start of the pandemic, I was approached by Kanbanize.com—thanks to Nikolay Tsonev—to write an article on their blog as a guest. I decided to write about evolutionary change management from my experiences and perspective.

The following links are my contributions.

Enjoy 🍻.

Introducing The Hero’s Journey in Evolutionary Change Management (Part 1)

The Hero’s Journey as an Evolutionary Change Management Tool – The Workshop (Part 2)

A Statement

We, the servant leaders, recognize that everyone has their own ways of creating value and we respect it. Also, we’re proud and passionate about the ways that we use to help people.

We acknowledge that it’s not about discarding the old and bringing the new (#revolution), but offering an alternative to see, objectively, which is more fit for purpose (#evolution).

We’re not playing a transformation game in the realm of Agile or similar paradigms.

We’re in the serious business of:
📌 Understanding the needs of the culture first, suggesting appropriate tools later

📌 Growing genuine leaders together to help their culture succeed in the face of rapid change

📌 Supporting cultures with scientific methods and models, to strive and flourish in the competitive business world

📌 Showing scientific evidence that the current ways of doing things are in the favor of what the culture is aiming for

We’re trying to do all the above to “diminish the dependency for our servant leadership services” (in other words render ourselves irrelevant). Enabling us to have our own #phoenix moment; reborn from our ashes and evolve for better.

⭐Agile is not an end but a means to an end.

Never Waste a Good Crisis Point

With the current events (*stressor*), every one is trying to “adapt” to the new environment. It’s not surprising to see people trying to keep their habits in the new environment; not letting go.

The surprising part is when people who are pioneers of agility in their organizations are not making an effort to try something new. Run small experiments, don’t put all your effort in keeping the status quo! Experimentation, isn’t this what we suppose to do? #experiment #kaizen

And what better time is there to come up with something new than now? Use this crisis to see what’s not working, come up with a completely new approach and experiment. You do not need to blindly follow your *rituals*. #dogmatism

Ingredients for change; stressor, reflector, and leadership. This is thought to us (Kanban Coaches) by David J. Anderson. With these, people are motivated and have less resistance for change. The stressor is here; COVID-19. Leadership is needed for new approaches/ideas and reflect on it.

Do not waste this crisis point! Try focusing on #flow. Use #gamification to better manage your existing #Kanban system.  Replace your routines with new ways of interactions. Use storification, find your services, update policies for better risk management. Try to implement AI.

Don’t just try to keep all habits but let some to transform or even die for better ones to emerge. Like a phoenix rise from your ashes; let go of the current and reinspect your purpose and policies. Let go of your tunnel vision. You are allowed to think. #nodogma #kaizen #fit4purpose

Takım Olgunluk Kriterleri

Herhangi bir işte ilerlemeyi gösterebilmek (%35 gibi) hatta benzerlerinin durumları ile karşılaştırabilmek (+10 daha hızlı gibi) ve bunu adil/tutarlı bir şekilde yapabilmek çoğumuzun ilgisini çeken, yapmak istediğiniz bir konudur. Anlamlandırması çok kolay gelir. (Bu X2 daha iyi)

Öğrendiklerimiz nesnelerin bağlam özel (context specific) doğasından dolayı sağlıklı bir karşılaştırma yapabilmenin zor olduğunu söylese de bir modele oturtmadan rahat duramayız. Çoğu zaman modelin mekaniği (nasıl yapılacağı) amacın, kazanımın (neden yapıldığının) önüne geçer.

Bir nevi ruhsuzlaştırmaya değersizleştirmeye maruz kalır. Model belli bir bağlamda çalışırken diğer bağlamlarda tutarlı sonuçlar vermemeye başlar. Çünkü (ruhunu, kazanımını) kaybettiğinden artık yorum yapılamaz, anlaşılamaz bir hale gelmiştir.

Organizasyonlarda koçluk yaparken olgunluk seviyesini gösterebilmek için ben de kendime özgü hazırladığım bir model kullanıyorum. Kullananların, modelin amacını ve kazanımını göz ardı etmeden, kendi bağlamlarına kolayca uyarlayabilecekleri bir noktaya getirmeye çalışıyorum.

Ne kadar işe yarar, ne kadar bağlam özel kalır bunu anlamak için sizlerle paylaşmak istedim. Kendinizin, takımınızın, organizasyonunuzun olgunluğunu bu 5 kategoride değerlendirip, modeldeki aksaklıkları ve güzellikleri paylaşırsanız çok sevinirim.

Takım Olgunluk Kriterleri | v1.1
http://bit.ly/intparseTMM

Experiences on Building Empathy and Trust w/ Metrics

Lead Time; one of the metrics used in kanban systems. Basically, it represents the time elapsed in a system for a request; from the first commitment point to when the value/outcome is generated/delivered. The time elapsed to make a request done; when someone’s need is met as Mike Burrows (@asplake) puts it.[1][2]

One use of this metric is to see it as a distribution. With the help of lead time distribution, we can determine how probable it is to deliver requests, with a similar class of service/process, within a given time frame. Basically, it helps you to answer the ultimate question we all encounter; when will it be done?

When I talk about using lead time distributions to answer this archaic question, people look at me as if they found a gem in the dirt. It is magic! Mathematics, in particularly statistics, is magic to the untrained eye. Now you can see me, now you don’t.

Also, when I talk about this topic, they look at me as if I am a charlatan. It depends on how you approach the topic and use the words to explain this phenomenon. One must be very careful, when talking about this subject, to not be seen as a fortune teller.

Most of the time these are the first reactions I get, and I adjust accordingly.

There is also a second reaction; when they try to use distributions in the real world for the first time. This writing is about the second reaction.

Let’s have a look at an example scenario; the customer has an urgent request and wants it in a week. It is non-negotiable because the organization needs to meet the government regulations. The service delivery manager (SDM) looks at the lead time distribution and sees that there is a 40% chance of completing the request within the due date.

The Service Delivery Manager (SDM) is frustrated because h/she just got trained in a pragmatic, actionable, evidence-based guidance but can’t apply it. H/She wants to say “You are being unreasonable. There is a 40% chance that this can be done. I can’t do this in the time frame you have given me. The distribution says so! There are a lot of critical requests you have already made last week which are still in progress!” to the customer but simply cannot. 🙂

So, the SDM turns to me and says, “Ha ha, Kanban this muthafakaa!” 🙂

The SDM has mixed the meaning of probabilistic approach with fortune telling. And using the new-found arsenal to say no. This is not the evolutionary way.

When this happens, I try to clarify what we are trying to do in an evolutionary way with the points written below.

  1. We are not in the business of fortune telling.
  2. The distribution is telling us the probability of delivering an item WITHIN a calendar date or time frame with the current data/situation in hand. The distribution does not tell us that this item will be done on that exact date. That is fortune telling.
  3. The distribution might tell us a different story with every new data point/sample gathered.
  4. We are not using this probabilistic approach to say no. That causes resistance.
  5. We are not trying to change the way we have been working with the customer right then and there. This also causes resistance.
  6. We are trying to avoid resistance as much as we can. Be like water.
  7. We are trying to create a feedback loop.
  8. We are trying to shift the responsibility to upstream as much as they can tolerate.
  9. We are trying to make them see the situation as we are seeing, with using scientific models. Not just words but with proof.

After this I help them on how to respond to the customer without saying NO but letting them know the risks that are involved to make this request happen in the time frame that they request. Letting them know of possible actions that needs to be taken to make the requested due date more probable. Maybe suggesting that the previous requests will be put on hold and delayed.

This way the customer will know from the start that when they ask for the request a week later there is a big chance that they will hear “it is not done, yet.” No surprises. Empathy and trust starts to build up. And next time the customer will be more willing to listen or help on the situation. Because responsibility has been shifted to them.

Rome is not built in one day. And if it would have built in one day there surely be a resistance. 🙂

When applying Kanban principles and practices you cannot expect your outer world to obey the new rules. That simply cannot happen without resistance or tears. You need to prove them something first and prove it with facts so that you can gain their trust. After this you can negotiate new rules and promise them the outcomes they will see if the new policies hold.

Pursue the evolutionary way. Be like water. Be humane and kind. If you can’t visualize your situation and build feedback loops to let others see, you can’t expect them to sympathize with you.

This is how the decision-making framework starts to build. This is how one starts managing flow. This is how one can build empathy and trust using metrics in an evolutionary way.

When in despair, people try so hard to find a solution to their problem. So hard that their common sense gets blocked, not able to comprehend even the simplest solutions.

And when they are guided to it, they think that it is untrue or not applicable. They feel unchallenged and foolish. They can’t justify all the effort they’ve been putting through to find a solution. So they deny the simple solution in order to find a complex one.

If the problem is not getting enough sleep, no one considers that the solution is to go to bed early. It is so simple and plain, it is an insult to the seeker. So it gets denied.

#Kanban #limitWIP #slackTime

ScienceOfTruth-460