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

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


Why Kanban is, Wrongfully, Perceived as a Waterfall Variant

I had an interesting conversation with a colleague about handover points that teams have in their processes and how to decrease them. He was explaining how to approach this problem in the Agile (Scrum) context; by allowing teams self organize around the work that needs to be done and having T-shaped team members, thus, avoiding silo culture. This was not the interesting part of the conversation.

What made this conversation interesting was, he actually wanted to know why Kanban did not care about silo culture; on the contrary, encouraged it. I was a bit shocked but none the less went along with it. I knew his question was sincere and I knew he was in a discussion on this topic with other Agile enthusiasts/evangelists in the work place.

So I asked “Why would you think that Kanban encourages silo culture?”┬á…

Continue reading