Podcast: Mit Abhängigkeiten umgehen

So sehr wir uns das auch wünschen – ohne Abhängigkeiten funktioniert es in den seltensten Fällen. Ist also alles eine Frage, wie wir damit umgehen. Das hörst du in dieser Episode!

Hast du Änderungswünsche? Dann schreib mir doch an post@florianeisenberg.de oder kommentiere bei Instagram (https://www.instagram.com/kanbanin7minuten/) oder Twitter: @KanbanIn7Min

Happy Kanban und stay safe!

Lieber zuhören? Hier ist der Podcast:

Dies ist schon die zwanzigste Folge. Aber man könnte trotzdem alle Folgen in etwas unter zweieinhalb Stunden hören. Ob du das dann auch alles so verdauen kannst, ist noch eine andere Frage. Apropos verdauen! Ich sehe immer wieder, wie Teams und ihre Scrum-Master, Agile-Coaches oder Team-Leads an der Implementierung der Kanban-Methode verzweifeln ODER es einfach supertrivial angehen. Wenn du schon seit ein paar Folgen zuhörst, wirst du wahrscheinlich wissen, dass es eben nicht trivial ist. Wenn du aber Lust hast, zu erfahren, wie es einfach aber nicht simplizistisch geht, schreib mir doch schnell eine Mail an post@florianeisenberg.de!

In dieser zwanzigsten Folge möchte ich über Abhängigkeiten sprechen. Außer wir haben eine richtig ideale Situation, in der wir ein autarkes, autonomes Arbeitssystem haben – also selbstbestimmt und ohne Abhängigkeiten – haben wir alle Abhängigkeiten. Es soll Rahmenwerke in der Softwareentwicklung geben, die das grundlegend fordern, was kaum jemand hinbekommt. Aber man darf sich ja alles wünschen.

Egal, also gehen wir mal davon aus, dass wir irgendwelche Abhängigkeiten nach außen haben. Das können permanente Abhängigkeiten sein oder Abhängigkeiten, die unvorhergesehen auftreten. Also wenn wir mal irgendwas benötigen, was aber nur nach detaillierter Analyse vorher hätte klar sein können.

Egal, wie wir uns auch dagegen wehren – wenn wir diese Abhängigkeiten nicht in den Griff bekommen, wird es auf uns zurückfallen. Wir können aus der Wahrnehmung unserer Kunden und Stakeholder nicht einfach einen Teil Unvorhersagbarkeit oder lange Laufzeit rausschneiden. Ich glaube auch kaum, dass irgendwer sagt: "Mit der Dienstleistung von XYZ bin ich vollumfänglich zufrieden. Nur der Dienstleister der nächsten Stufe macht das Ganze für mich total unvorhersagbar." Allein schon, dass wir das evtl. nicht gemanagt bekommen, raubt da ja schon Glaubwürdigkeit. Also: In den Griff bekommen!

Wir haben also permanente und unvorhersagbar auftretende Abhängigkeiten. Im ersten Fall, der permanenten Abhängigkeit, müssen wir ein bisschen mehr arbeiten – leider.

Sehen wir uns doch mal an, wie wir damit umgehen. Also. Normalerweise treten permanente Abhängigkeiten immer am gleichen Ort auf. Also beispielsweise, wenn wir ein Softwareprojekt durchführen und eine Abhängigkeit zu einem externen Dienstleister haben. Ganz typischer Fall. Dann gibt's zwei Fälle. Erster Fall: Die Abhängigkeit tritt für alle Aufträge dieser Dienstleistung auf. Dann können wir das wie einen normalen Schritt in unserem Workflow behandeln.  Wichtig ist, dass wir dann hier auch mit einem WIP-Limit arbeiten, dazu später noch mehr. Dann machen wir unser Pull-System nicht kaputt. Und wir können steuern, dass wir den Dienstleister nicht überlasten – falls der nicht auch ein Kanban-System hat.

Im zweiten Fall müssen nur einige Arbeitsaufträge durch die externe Abhängigkeit. Im Optimalfall können wir das schon sehr früh, am besten vielleicht sogar schon am Eingang feststellen. Dann können wir den Mix stabil halten und können vorhersagbar bleiben. Da muss man aber ein bisschen aufpassen – da habe ich in der letzten Folge schon drüber gesprochen.

Auf dem Kanban-Board stellen wir das einfach mit einer Teilung des Flows dar – Tickets mit Abhängigkeit kommen auf eine Art Parkplatz und warten dort, bis sie wieder in unseren Flow eintreten dürfen. Die anderen wandern einfach an dem Parkplatz vorbei in Richtung Glückseligkeit.

So, ich sage, dass sie warten. De facto ist es ja aber häufig so, dass solche Abhängigkeiten super unzuverlässig sind. Also statt Termine zu halten, muss man x-mal nachfragen, damit das Ticket dann zurückkommt. Wenn es bei dir nicht so ist, super! Im sonstigen Fall sollten wir aber entweder mit dem Dienstleister ein Service-Level-Agreement abschließen. Dann können wir nämlich nach Ablauf der Zeit nachhaken, müssen uns vorher aber nicht darum kümmern.

Oder wir erheben selbst Daten über das Service-Level, das uns geboten wird. Das können wir dann nämlich schön in unseren eigenen Metriken berücksichtigen. Und mit solchen Daten kann man dann auch gut zum Dienstleister gehen und um Besserung bitten. Wenn Du denen dann noch meine Telefonnummer gibst, wird alles gut! Sicherheitshalber schreibe ich die mal in die Shownotes. Nur für den Fall der Fälle. :)

Jetzt werde ich häufig gefragt, ob man da auch ein WIP-Limit auf den Parkplatz legt. Die einfache Antwort ist natürlich "Ja. Wir wollen ja ein echtes Pull-System haben."

Die richtige Antwort ist "Kommt darauf an." Und zwar kommt es darauf an, ob wir denn damit umgehen können, wenn der Parkplatz voll läuft. Also wir haben ganz viele Sachen bei gegebenenfalls sogar unterschiedlichen Dienstleistern in einem Wartezustand. Wachsende Risiken und alles, wenn wir mehr neue Arbeit hinzunehmen. Aber – berücksichtigen wir unsere Obergrenze, würde es so aussehen, als würden WIR nicht weiterarbeiten, weil die ihre Arbeit nicht fertig bekommen. Da muss die Organisation reif genug sein, um damit umgehen zu können.

Aber eigentlich – wenn die Orga reif genug ist – wollen wir ja schon Auswirkungen auf unsere Auftragsannahme, wenn wir die Dienstleister nicht gemanagt bekommen. Klar, das WIP-Limit muss hoch genug gewählt werden, dass das nicht ständig auftritt. Wir sollten also ein gewisses Maß an Variabilität abbilden können. Meine Empfehlung ist hier, erst einmal mit einem nicht verbindlichen WIP-Limit zu starten. Also sowas wie ein Soft-Limit. Wie eine Kreidemarkierung. Mithilfe derer gucken  wir, ob die Grenze überschritten wird. Falls das der Fall ist, können wir dann noch aktiv eingreifen und unseren Fluss managen. Und dann in unserem Verbesserungsteil weitergehende Maßnahmen ergreifen.

Diese Maßnahmen – bei permanenten Abhängigkeiten – sollten darauf abzielen, die Menge an Arbeit und die Leistung dieses Sub-Arbeits-Systems bezüglich Geschwindigkeit und Vorhersagbarkeit zu steigern. Damit können wir Kanban übrigens supergut durch die Organisation hindurch wachsen lassen, wenn wir die Dienstleistung an Ort und Stelle belassen. Auch ein gern gewähltes Muster ist, die Tätigkeiten bei sich selbst durchzuführen. Das benötigt dann aber Wissensaufbau und Erlaubnis und eine wirtschaftliche Betrachtung, ob das überhaupt sinnvoll ist.

Jetzt habe ich noch gar nicht über die Nicht-Permanenten Abhängigkeiten gesprochen. Also Dinge, die immer nur mal so sporadisch auftreten. Die behandeln wir im Gegensatz zu den permanenten einfach als Ausnahmen. Also entweder auf dem physischen oder elektronischen Board einen Blockadesticky drauf. Wir klären am besten, wie lange wir auf Lösung warten müssen. Die WIP-Limits im System müssten das eigentlich aushalten, wenn man sich nicht superduper eng gefesselt hat. Kleine Beobachtung meinerseits: Hat niemand.

Wenn die Lösung dann gefunden wurde und das Ticket in den normalen Flow zurückkehrt, nehmen wir diese Blockade und heben sie auf. Das ist ja Input für unsere Risikobetrachtung! Wenn das einmal auftritt – geschenkt, Special-Cause-Variation. Wenn das mehrmals auftritt und sich ggf. in eine permanente, aber bis jetzt unvorhersagbare Abhängigkeit entwickelt, wollen wir das auf dem Schirm haben!

Fazit: Abhängigkeiten gehören zum Leben dazu. Wir müssen lernen, ordentlich damit umzugehen und sie möglichst auch vorhersagbar machen. Denk daran: Immer die Erwartungen und Bedürfnisse des Kunden im Blick behalten!

Permanente Abhängigkeiten versuchen wir genauso normal zu behandeln, wie sie es eben auch sind. Sporadisch auftretende Abhängigkeiten behandeln wir als Sonderfälle. Wir überlegen uns vielleicht, wie wir in Zukunft besser damit umgehen können, wenn sie auftreten. Wenn sie sich von sporadisch zu permanent ändern... das hatten wir ja schon.