Kanban ist eine evolutionäre Change-Management-Methode. Sie bietet die Möglichkeit, Schritt für Schritt zu lernen und zu erkennen, wo das Problem liegt. Damit schafft sie einen Rahmen zur kontinuierlichen Verbesserung. Statt ständig neue Aufgaben zu beginnen, liegt der Fokus darauf, angefangene Arbeiten zu beenden – ganz nach dem Kanban-Prinzip „Stop starting, start finishing.“

Kanban ist seit Jahren eine beliebte Methode in Organisationen. Es hilft, Prozesse zu visualisieren und in kurzen Iterationszyklen zu optimieren. Es lässt uns erkennen, wo die Probleme liegen und bietet Möglichkeiten, diese zu ändern. Kanban enthält Kaizen als festen Bestandteil und somit eine Kultur des kontinuierlichen Verbesserungsprozesses (siehe Infokasten unten).

Ein weiterer zentraler Bestandteil ist die Einführung einer Begrenzung der in Arbeit befindlichen Aufgaben, die sogenannten WIP (Work in Progress)-Limits. Diese sorgen für den nötigen Fokus, damit es vorangeht. Doch keine Angst, schon ein Kanban ohne WIP-Limits kann weiterhelfen. Diese sollten im Laufe der Zeit allerdings Einzug halten, sonst bleiben wir beim Proto-Kanban.

Es gibt sechs Prinzipien und sechs Praktiken, auf denen Kanban aufbaut. Um zu erklären, was Kanban ideal für das Change-Management macht, schauen wir uns die folgenden vier von sechs Prinzipien genauer an:

• Prinzip 1: Beginne mit dem, was Du jetzt tust.
• Prinzip 2: Vereinbare durch evolutionäre Veränderungen, eine Verbesserung anzustreben.
• Praktik 5: Feedback-Schleifen einführen.
• Praktik 6: Gemeinsam verbessern, experimentell weiterentwickeln.

Wir bilden das ab, was und wie wir es gerade tun (Prinzip 1). Danach unterhalten wir uns gemeinsam regelmäßig im Stand-up vorwiegend über Blockaden, messen Durchlaufzeiten (Prinzip 2) und unterhalten uns ein- bis zweimal monatlich in einer Retrospektive (Praktik 5) darüber, zu welchen Problemen es seit der vergangenen Retrospektive gekommen ist.

In der Retrospektive beleuchten wir die Gründe dieser Probleme und diskutieren die „gewinnbringendste“ Veränderung, die uns helfen würde, dieses Problem zu beheben. Wenn die Lösung nicht offensichtlich ist, führen wir probeweise einen Lösungsansatz in Form eines kleinen Experiments ein und schauen in der nächsten Retrospektive, ob dieser Erfolg gebracht hat. Wenn ja, wird dieser beibehalten, wenn nein, wieder zurückgerollt (Praktik 6). Hier ist darauf zu achten, dass Experimente klar und eindeutig definiert und beschrieben sind. Alte, verirrte oder verwaiste Experimente nerven und führen die Idee ad absurdum. Daher: kurz und knapp beschreiben und nachhalten ist die Devise!

Wir können also sehr schnell sehen ob wir Kanban machen oder nicht, denn nur was sich immer wieder verändert ist Kanban. So passen wir ein existierendes System nach und nach an eine andere oder neue Umwelt an.

Wenn Kanban in die DNA des Systems übergegangen ist, dann ergibt sich daraus der Effekt, dass dieses System sich automatisch und kontinuierlich an sich verändernde Umwelten anpasst. Genau das ist Evolution.

Kanban als Change-Methode macht überall dort Sinn, wo iterativ vorgegangen werden kann. Das ist häufiger, als man vermutet. Natürlich möchte man zum Beispiel bei lebenserhaltenden Maschinen auf der Intensivstation keine „Experimente“ machen. Es ist aber durchaus vorstellbar, dass nicht alle Intensivstationen eines Krankenhauskonzerns gleichzeitig auf eine neue Technik umgestellt werden, sondern in einer Station angefangen und dort dazu Erfahrung gesammelt wird. Auf Basis dieser Erfahrung wird dann eine zweite Station noch besser angepasst. Es wird also nicht für alle Stationen vorab geplant, sondern die initiale Planung bleibt schlank.

So könnte zwar eine Preisreduktion durch eine Großabnahme verloren gehen, allerdings ist die Möglichkeit einer Fehlplanung bzw. Fehlanpassung gering. Viele Change-Projekte werden entweder nie implementiert oder zurückgerollt. Und wenn es eine große Implementierung war, ist der Schaden und die Frustration immens.

Wir setzen uns daher nicht zwei Jahre zum Theoretisieren hin, sondern theoretisieren so viel wie nötig, um den ersten Schritt zu machen, Erkenntnisse zu sammeln und anschließend den zweiten Schritt zu planen.

Oftmals treten dadurch ganz neue Aspekte auf, die zuvor unsichtbar waren oder das Umfeld überrascht uns mit neuen Möglichkeiten oder technischen Errungenschaften.

Überall dort allerdings, wo ein experimentelles Vorgehen absolut unmöglich ist, wird Kanban nicht voll zum Zuge kommen können.

Die Kerneigenschaften (Prinzipien und Praktiken) von Kanban sind recht breit formuliert und geben keine Auskunft darüber, wo im Unternehmenskontext sich Kanban einbetten lässt. Trotzdem gibt es häufig den Irrtum, dass Kanban ein agiler Ansatz zur Team-Optimierung sei. Es kann durchaus auf Team-Ebene eingesetzt werden, es hat jedoch stets die gesamte Wertschöpfungskette im Blick. Um eine bessere Orientierung zu liefern, wo im Unternehmen Kanban eingesetzt werden kann, wurde das Modell der Flight Level entwickelt.

• Flight Level 1 – Operative Ebene
• Flight Level 2 – Koordination
• Flight Level 3 – Strategisches (Portfolio-)Management

Mit den drei Flight Levels ist es möglich, Kanban über die komplette Organisation zu skalieren und so das gesamte System dem evolutionären Wandel zu unterziehen.

Veränderung hat sehr viel mit einem Sicherheitsbedürfnis zu tun und dies ist ein persönliches Bedürfnis. In Systemen, in denen viele Menschen mit einem höheren Sicherheitsbedürfnis agieren, können Experimente ein sehr hilfreiches Mittel sein. Einen Schritt zu tun, von dem man weiß, dass er nach Implementierung kaum Chancen hat, wieder zurückgenommen zu werden, wird für einen sicherheitsbedürftigen Menschen Anlass zur Sorge sein. Ist der Schritt allerdings klein und als Experiment angelegt, ist die Implementierung vom erfolgreichen Ausgang des Experiments abhängig.

So haben die Kolleginnen und Kollegen die Sicherheit, dass nichts implementiert wird, was die Situation nicht verbessert. Das schafft Vertrauen.

Weiterhin wird nicht zu Anfang ein riesiges Konzept erarbeitet, was sehr viel gleichzeitig ändert. Das gibt den Menschen die Möglichkeit, mit der Veränderung mitzukommen und sich daran zu gewöhnen. Deswegen beginnt Kanban dort, wo wir aktuell sind: „Start where you are“ und geht in kleinen iterativen Schritten voran.

Als Kanban Coach wird man in den Retrospektiven oft gefragt, was denn ein vernünftiger nächster Schritt sein könnte. Das ist nicht immer einfach, denn werden die „falschen“ Schritte vorgeschlagen, also Schritte, die nicht dem Reifegrad des Systems entsprechen, werden Menschen überfordert und Vertrauen zerstört. Um zu erkennen, wo sich ein System im Reifegrad befindet, bringt Kanban das Kanban Maturity Model (KMM) mit, mit Hilfe dessen wir nicht nur den Reifegrad herausfinden, sondern auch sinnvolle von unsinnigen nächsten Schritten unterscheiden können.

Das kann ich natürlich nicht beantworten. Kanban bringt nur wenig mit, denn Kanban ist kein Framework wie z. B. Scrum. Wer Scrum nutzt kennt das: Ob ich besser werde oder nicht, erfahre ich aus den Messungen. Es geht dort viel um Storypoints, Velocity, Sprints und Planning. All das bringt Kanban nicht mit. Oh wie schön, keine Planung, keine Menge, die ich zusage, kein Schätzen und kein Sprintzeitraum –  kein Overhead!

Genau, nur Prinzipien und Praktiken bringt Kanban mit. Das bedeutet, aus diesen Einzelteilen wird nun ein eigenes Ruleset gestrickt (siehe Infokasten: Prinzip 6 und Praktik 4). Das ist viel und vor allem kontinuierliche Arbeit und damit Diskussion – am Anfang ist kaum etwas da und nach und nach haben wir unser eigenes genau angepasstes (und sich immer wieder anpassendes) Ruleset.

Wer diese Arbeit nicht investieren möchte oder eine Gruppe hat, die sich weder kontinuierlich einigen möchte noch kann, sollte es vermutlich besser lassen. Vielleicht ist ein fertiges Ruleset oder Framework dann besser. Wer sich nun allerdings denkt, dass dies ein guter Ansatz für ein System sein könnte, fragt sich vielleicht, wie ich messen soll, ob ich besser werde – ohne Schätzen, ohne Planen und ohne Sprintzeitraum. Da sage ich: Durchlaufzeit! Und darüber werde ich ein anderes Mal schreiben.

Infobox – Die wichtigsten Kanban-Elemente

Kanban kommt schlank daher und bringt nur wenige Prinzipien und Praktiken mit. Das eröffnet die Möglichkeit, Kanban in nahezu alle Systeme zu integrieren.

„Don’t get set into one form, adapt it and build your own, and let it grow, be like water.“

Über die Autorin:

Ich heiße Gina, lebe seit über 30 Jahren in Hamburg und beschäftige mich mit agilen Arbeitsmethoden und Organisationsentwicklung. Ich bin akkreditierte Kanban-Trainerin der Lean Kanban University und habe im Laufe meiner beruflichen Laufbahn einigen Firmen bei der agilen Transition geholfen. Bei intersoft bin ich seit über 2 Jahren als PO tätig und wirke dabei während der alltäglichen Arbeit auf die agile Transformation ein.

Während und nach meinem Meteorologie-Studium habe ich am Max-Planck-Institut für Meteorologie gearbeitet, wo ich mit der Open Source Welt in Kontakt kam. Seit 2003 war ich diesbezüglich stark engagiert, Vize Präsident der TYPO3 Association, danach ein Neos-Core-Team-Member und Direktorin der Neos Foundation.

Privat liebe ich es, durch die Welt zu reisen, zu schwimmen und Kajak zu fahren. Ich bin Tauchlehrerin, GUE Höhlentaucherin und segle ab und zu auf einem Traditionsschiff namens Windsbraut.

Klar, auch wir waren davon betroffen und haben kurzzeitig händeringend Personal gesucht, welches einerseits unsere bestehenden Bedarfe deckt, zeitgleich aber auch neue Ideen und Impulse mitbringen sollte – Veränderungsbereitschaft, Eigeninitiative, Kommunikationsgeschick und viel Flexibilität.

Klingt schwierig in der Tech-Branche, wenn man an Code in einem Legacy-System für Versicherungssoftware schreibt, der seit über 20 Jahren gefüttert wird, aber wir als Unternehmen und auch der Code sich weiterentwickeln wollen und sollen. Das Altbewährte hat für uns im Recruiting dann doch irgendwie nicht mehr geklappt und wir standen ohne neue Kollegen da. Für uns gab es nur noch eine Option: Veränderung.

Hohe Anforderungen noch höher geschraubt.

Im nächsten Schritt saßen wir mit unseren Teams vor den Personas und bemerkten, dass der Tellerrand, über den die potenziellen neuen Kollegen gucken sollten, ziiiiiemlich breit war. Kurz hatten wir das Gefühl, wir würden den Fachkräftemangel bei uns selbst noch befeuern, denn die Anforderungen haben wir mal so richtig hochgeschraubt. Abstriche konnten und wollten wir aber nicht mehr machen, denn dann würden wir nicht in die Veränderung kommen, die wir anstrebten. Was könnten wir ändern und wie konnten wir das bei der Personalsuche transportieren?

Wir waren einfach mutig und spontan. Alle zusammen.

Wir texteten all unsere Stellenausschreibungen neu. „Mehr ist mehr“ ist die neue Devise. Wir sind der Meinung, dass ein Bewerber vorab einen guten Überblick über sein tägliches Doing haben sollte. Wir änderten unsere Tonalität. Wir nahmen uns raus, den Bewerber mit einem „Du“ wieder anzusprechen. Unsere Werte und Stimmung ließen wir in den Ton zwischen den Zeilen einfließen, sodass man erahnen konnte, wer wir sind und wie wir ticken. Dabei blieben wir noch im Rahmen und nutzten ausreichend Buzzwords, sodass wir nicht komplett aus dem Google Raster fielen. Wir erlaubten uns, Stellenausschreibungen für die Rolle der Eier legenden Wollmilchsau zu veröffentlichen und waren damit recht risikofreudig. Aber ohne Veränderung „im“ Innen gäbe es keine Veränderung „nach“ Innen, wenn wir nicht zumindest versuchen würden, diese seltenen Exemplare zu finden und für uns zu gewinnen. Anders machen, kann man danach immer noch.

Wir hörten zu. Wir fragten die Bewerber, was sie brauchten und sich wünschten.

Den heiß geliebten Recruiting-Prozess lockerten wir bewerberorientiert auf und fanden selbst so mehr Flexibilität. Wir erlaubten uns zusätzliche Interviews und wieder mehr Interviews vor Ort. Wir nahmen uns für die Fragen der Bewerber auch zwischen den Gesprächen viel mehr Zeit. Wir lösten uns von dem „Muss“, dass immer ein Recruiter in den Interviews dabei sein sollte. Stattdessen vertrauten wir darauf, dass unsere Führungskräfte auch selbst die Kompetenz besaßen, einzuschätzen, ob ein Bewerber ins Team, zu den Anforderungen und zu intersoft passt. Sie hatten die Fähigkeit entwickelt, die Bewerber in offenen Dialogen durch die Gespräche zu führen, sodass auch die Kandidaten ihren eigenen Teil dazu beizutragen würden. So konnten wir unseren Prozess auch deutlich beschleunigen, weil wir zeitgleich mehrere Interviews führen konnten.

Plötzlich war er vorbei …

… bei uns, der freche kleine Fachkräftemangel. 2024 konnten wir bereits im ersten Halbjahr unser Jahresziel erreichen, sowie bereits die Personalbesetzung für das erste Quartal 2025 mit abdecken. Man redet zwar noch über ihn, aber man spürt ihn nicht mehr so sehr, wenn man die Fülle der Möglichkeiten zur Veränderung erkennt.

Über die Autorin:

Ich bin Miriam, 42 Jahre jung, seit 5 Jahren Recruiterin bei intersoft. Nach über 15 Jahren in der Marketingwelt, zuletzt als Projektmanagerin in Führungsrolle, entdeckte ich meine Leidenschaft für die Zusammenarbeit mit Menschen und das Personal-Recruiting. Nach einer nebenberuflichen Ausbildung zur Heilpraktikerin für Psychotherapie wagte ich 2017 den Sprung ins kalte Wasser und startete direkt von 0 auf 100 als In-House-Recruiterin durch. Seit 2020 bin ich glückliche Recruiterin bei intersoft und lebe und liebe meinen Job – Die Vielfältigkeit, Spontanität, Flexibilität, Möglichkeiten zur Selbst- und Weiterentwicklung, vor allem aber die Menschen und diese zusammenzubringen.

Das Gradle Feature „Composite Build“ ermöglicht es getrennt entwickelte Projekte als eines zu betrachten. Die Projekte werden dabei automatisch in der richtigen Reihenfolge gebaut. Abhängigkeiten werden ohne den Zwischenschritt eines Maven-Repositories aufgelöst. Auch in IDEs bietet es große Vorteile, indem z. B. Refactorings projektübergreifend durchgeführt werden können. Wir haben es vor kurzem zum ersten Mal auf unseren Projekten angewandt und berichten hier von unseren Erfahrungen.

Unsere monolithische Anwendung lifestream classic soll in kleinere Projekte aufgeteilt werden. Die Anwendung bleibt bestehen, aber Teilkomponenten sollen herauswandern und dadurch besser isoliert und wartbarer werden. So werden aus Gradle Subprojekten eigenständige Projekte, die als Modul-Abhängigkeiten in lifestream classic eingebunden werden.

Den ersten Schritt sind wir vor kurzem gegangen und haben einige Module der untersten Schicht in ein eigenes Projekt verschoben. Wir nennen es die technische Plattform intersoft, kurz TPI.

Für den Buildprozess haben wir bereits einige Gradle Convention-Plugins eingesetzt. Convention Plugins in Gradle ermöglichen es, Buildlogik global wiederverwendbar zur Verfügung zu stellen. Davon haben wir bereits vor der Umstrukturierung Gebrauch gemacht, bis dahin aber im selben Projekt unter dem buildSrc-Subprojekt verwaltet. Um die Convention-Plugins in beiden Projekten anwenden zu können, haben wir sie ebenfalls ausgelagert. Sie liegen jetzt im Projekt lifestream-gradle-conventions.

Zusammengefasst haben wir jetzt also drei Projekte:

• lifestream Classic – unser Hauptprodukt
• die technische Plattform – die Basis für lifestream und die herauszulösenden Teilkomponenten
• Eine Sammlung an Convention-Plugins, die den Build gleichartiger Module in den Projekten beschreibt.

Die herausgelösten Projekte sind jetzt klein und gut wartbar. Durch kleinere Projekte sind Builds schneller durchführbar. Doch was ist, wenn wir in einem der Projekte etwas ändern, was zu Anpassungen in einem nachfolgenden Projekt führt? Der übliche Weg wäre, die Anpassungen in Projekt A durchzuführen, eine neue (Snapshot-)Version zu bauen und diese in Projekt B als Abhängigkeit einzutragen. Anschließend wären in Projekt B die nötigen Anpassungen vorzunehmen. Fallen noch Fehler auf, wiederholen wir die Schritte so oft, bis das gewünschte Ergebnis erreicht ist. Klingt ineffizient? Ist es auch …

Hier kommt das Composite Build Feature von Gradle ins Spiel. Mit diesem Feature ist es möglich, Modul-Dependencies durch ein lokales Gradle-Projekt zu substituieren. Gradle erkennt dann automatisch anhand der GAV (Maven-Koordinaten), dass Abhängigkeiten durch die Artefakte eines lokal eingebundenen Projekts aufgelöst werden können.

Im Folgenden erklären wir, wie wir dieses Feature auf unsere eigenen Projekte angewandt haben. Wir nutzen es, um projektübergreifende Refactorings einfacher durchführen zu können.

Die einfachste Möglichkeit, einen Composite Build durchzuführen, ist über die Kommandozeile:

Alternativ können wir das auch fest in der settings.gradle eines Projekts konfigurieren:

Das bietet sich an, wenn das gleiche Set an Projekten immer zusammen gebaut werden soll.

In unserem Projekt soll der Composite Build jedoch nur eine Option sein. Dazu verknüpfen wir das Inkludieren der Projekte an Properties, welche in einer separaten Konfigurationsdatei im Workspace zu setzen sind. Die Properties definieren, wo diese Projekte liegen. Ist die Property nicht gesetzt, findet kein Composite Build statt. Wir ermöglichen den Entwickler:innen, so die Projekte in einem lokalen Workspace fest zu inkludieren, ohne dafür Dateien unter Versionskontrolle anpassen zu müssen.

Das haben wir in einem Settings-Plugin umgesetzt und (zunächst – wir kommen gleich noch einmal drauf zurück) ebenfalls über das Convention-Plugin bereitgestellt.

Öffnen Entwickler:innen das Projekt in einer IDE mit Gradle-Support (getestet mit IntelliJ und Eclipse), nimmt die IDE die inkludierten Projekte automatisch in den Workspace auf. Refactorings wirken sich dann projektübergreifend aus.

Im Normalfall sollten die oben beschriebenen Schritte ausreichen, um bereits effektiv mit dem Composite Build Feature arbeiten zu können.

In unserem Projekt haben wir aber auch einige Module, welche von der Standard Java Buildlogik in Gradle abweichen. Deshalb war der Composite Build bei uns zunächst nicht einsetzbar. Folgende Punkte sind daher zum Tragen gekommen und bedurften Anpassungen.

Problem 1 – Das projektübergreifende Auflösen von Artefakten funktioniert nur, wenn diese in der Default-Konfiguration von Gradle veröffentlicht wurden.

In unseren Projekten waren vereinzelt eigene Konfigurationen definiert, zu denen der Build Artefakte veröffentlicht. Die haben in der bisherigen Form nicht mit dem Composite-Build funktioniert. Hier ein Beispiel:

Abhilfe hat die Variante aware API von Gradle geschafft. Anstatt die Artefakte aus eigenen Konfigurationen zu publishen, werden sie als Variation zur Default-Konfiguration hinzugefügt und darüber gepublisht.

Dafür sind folgende Schritte notwendig:

1. Die bestehenden Konfigurationen mit Variant-Attributen versehen.
2. Publishing der Custom-Konfigurationen entfernen.
3. Artefakte der Konfigurationen zur Default-Konfiguration hinzufügen.
4. In abhängigen Projekten die Dependency-Konfiguration um das attributesSchema ergänzen.
5. Bonus: In der Repository-Konfiguration gradleMetadata() ergänzen, wenn vom Default abgewichen wurde.

Problem 2 – Der Composite Build für das Convention-Plugin funktioniert nicht, wenn das anwendende Settings-Plugin im selben Artefakt releast wird.

Hintergrund ist (mutmaßlich), dass der Build bereits während der Initilization-Phase des Builds das Artefakt des Plugins auflöst. Dadurch überschreibt der Composite Build die Klassen nicht.

Zur Lösung haben wir das Projekt der Convention-Plugins aufgeteilt und das Settings-Plugin in ein eigenes Projekt verschoben. Dadurch muss Gradle nur das Artefakt der Settings-Plugins zur Initializations-Phase auflösen. Die Convention-Plugins sind in einem eigenen Artefakt und können wieder durch den Composite Build überschrieben werden.

Das Composite Build Feature kann projektübergreifende Arbeiten stark erleichtern. Je nachdem, wie ein Projekt aufgesetzt ist, sind aber Anpassungen notwendig, um das Feature effektiv nutzen zu können.

• Custom-Artefakte sollten mittels Variant Aware API der Default-Konfiguration hinzugefügt werden.
  Beim Publishing werden sie dadurch automatisch berücksichtigt und der Composite-Build kann die Auflösung korrekt auf lokale Artefakte umleiten.
• Ein Settings-Plugin um den Composite-Build zu konfigurieren, sollte unabhängig von anderen Convention-Plugins entwickelt werden.
  Dadurch sind die Convention-Plugins separat publiziert und können ohne Einschränkung mittels Composite-Build live entwickelt und getestet werden.

• • https://docs.gradle.org/current/userguide/composite_builds.html
  • https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:sharing_logic_via_convention_plugins
  • https://docs.gradle.org/current/userguide/custom_plugins.html#project_vs_settings_vs_init_plugins
  • https://docs.gradle.org/current/userguide/variant_attributes.html
  • Bilder: https://www.shutterstock.com/

Über den Autor:

Hi, ich bin Helge! Ursprünglich in Hamburg geboren, wohne ich seit 2019 mit meiner Familie in Wedel.

Bei intersoft bin ich seit über 15 Jahren an der Bereitstellung und Gestaltung von Infrastruktur und Prozessen rund um Build und Deployment unserer Software-Produkte beteiligt. Der Markt hat sich in dieser Zeit stark weiterentwickelt, sodass ich das heute als DevOps-Engineer in einem Kubernetes-Umfeld tue.

Auch privat interessiere ich mich für neue Technologien und probiere gern in kleinen Projekten das eine oder andere aus.

Über den Autor:

Ich bin Lennart, 38 Jahre alt und bei intersoft als DevOps-Engineer im Team „Developer Productivity Engineering“ (DPE) tätig.

Unser Team kümmert sich um die Prozesse und Werkzeuge, welche den Entwicklungsprozess möglich machen. Also alles von der Versionkontrollverwaltung, über den Build-Prozess bis hin zum Deployment.

Meine Firmenzugehörigkeit hat sich gerade zum 20. mal gejährt. In dieser Zeit hat sich technologisch einiges weiterentwickelt. Wir bauen unsere Software nicht mehr mit Apache Ant, sondern mit Gradle, statt CVS oder SVN nutzen wir Git für die Versionskontrolle und wir deployen unsere Software als Container in Kubernetes, statt in einem Weblogic. Solche Herausforderungen sind es, durch die die Arbeit niemals langweilig wird und es ist eine große Freude an diesen Entwicklungen mitzuwirken.

Aufgewachsen im Osnabrücker Land, bin ich 2004 nach Hamburg gezogen. Mit meiner Frau und meinen zwei Kindern leben wir inzwischen seit einigen Jahren in Quickborn im Norden Hamburgs (ja genau, da wo Mike Krüger herkommt).

Kanban ist nicht nur ein Projektmanagement-Tool, sondern eine evolutionäre Change Management Methode. Sie ist heute so aktuell, wie nie zuvor. Für welche Aufgaben Kanban optimal geeignet ist und wie das Ganze funktioniert, erfahrt ihr hier. 

Kanban kann vieles verändern zum Beispiel auch das Projektmanagement. Im Projektmanagement ist eines der häufigsten Probleme ein unübersichtlicher, nicht zu bewältigender Workload.

Da stapeln sich die To-Dos, diverse Aufgaben sollen parallel erledigt werden und beim nächsten Statusmeeting stellt man fest, das nichts wirklich fertig geworden ist.
Genau an diesem Punkt setzt Kanban ein. Kanban verändert die Dinge, die wir damit abbilden. Damit ist es eine optimale Methode zur Optimierung von Workflows und Arbeitspaketen. Ihr wichtigstes Prinzip ist die Visualisierung und die Konzentration auf einige wenige Aufgaben, die gleichzeitig bearbeitet werden. Um dieses Ziel zu erreichen, nutzt das Kanban-System einfache, aber effektive Methoden.

Bevor wir in die Tiefen von Kanban gehen, lohnt sich ein kurzer Blick zurück. Bereits in den 1940er Jahren hat der japanische Autohersteller Toyota die „Just-in-Time“ Produktion eingeführt, um seine Effektivität zu steigern. Dieses Ziel wurde unter anderem durch die Einführung eines einfachen Diagramms erreicht, das der Organisation des Materials und der Arbeitsabläufe diente – die Geburtsstunde der Kanban-Boards.
Der Begriff „Kan Ban“ stammt aus dem Japanischen und bedeutet „Karte“ oder auch „Schild“. Auf dieser Karte, dem Board, werden die Aufgaben und ihr jeweiliger Status für alle deutlich visualisiert. So kann jeder im Team, immer sofort erkennen, wo man sich im Prozess befindet, an welchen Aufgaben gearbeitet wird und wo möglicherweise Material-Engpässe sind. Diese Neuerung war für das Unternehmen Toyota damals ein bahnbrechender Erfolg.

Ein Kanban-Board ist die bereits erwähnte Visualisierung eines Projektes in mehrere Spalten. Im einfachsten Fall heißen die Spalten beispielsweise „To-Dos“, „In Arbeit“ und „Erledigt.“ Jedes To-Do wird am Anfang auf eine Karte geschrieben und in der ganz linken Spalte platziert. Im Laufe eines Projektes „bewegen“ sich diese Kanban-Karten dann nach rechts durch die Spalten hindurch.

Wenn im Team entschieden wird, dass To-Do A bearbeitet werden soll, dann wird die entsprechende Karte eine Spalte weiter in den Bereich „in Arbeit“ geschoben. Später nach Abschluss der Tätigkeit wandert sie schließlich weiter in den Bereich „erledigt.“ Wichtig ist dabei, dass es ein Limit gleichzeitig zu bearbeitender Aufgaben gibt, damit die Effizienz gewährleistet werden kann. Im Bereich „in Arbeit“ können so zum Beispiel maximal fünf Kanban-Karten gleichzeitig sein.

Ein Kanban-Board passt sich im Laufe der Zeit dem Prozess an. Es bildet also den genauen Wertschöpfungsprozess ab. Reife Kanban-Boards haben oft „Ready-to“-Spalten, in denen klar zu erkennen ist, ob hier ein „Stau“ entsteht. Denn Kanban optimiert auf Durchlaufzeiten und legt damit viel Augenmerk auf Blockaden. Daher haben Kanban-Boards in der Regel mehr Spalten als Boards, die in Scrum genutzt werden.

Prinzipiell folgen Kanban-Boards auch heute noch der gleichen Logik, wie zu ihren Anfängen in der Produktion von Toyota. Im Zentrum stehen noch immer die Visualisierung und der transparente, schnelle Durchlauf von Tasks. Doch im Laufe der Zeit wurde die Methodik in ungezählten Praxistests angereichert, optimiert und durch einige bekannte Prinzipien ergänzt. Ganz besonderen Schwung hat das Thema im Agile Kontext erhalten und durch die Anpassung an die moderne IT geradezu eine Wiederbelebung erfahren.

Der entscheidende Input dafür stammt von David J. Anderson, der 2007 in seiner Kanban-Definition ein auf inzwischen sechs Prinzipien und sechs Methoden basierendes System vorstellte. Seither hat natürlich auch hier eine Weiterentwicklung stattgefunden. Die Grundgedanken von David Anderson, die ja ihrerseits eine Weiterentwicklung des ursprünglichen Systems sind, gelten für alle Kanban-Projekte.

Der Regelkreis des Kanban-Prinzips dreht sich um diese sechs Elemente:

1. Visualisierung: die Darstellung des Projektworkflows
2. Arbeit begrenzen und Limits einhalten: Ein Maximum definieren, damit nicht an zu vielen Aufgaben parallel gearbeitet wird (Effizienz).
3. Workflow-Management: Definition von Regeln und Fokus auf konstantem, schnellen Durchfluss von Kanban-Karten
4. Regeln und Continuous Improvement etablieren: Einhaltung der vereinbarten Regeln und regelmäßiges, offenes Feedback zu allen Elementen des Projekts.
5. Leadership / Verantwortung auf allen Ebenen: Klare Verantwortlichkeiten bei möglichst hohem Grad von Eigenverantwortung etablieren.
6. Zusammenarbeit optimieren: Mit Hilfe von Spielregeln, Modellen und wissenschaftlichen Methoden das Teamwork verbessern.

Weitere gängige Standards sind zum Beispiel tägliche Standup-Meetings am Kanban Board, das Replenishment, sowie regelmäßige Operation Reviews und die weiteren sogenannten Kanban-Kadenzen. Alle Kadenzen haben sich bewährt, gehören aber nicht verpflichtend zum Regelkreis.

Das größte Plus bei der Anwendung von Kanban ist seine Einfachheit. Die Regeln und Prinzipien sind überschaubar und dennoch hat das System bei richtiger Anwendung einen enormen Effekt. Durch die Visualisierung und die Reduktion auf eine machbare Anzahl paralleler Tätigkeiten wird der Managementaufwand reduziert und gleichzeitig die Geschwindigkeit erhöht, mit der Aufgaben abgearbeitet werden. Diese Geschwindigkeit ist als „mittlere Durchlaufzeit“ messbar und kann dann sogar als KPI herhalten.

Ein großes Plus ist zudem die hohe Flexibilität bei neuen Anforderungen und Scope-Änderungen. Dadurch, dass regelmäßig neu entschieden wird, welche Kanban-Karten weiterbewegt werden und das Backlog ohne Priorität daherkommt, kann schnell auf solche Änderungen reagiert werden. Die Reaktionszeit kann den Wochensprint in Scrum übertreffen.

Allerdings hat ein einfaches Kanban-System auch seine Grenzen. Bei langwierigen und sehr komplexen Projekten mit vielen Abhängigkeiten reichen die Informationen auf einem Kanban-Board nicht mehr aus. Hier ist eine Implementation von Upstream-Kanban oder von Kanban in mehreren Flightleveln sinnvoll oder notwendig (dazu mehr in meinen anderen Artikeln hier im Blog).

Weiterhin muss das Team willens sein, die Regeln selbst auszuarbeiten und einzuhalten (Kanban ist kein Framework wie Scrum). Das bedeutet ebenfalls, dass ein Regelwerk nicht nur erschaffen werden, sondern dann kontinuierlich überarbeitet werden muss – das bedeutet viel Diskussion und Konsequenz.

Es lohnt sich fast für alle Teams und Unternehmen, das Kanban-System zumindest einmal auszuprobieren. Der Vorteil der Methode ist gerade seine Einfachheit. Am besten nimmt man zu Beginn eine freie Fläche und klebt die entsprechenden Spalten ab. Mit Post-Its heftet man dann die anstehenden Aufgaben und Informationen eines Projektes daneben wie bei einer To-Do-Liste. Das geht natürlich auch bestens virtuell.

Dann sollte in einem Meeting mit dem gesamten Team das Regelwerk besprochen und festgehalten werden. Das kann gerne auf einem Flipchart oder digitalen Board passieren, damit die Grundregeln gut sichtbar und alle bekannt sind. Nun kann es schon losgehen und die ersten Kanban-Karten können in die „in Arbeit“-Spalte bewegt werden – voilà.

Dies hier ist, wie ihr bemerkt, der allererste Überblick. Wenn ihr Kanban ernsthaft ausprobieren wollt, empfehle ich euch meinen nächsten Artikel – er ist bereits in Arbeit, bleibt also dabei, es kommt noch mehr!

Nice to have: Kanban eignet sich besonders gut fürs Change Management.

Über die Autorin:

Ich heiße Gina, lebe seit über 30 Jahren in Hamburg und beschäftige mich mit agilen Arbeitsmethoden und Organisationsentwicklung. Ich bin akkreditierte Kanban-Trainerin der Lean Kanban University und habe im Laufe meiner beruflichen Laufbahn einigen Firmen bei der agilen Transition geholfen. Bei intersoft bin ich seit über 2 Jahren als PO tätig und wirke dabei während der alltäglichen Arbeit auf die agile Transformation ein.

Während und nach meinem Meteorologie-Studium habe ich am Max-Planck-Institut für Meteorologie gearbeitet, wo ich mit der Open Source Welt in Kontakt kam. Seit 2003 war ich diesbezüglich stark engagiert, Vize Präsident der TYPO3 Association, danach ein Neos-Core-Team-Member und Direktorin der Neos Foundation.

Privat liebe ich es, durch die Welt zu reisen, zu schwimmen und Kajak zu fahren. Ich bin Tauchlehrerin, GUE Höhlentaucherin und segle ab und zu auf einem Traditionsschiff namens Windsbraut.

Lotte: Du sag mal, du bist doch jetzt schon länger hier. Bleibt das Arbeitsklima eigentlich immer so locker?

Dennis: Ja, es ist für mich bisher auch immer so angenehm geblieben. Ich hatte bereits seit meinem Bewerbungsgespräch das Gefühl, mich nicht unterordnen zu müssen und viel mehr, dass sich mein Bewerbungsanliegen sehr unvoreingenommen angehört wurde.

Lotte: Das habe ich auch so empfunden. Die Atmosphäre im Bewerbungsgespräch fand ich sehr entspannt und auf Augenhöhe. Ich habe auch keine klassischen Personalfragen gestellt bekommen, die prüfen sollen, wie ich unter Stress reagiere. Stattdessen konnte ich viel über meinen Werdegang erzählen, da ich ja schon einige Jahre Berufserfahrung habe, und so schauen, ob und wie ich in die Firma passe.

Dennis: Stimmt, bei mir war es ähnlich. Alles im Gespräch hatte mir gerade deshalb auch den Eindruck gegeben, dass die Kontaktpersonen bei der intersoft wirklich an mir interessiert waren und daran, mir die Welt der intersoft zu zeigen. Und auch wenn es ein sehr angenehmes, entspanntes Klima war, waren die Prozesse rundum sehr strukturiert und gut organisiert. Ich konnte zum Beispiel allen Vorgesprächen online beiwohnen, als ich noch nicht in Hamburg gewohnt habe. Und eines der Bewerbungsgespräche in Präsenz wurde dann auch wirklich genutzt, damit die intersoft ihre Teammitglieder, Arbeitsweisen und Räume und sogar die Arbeit selbst vorstellen kann.

Lotte: Ja, die Organisation war großartig. Antworten kamen postwendend und ich wurde sehr schnell und transparent zwischen den Gesprächen über alle Schritte informiert. Ich habe knapp drei Wochen nach dem ersten Blick auf die Anzeige bereits eine positive Rückmeldung erhalten. Es ging also alles sehr schnell.

Dennis: Das ging bei mir auch so schnell. Ich war sehr froh, dass ich über das Jobcenter auf die Anzeige aufmerksam wurde. Wie bist du eigentlich auf die Anzeige gekommen?

Lotte: Ich habe auf monster.de eine Jobanzeige von einer Personalvermittlung gefunden, nur zufällig, ohne auf der Suche nach einer Veränderung zu sein, da ich in meinem vorherigen Job sehr zufrieden war. Trotzdem bin ich jetzt froh, hier zu sein.

Dennis: Was hat dich an der Jobanzeige angesprochen, obwohl du in Deinem vorherigen Job schon zufrieden warst?

Lotte: Die Stellenbeschreibung hat genau die Tätigkeiten genannt, die ich sowieso schon gemacht habe, sodass ich meine Kompetenzen in der Richtung ausbauen kann und hat zusätzlich wieder mehr Fachwissen in der Versicherungstechnik erfordert, woher ich ursprünglich komme. Also eine hervorragende Gelegenheit, vergangene und aktuelle Kompetenzen wieder zusammen zu bringen und gewinnbringend einzusetzen.

Lotte: Wie war dann Dein Einstieg in den Job? Hat sich das positive Gefühl aus dem Bewerbungsgespräch bestätigt?

Dennis: Am Anfang war alles erst einmal sehr viel, das kommt aber alleine schon davon, dass dies mein erster Job nach der Uni ist. Also viele neue Dinge lernen, viele neue Namen von Menschen und Systemen, viele neue Prozesse. Meine Teammitglieder haben mir aber von Anfang an das Gefühl gegeben, dass ich nicht gleich alles beherrschen muss. Trotzdem wurde ich bereits in viele Strukturen wie Meetings und Technik eingegliedert, damit ich frei vom Rande erst einmal zugucken, lernen und meine Fragen stellen konnte. Du hast ja schon mehr Berufserfahrung, wie war der Anfang für Dich?

Lotte: Meine erste Woche war toll! Ich wurde sehr herzlich empfangen, am zweiten Tag gab es zufälligerweise ein Teamevent, was für mich wahnsinnig schön war, da ich alle Teammitglieder gleich persönlich und in lockerer Atmosphäre kennenlernen konnte. Die Einarbeitung war super strukturiert, es gab einen guten Plan und ich habe mich schnell in die Themen reinfinden können. Ich habe sehr viel aus meinen vorherigen Tätigkeiten wiedererkannt. Vieles ist bekannt, aber die Details und die konkreten Umsetzungen der Themen sind dann doch zum Teil ganz anders als bei meinen bisherigen Tätigkeiten. Also viel Bekanntes, aber auch viel Neues, eine gute Mischung. Was war für Dich komplett neu?

Dennis: Viele Dinge! Im Studium habe ich eine Vorliebe für abstrakte, wenig praktische Theorien entwickelt, was jedoch in einer Softwarefirma maximal in der Methodik Anwendung findet. Die Komplexität der Themen kommt eher von den Versicherungsgrundlagen, mit welchen ich vorher nur in sehr geringem Ausmaß Kontakt hatte, es war also eine Herausforderung, mich diesen anzunähern. Die technische Entwicklungsseite ist für mich zudem immer noch etwas fremd, aber meine Vorkenntnisse aus dem Studium helfen schnell, die Programmierung für mich verständlicher zu machen. Wie lief es mit der Eingewöhnung in Dein neues Team?

Lotte: Die Eingewöhnung ins Team fing etwas ungewöhnlich an, denn schon in meiner zweiten Woche wurden die Teams neu zusammengestellt. Ich habe also am Anfang schon gewusst, dass das Team in dem ich anfange nicht das Team sein würde, in dem ich weiterhin bleibe. Aber auch das war eine spanndende Erfahrung und ich bin sehr zufrieden mit der neuen Teamzusammenstellung. In dem ganzen anfänglichen Chaos habe ich trotzdem immer eine sehr angenehme, offene und herzliche Atmosphäre wahrgenommen und habe mich sehr gut aufgenommen gefühlt. Die Teammitglieder sind alle bereit, Zeit in die Einarbeitung zu investieren und begegnen mir auf Augenhöhe. Hast Du das auch so erlebt?

Dennis: Ja, das passt. Die lockere Arbeitskultur und der Fokus der Anderen auf die Einarbeitung haben es mir sehr erleichtert, mich in der Teamstruktur willkommen zu fühlen und mich schnell als Teil von ihnen zu sehen. Die Arbeitsabläufe wurden auch schnell vergleichbar und haben mir ermöglicht, in engen themenorientierten Austausch zu kommen. Es wurde auch viel Zeit in teambildende Maßnahmen gesteckt, welche das Teamverständnis allgemein verstärkt haben.

Lotte: Womit hast Du Dich eigentlich in Deiner Einarbeitungszeit beschäftigt?

Dennis: Das ist eine sehr spannende Frage.

Ich hatte vor meinem eigentlichen Einarbeitungsthema eher kleinere Aufgaben übernommen, da mir noch die grobe Arbeitsweise und Unternehmensstruktur vorgestellt wurde. Mein eigentliches Einarbeitungsthema hat sich bei einem Sterbegeldprodukte der WWK damit beschäftigt, was passiert, wenn die Sterbetafel zu Ende ist. Die Sterbetafel ist dabei eine Tabelle in der abgelegt wird, mit welcher Wahrscheinlichkeit eine Person eines gewissen Alters stirbt und die Besonderheit des Produktes war, dass der Vertrag nicht ohne den Tod der Person abgelöst wird, die Sterbetafel aber trotzdem zu Ende geht. Verträge, welche also laut Sterbetafel zu Ende waren, mussten im System aber trotzdem geführt werden können.

Als erstes wurde mir aufgetragen, einmal durch die Fachkonzepte zu gehen und zu schauen, welche Stellen betroffen sind, wenn man auf die Sterbewahrscheinlichkeit keinen Zugriff hat. Grundsätzlich musste man sich dabei nebenbei natürlich überlegen, wie man diese Stellen auch anpassen müsste. Weiterführend wurde dann mit anderen Teams und dem Kunden weitere Anforderungen geklärt. Da ich mit einer anderen Person daran gearbeitet habe, hatte ich Unterstützung bekommen, die für mich unbekannten Begriffe zu klären und einzuordnen und die Teile der Anpassungen, welche von mir stammten, zu kontrollieren. Bis das alles gesessen hat, musste natürlich einiges geklärt werden und, wie sich später herausstellte, auch noch während des eigentlichen Umsetzungsschritts. Nichtsdestotrotz wurde nach fertiger Konzeption den Entwickelnden die Anpassungen nähergebracht, sodass diese die Änderungen in den Softwarecode überführen konnten.

Dies war zumindest mein erstes großes Thema. Es war sehr interessant zu sehen, wie so ein Umsetzungsschritt bei Software wirklich intern aussieht und ich konnte, neben den Inhalten und der Kommunikation vieles über den gesamten Prozess lernen für meine zukünftigen Arbeiten.

Lotte: Interessant. Hattest Du viele Möglichkeiten, andere zu fragen, wenn bei dem ganzen Themenkomplex etwas unklar war?

Dennis: Ja, das hatte ich zum Glück. Eine der primären Möglichkeiten ist es natürlich, seine Fragen beim Team loszuwerden, da nimmt sich auch niemand raus und Zeit findet sich dafür immer irgendwie. Meine Teammitglieder haben mir die Dinge anfangs sehr simpel, später aber auch mit steigender Komplexität erklärt. Das ist mir sehr wichtig gewesen, da ich bisher keinen Versicherungshintergrund in meiner Ausbildung erlangen konnte. Falls mal doch nicht sofort Zeit gefunden werden konnte, wurden mir andere Wege gezeigt, wie ich mich erst mal selbst mit einem Thema auseinandersetzen kann. Welche Möglichkeiten hast Du für Dich gefunden, um selbst weiterzukommen?

Lotte: Das firmeninterne Wiki kann da zum Beispiel einige Hilfestellung geben. Mit meiner Vorerfahrung im Versicherungswesen konnte ich aber auch schon gut in den Fachkonzepten recherchieren und dann immer noch schauen, wer mir zusätzliche Fragen beantworten kann. Meine Fragen haben immer ein offenes Ohr gefunden und wurden kompetent beantwortet.

Dennis: Hattest du bisher das Gefühl, dass es nicht schlimm ist, wenn du soviel fragst? Ich hatte aufgrund der offenen Kommunikation hier in der Firma keine versteckte Erwartungshaltung mitbekommen und würde gerne Deinen Eindruck hören.

Lotte: Ich habe keine konkreten Erwartungen wahrgenommen, eher ein neugieriges Interesse, was ich in das Unternehmen einbringen kann. Ich weiß die gegenseitige Unterstützung sehr zu schätzen insbesondere die Reviews innerhalb des Teams empfinde ich als sehr konstruktiv und gewinnbringend.

Dennis: Es ist klar, dass jeder mal Fehler macht und nicht immer performant arbeiten kann, aber die Aufgaben werden trotzdem zielstrebig und mit Bedacht gelöst. Und um Fehler abzusichern, hat man einige Strukturen wie Regelmeetings oder nachträgliche Qualitätssicherung, um die Aufgabenbearbeitung transparent und offen für mehr Meinungen zu machen, welche bisher auch nie in meine Richtung von oben herab formuliert wurden.

Lotte: Dann lass uns schauen, wie wir jetzt weiter nützliches Wissen und spannende neue Erfahrungen abgreifen können.

Wir lachen und gehen wieder an unseren Arbeitsplatz mit der Gewissheit, dass wir jeden Tag neue Herausforderungen und ein angenehmes Miteinander finden werden.

Über die Autorin:

Ich habe in Berlin und Stuttgart Mathematik studiert und habe 2003 als Diplom-Mathematiker in Hamburg bei der Volksfürsorge, später Generali angefangen. Dort habe ich im Aktuariat und in der Bestandsverwaltung gearbeitet und habe nebenher meine Ausbildung zum Aktuar DAV absolviert. 2018 bin ich zu dem Unternehmen IT-workbench gewechselt, welche Softwareentwicklung für Versicherungsunternehmen anbieten und habe so den technischen Teil der Versicherungswelt kennengelernt. Seit dem 01.06.2024 bin ich bei intersoft als Business Analyst angestellt und kann die fachliche und technische Seite aus meinen Erfahrungen vereinen und einbringen.

Über den Autor:

Ich bin Dennis und ich habe an der TU Berlin 2023 meinen Mathematik-Master abgeschlossen. Nachdem ich einige Zeit mit Nachhilfe in Rostock verbracht habe, zog es mich nach Hamburg, wo ich ab Januar 2024 eine Stelle als Business Analyst bei der intersoft besetzen kann. Dabei steht für mich der fachliche Fokus im Vordergrund, aber auch mit der technischen Entwicklungsseite werde ich mehr konfrontiert.

Außerhalb der Arbeit findet man mich auch vor einem PC sitzend, da ich sehr gerne Videospiele spiele, aber auch gerne mal analoge Tabletop-Rollenspiele.

Bild KI generiert mit Shutterstock am ‎27. September ‎2024

Dieser Beitrag richtet sich sowohl an DevOps-Spezialisten als auch an technisch interessierte Leser, die sich mit Kubernetes und der Automatisierung von Prozessen beschäftigen. Daher möchte ich gern auf folgende Themen im Detail eingehen:

1. Installation über Argo CD
2. Schutz von Pods vor Node-Neustarts
3. Benachrichtigungen über Node-Neustarts mit Slack
4. Überwachung und Neustarts auch von ControlPlane/Etcd-Nodes

Diese Aspekte waren für uns entscheidend, um Kured effizient zu nutzen und die Verfügbarkeit unserer kritischen Anwendungen jederzeit sicherzustellen.

Was ist Kured noch mal?

Kured steht für Kubernetes Reboot Daemon und ist ein Tool, das speziell dafür entwickelt wurde, Nodes in einem Kubernetes-Cluster zu überwachen und sicherzustellen, dass sie bei Bedarf neu gestartet werden – und zwar so, dass der laufende Betrieb nicht beeinträchtigt wird.

Ausgangslage

Wir betreiben einen Kubernetes-Cluster mit insgesamt 14 Nodes: drei Control Plane/Etcd-Nodes und elf Worker-Nodes. Für die Verwaltung und Konfiguration der eingesetzten Systeme setzen wir auf das GitOps-System Argo CD. Dieses ermöglicht es uns, die komplette Clusterkonfiguration als Code zu speichern. Bei Änderungen an dieser Konfiguration werden die neuen Einstellungen automatisch und sofort auf die betroffenen Systeme ausgerollt. Das stellt sicher, dass unser Cluster immer den aktuellsten Stand der Konfiguration nutzt und Änderungen effizient umgesetzt werden können.

1. Installation über Argo CD

Die Installation von Kured haben wir gemäß unserem Standardvorgehen über Argo CD vorgenommen. Natürlich könnte man Kured auch mit anderen Tools wie Helm installieren und nutzen, aber in diesem Beitrag gehe ich nur auf die Installation mit Argo CD ein.

Um Kured über Argo CD zu installieren, haben wir eine sogenannte Application im Cluster definiert. Diese Application dient Argo CD dazu, die Anwendung im Cluster zu installieren und sicherzustellen, dass eventuelle Änderungen an der Konfiguration automatisch übernommen und aktualisiert werden.

Für die Installation kann folgende YAML-Datei verwendet werden. In diesem Beispiel wurde der Aktivitätszeitraum des Tools auf jede Nacht zwischen 0 Uhr und 4 Uhr gesetzt.

Nach der Installation dieser Applikation über Argo CD steht das System sofort zur Verfügung und führt bei Bedarf nächtliche Neustarts der Cluster-Nodes durch. Dabei überwacht Kured je nach Betriebssystem das Dateisystem und erkennt automatisch, wann ein Neustart erforderlich ist.

Herausfordernd wird es jedoch, wenn eine Node neu gestartet werden soll, während dort ein Pod läuft, der nicht beendet werden darf.

2. Schutz von Pods vor Node-Neustarts

Kured bietet die Möglichkeit, den Neustart einer Node zu verschieben, falls erkannt wird, dass kritische Pods darauf laufen, die nicht unterbrochen werden dürfen. In der Praxis gibt es häufig Pods, die nicht einfach unterbrochen werden dürfen. Gründe wie Datenintegrität, lang laufende Jobs oder kritische Geschäftsprozesse spielen dabei eine große Rolle.

Um diese Funktion zu nutzen, müssen die betroffenen Pods mit einem speziellen Label versehen werden. Kured verhindert daraufhin den Neustart der Node, bis diese Pods ordnungsgemäß beendet sind. Aus diesem Grund haben wir beschlossen, die entsprechenden Pods mit dem Label "kured-prevent-reboot=true" zu kennzeichnen. Die Konfiguration erfolgt mit dem Eintrag "blockingPodSelector"in der Helm-Konfiguration von Kured.

Ein solcher Pod, der nicht unterbrochen werden darf, könnte folgendermaßen im Kubernetes-Cluster konfiguriert sein:

Code-Beispiel generiert mit ChatGPT am 26.09.2024

3. Benachrichtigungen über Neustarts mit Slack

Die Neustarts erfolgen nun immer dann, wenn die Betriebssysteme einen Neustart benötigen, und dieser wird, sofern möglich, durchgeführt. Als Systemverantwortlicher möchte ich jedoch auch wissen, wann ein solcher Neustart durchgeführt wurde.

Kured bietet die Möglichkeit, über verschiedene Messaging-Systeme über die Neustarts zu informieren. Wir nutzen dafür einen eigenen Slack-Channel, in dem wir über die Neustarts informiert werden. Die Konfiguration ist ebenfalls sehr einfach und erfolgt durch Anpassung der Helm-Values, insbesondere des Wertes notifyUrl.

Entsprechend sieht dann die Ausgabe in Slack folgendermaßen aus:

Somit lässt sich klar nachvollziehen, wann die Nodes neugestartet und welche Aktionen jeweils auf den einzelnen Nodes durchgeführt wurden.

4. Überwachung und Neustarts auch von ControlPlane/Etc-Nodes

Das Überwachen und Neustarten von ControlPlane- und Etcd-Nodes funktioniert nicht direkt mit der Installation von Kured, da auf diesen Nodes normalerweise keine Pods installiert werden dürfen. Kured bietet jedoch einen cleveren Trick: Durch die Verwendung von sogenannten Tolerations können die Kured-Pods auf diesen Nodes ausgerollt werden, wodurch Kured in der Lage ist, auch diese Nodes zu verwalten.

Tolerations ermöglichen es Pods, auf Nodes zu laufen, die mit bestimmten Taints versehen sind, die normalerweise die Ausführung von Pods verhindern würden. Durch das Hinzufügen entsprechender Tolerations zu den Kured-Pods kann sichergestellt werden, dass sie auf den ControlPlane- und Etcd-Nodes bereitgestellt werden können.

Diese Tolerations können ebenfalls über die Helm-Values konfiguriert werden.

Einsatz mit Mehrwert

Durch den Einsatz von Kured in Kombination mit Argo CD und Slack haben wir einen echten Mehrwert für unser Unternehmen geschaffen. Die Zeiten manueller Wartungen sind vorbei. Dank der Konfiguration durch Configuration-as-Code über Argo CD können wir Änderungen am System jederzeit schnell und einfach durchführen. Kritische Pods werden vor Neustarts geschützt und über Slack erhalten wir zeitnahe Benachrichtigungen über Wartungen. Zudem werden die ControlPlane- und Etcd-Nodes automatisch gewartet, was zur Stabilität und Verfügbarkeit unserer Anwendungen beiträgt.

Wenn ihr mehr über unsere Erfahrungen mit Kured erfahren möchtet, scheut euch nicht, mich direkt anzusprechen.

Über den Autorin:

Ich bin ein begeisterter DevOps-Engineer mit einer Leidenschaft für neue Technologien, insbesondere im Kubernetes-Umfeld. Seit 26 Jahren bin ich bei intersoft tätig und habe in vielen Bereichen zur Entwicklung unserer Kernkomponenten beigetragen. Ich bringe umfangreiche Erfahrung in der Softwareentwicklung, Prozessoptimierung und im Bereich Testmanagement ein und treibe gerne Prozesse und den Einsatz neuer Technologien voran.

In meinem Team DPE (Developer Productivity Engineering) arbeite ich kontinuierlich an der Verbesserung der Prozesse rund um die gesamte Entwicklung unserer Software im Hause und bei der WWK. Mein Ziel ist es, die Prozesse immer wieder zu prüfen und zu verbessern, um den Entwicklungsteams die besten Möglichkeiten zu bieten, optimal bis hin zur Produktionsreife zu entwickeln.

Ich wohne im Landkreis Stade, bin verheiratet und habe zwei Kinder. Meine Freizeit verbringe ich gerne am Meer, bin Handball-Trainer und liebe es, verschiedene Sportarten wie Tennis, Handball und gelegentlich auch Golf zu spielen.

Lasst uns gern auf Social Media in Austausch gehen.

Performante Teams wünschen sich alle – Unternehmen und Arbeitnehmende. Aber wie bekommt man solche Teams? Wir haben die Entscheidung der Teamzusammenstellung in die Hände der Menschen gelegt, die in diesen Teams nachher performant sein sollen, statt die Führungsebene entscheiden zu lassen. Lest selbst, wie wir das gestaltet haben und ob wir zu einem Ergebnis gekommen sind.

Nach einer Neuorganisation der Abteilungsstrukturen ergab sich die Situation von zwei Teams mit sehr ungleicher Größe. Beide Teams bearbeiten den gleichen Value Stream des Unternehmens. Für ein einziges Team sind es aber zu viele Leute, vor allem bei agiler Softwareentwicklung. Daher mussten neuen Teamzusammensetzungen her – nur wie?

Traditionell werden Teamzusammenstellungen bei der intersoft durch Managemententscheid erstellt. Und auch dieses Mal gab es schon Ideen und Diskussionen in der Führungsebene, um die bestmögliche Teamzusammensetzung zu erarbeiten. Wir Agile Master schlugen vor, die Kompetenz der Mitarbeitenden als Grundlage für die Teamzusammenstellung zu nutzen, indem man eine Team Self-Selection durchführt. Die Idee dahinter ist, dass die betroffenen Menschen selbst am besten wissen und entscheiden können, mit welchen anderen Menschen sie effektiv, effizient und zufrieden ihren Arbeitsalltag gestalten.

Wir drei Agile Master in dem Bereich haben uns diesem Thema angenommen. Keiner von uns hatte so etwas schon mal selbst erlebt oder durchgeführt, aber es gab erste Erfahrungen im Unternehmen, die wir einholten. Und es gab den Kontakt zu Sandy Mamoli, die uns mit Material und Informationen sehr hilfreich zur Seite stand. So arbeiteten wir uns in die Methode ein und kamen zu dem Schluss, dass wir für unsere Situation und unsere Mannschaft eine Self-Selection als eine lohnenswerte Option für die Teamerstellung einschätzten. Jetzt musste die oberste Führungsebene informiert und überzeugt werden. Und wir brauchten glasklare Bedingungen, unter denen diese Personalentscheidung durch die Mitarbeitenden gefällt werden konnte.

• Mandat von oberer Führungsebene und Vorstand
• Klarheit über Rahmenbedingungen für die Self-Selection, auch freigegeben durch die Führungsebenen
• Entscheidung der Mitarbeitenden, ob sie eine Self-Selection oder ein Managemententscheid bevorzugen

Nachdem Vorstand und obere Führungsebene der Idee einer Team Self-Selection als Möglichkeit zugestimmt hatten, wurden die einzuhaltenden Rahmenbedingungen erarbeitet. Hierzu haben die Agile Master mit der Abteilungsleitung die Rahmenbedingungen diskutiert und formuliert. Diese wurden (nach mehreren Runden von Diskussion, Überlegungen und Ausarbeitung) vom Vorstand freigegeben. Damit war der einzuhaltende Rahmen gesetzt und das explizite Mandat für eine Self-Selection der Mitarbeitenden gegeben.

Folgende Rahmenbedingungen sind für die Teamfindung einzuhalten:

• Das Team ist eigenständig lieferfähig für Produktthemen
• Jedes Team ist in der Lage, Ausfallrisiken zu puffern
• Jedes Team hat annähernd die gleiche Größe

Mit diesen Rahmenbedingungen folgte eine Abfrage aller betroffenen Mitarbeitenden mit zwei Optionen: Durchführen der Team Self-Selection mit den genannten Rahmenbedingungen oder Aufteilen der Mannschaft durch eine Managemententscheidung. Ein einfacher Mehrheitsentscheid wurde festgelegt und die Option der Self-Selection wurde gewählt. Hier gilt es zwei Mal laut Danke zu sagen: Danke an die gesamte Führungsebene der intersoft AG für das Vertrauen in die Agile Master und die Belegschaft für diese andere Art der Teamzusammenstellung. Und Danke an alle Beteiligten für den Mut und das Ausprobieren dieses neuen Weges!

Jetzt ging es in die Vorbereitung der Self-Selection, und es ging auch daran, einen Rahmen zu schaffen, in dem die Menschen sich aus ihren alten Teamkonstellationen verabschieden konnten, um dann frei in neue Zusammensetzungen zu starten.

Zunächst verabschieden – Team Adjourning haben wir es genannt: Frühstück mit allen Teams zusammen, dann eine Phase von zwei Stunden in den Altteams – Teamräume entrümpeln, alle Deko, alle Projektpläne etc. von den Wänden nehmen, bisherige Arbeitsplätze freiräumen, alles Material zurück ins Materiallager und dann noch eine kurze Phase des Abschieds. Wir Agile Master hatten für jedes Teammitglied individuelle Postkarten entwickelt, in denen ihr Vorname mit Adjektiven dargestellt war, die ihre Person ausmachen. Diese Karten wurden in den Teams vorgelesen und verteilt. Dann war der Vormittag schon um und es gab ein Mittagessen außerhalb der Büroräume. Die Agile Master haben derweil den Raum für die Self-Selection vorbereitet.

Das Self-Selection Event wurde mit einer kleinen Warmup-Runde mit der Methode „Wetterbericht“ begonnen: Das gefühlte Wetter im Raum war ziemlich bewölkt und nebelig. Dann haben wir das Vorgehen genau erläutert, die Rahmenbedingungen erneut benannt und vor allem viel Platz für Fragen und Diskussionen gelassen. Danach haben die zwei Product Owner (PO), die die neuen Teams parallel mit Themen versorgen werden, gepitcht, was ihnen an neuen Teams wichtig ist, welche Themen sie in der näheren Zukunft sehen und wie sie sich eine Zusammenarbeit erhoffen. Als nächstes haben wir drei Agile Master uns kurz vorgestellt und gesagt, wo wir unsere Stärken sehen – immerhin waren wir Teil der Self-Selection, da sich jedes neue Team einen der Agile Master zuordnen sollte. Hier sind wir von der ursprünglichen Methode abgewichen, bei der sich die Teams zu den POs und ihrem thematischen Schwerpunkt zuordnen.

Und dann ging es richtig los: drei Runden der Selection (mindestens) zu je sieben Minuten und einer Phase der Überprüfung des Ergebnisses.

Alle nahmen sich die Avatarkarten vom Vormittag, es gab ausreichend leere Metaplanwände im Raum verteilt und die Leute pinnten sich in Gruppen an diese Wände. Die erste Runde war schnell vorbei, es folgte eine Ansicht der Ergebnisse im Plenum und die Überprüfung, ob die vorgegebenen Rahmenbedingungen eingehalten wurden. In unserem Fall hatten sich drei Teams erstellt und die Bedingungen waren recht gut eingehalten. Mit diesem ersten Ergebnis ging es in die zweite Selection-Runde – nach sieben Minuten hatten wir zwei ungleich große Teams und durchaus Diskussionsbedarf im Raum. Hierfür war Raum eingeplant. Auch hatten wir, da wir Agile Master ja mehrere Positionen im Bezug auf die Teams innehaben, zwei wirklich externe Beobachterinnen im Raum, die diese doch recht emotionale Diskussion rund um Teamkonstellationen souverän geleitet und zu einem guten Punkt gebracht haben. Somit war dann der Raum bereitet für die dritte Selection.

In der dritten Runde entstanden drei Teams und nach Überprüfung der Rahmenbedingungen und unter Beachtung der vorhergegangenen Diskussion war bald Konsens im Raum, dass diese drei Teams ein Ergebnis darstellen, dass in der Praxis erprobt werden sollte. So hatten wir nach einem vollen Tag gemeinsamer Arbeit und drei Runden Team Self-Selection drei neue Teams mit zugehörigen Agile Mastern gefunden. Den Tagesabschluss nutzten wir, um als erste Amtshandlung der neuen Teams Teamnamen festzulegen und Fotos zu machen.

Was für ein spannender Tag! Wir saßen nach getaner Arbeit zusammen, etwas müde, aber geflasht von der tollen Arbeit jedes und jeder Einzelnen. Was hatten wir da erlebt? Die Kompetenz von Menschen, selbst zu wissen, in welchen Konstellationen sie gut arbeiten können. Die Offenheit und den Mut, die Verantwortung für sich selbst und eine Teamkonstellation zu übernehmen. Dass neutrale Beobachterinnen ein wichtiges Element in unserem Setup waren, um den Raum für Diskussionen halten zu können und zu einem guten Ergebnis zu führen. Die eigentliche Arbeit – aus den neuen Teams auf dem Papier nun tolle, funktionierende und effiziente Teams zu formen – die steht noch aus. Sie fängt am Tag nach der Self-Selection an.

Gern berichten wir, wie es uns und den neuen Teams in den nächsten Monaten ergeht und wie sich die Teamentwicklung gestaltet – nach einigen Monaten rückblickend wieder an dieser Stelle.

Über die Autorin:

Ich bin Antje und seit 10 Monaten bei der intersoft AG als Agile Master tätig. Ich kann offiziell weder IT noch Versicherungen, sondern bin studierte Kultur- und Sprachwissenschaftlerin. Allerdings schlägt mein Herz beruflich schon seit 2006 für die IT. Seitdem arbeite ich in diesem volatilen, beweglichen und offenen Umfeld – als Rolloutmanager, Kundenbetreuung, Projektmanagerin (mit Zertifizierung nach GPM / IPMA) von IT-Großprojekten und als IT-Beraterin. Ich bediene dabei immer Schnittstellen, meist zwischen Endkunden und Nutzern auf der einen und den technischen Superhirnen auf der anderen Seite, und sorge für eine erfolgreiche Kommunikation und Zusammenarbeit (für mich eindeutig auch eine Form von Übersetzungsarbeit und Kulturverständigung). 2017 entscheide ich mich für eine Weiterbildung zum Scrum Master und finde Liebe auf den ersten Blick in diesem Framework. Seitdem ergreife ich jede Gelegenheit, agile Methoden und Frameworks dort zum Einsatz zu bringen, wo sie einen Mehrwert schaffen können. Sechs Jahre habe ich dies zuletzt bei der Lufthansa Technik AG machen dürfen – im IT-Kontext, aber auch außerhalb davon. Aktuell stelle ich all meine Erfahrung und Methodenkompetenz in die kontinuierliche Begleitung von Entwicklungsteams bei der intersoft AG und lerne weiterhin jeden Tag Neues dazu.

Ich stamme aus dem Ruhrpott, bin aber schon zum Studium nach Hamburg gezogen. Hier lebe ich mit meinem Mann und unseren zwei Kindern ganz im Westen (wieder) und genieße Garten, Bücher und eine spannende Partie American Football, wann immer der Alltag das zulässt. Als Ausgleich zum Bürojob halte ich mich mit Fahrradfahren und Fitness einigermaßen im Lot.

Viele Unternehmen kämpfen mit der Herausforderung, ihre IT-Infrastruktur effizient zu warten, ohne den täglichen Betrieb zu stören. In diesem Blog erfahrt ihr, wie wir es geschafft haben, unsere Kubernetes-Server voll automatisiert während der Nachtstunden zu aktualisieren und damit die Betriebseffizienz zu maximieren. Egal ob ihr IT-Manager, DevOps-Spezialisten oder technikbegeisterte Leser seid, diese Tipps werden euch helfen, eure IT-Wartungsprozesse zu revolutionieren. Lernt, wie ihr durch automatisierte Prozesse nicht nur Zeit und Geld sparen, sondern auch die Zufriedenheit eurer Teams steigern könnt. Wir werden zuerst die Herausforderungen der bisherigen Wartung beleuchten, gefolgt von unserer Analyse und den Vorteilen der Automatisierung mit Kured. Abschließend teilen wir unsere besten Praktiken für eine störungsfreie Wartung.

Über den Autorin:

Ich bin ein begeisterter DevOps-Engineer mit einer Leidenschaft für neue Technologien, insbesondere im Kubernetes-Umfeld. Seit 26 Jahren bin ich bei intersoft tätig und habe in vielen Bereichen zur Entwicklung unserer Kernkomponenten beigetragen. Ich bringe umfangreiche Erfahrung in der Softwareentwicklung, Prozessoptimierung und im Bereich Testmanagement ein und treibe gerne Prozesse und den Einsatz neuer Technologien voran.

In meinem Team DPE (Developer Productivity Engineering) arbeite ich kontinuierlich an der Verbesserung der Prozesse rund um die gesamte Entwicklung unserer Software im Hause und bei der WWK. Mein Ziel ist es, die Prozesse immer wieder zu prüfen und zu verbessern, um den Entwicklungsteams die besten Möglichkeiten zu bieten, optimal bis hin zur Produktionsreife zu entwickeln.

Ich wohne im Landkreis Stade, bin verheiratet und habe zwei Kinder. Meine Freizeit verbringe ich gerne am Meer, bin Handball-Trainer und liebe es, verschiedene Sportarten wie Tennis, Handball und gelegentlich auch Golf zu spielen.

Lasst uns gern auf Social Media in Austausch gehen.

Teamgröße: Eine:r mehr ist eine:r mehr – plus eins. Oder vielleicht doch nicht?

Ich werde oft gefragt, welche Teamgröße die richtige ist. Die Antwort ist einfach und unbefriedigend: Es kommt darauf an. Es lohnt sich aber etwas darüber nachzudenken.

Irgendwo müssen natürlich Annahmen getroffen werden und das geschieht nun hier: Ich nehme an, ihr arbeitet in agilen Teams, die selbst entscheiden, wie sie die Dinge tun, die in ihrem Aufgabengebiet liegen. Jetzt nehmen wir weiterhin an, euer Team kriegt alles super hin und liefert zur Zufriedenheit. Dann liegt der Gedanke nahe: Och, da muss ich ja auf nichts mehr achten. Ich lege euch dennoch ans Herz, euch regelmäßig zwei Dinge zu fragen:

• Führen wir immer noch genug kritische Retrospektiven durch, um auch weiterhin eine Achtsamkeit gegenüber verdeckten Konflikten und schlummernden Ideen/Innovationen zu gewährleisten?
• Sind wir in einer Wohlfühlzone angekommen? Entwickeln wir uns kaum mehr weiter, sind also auf einer Art Plateau angekommen? Dies kann dazu führen, dass wir glauben, die Situation ohne weitere Probleme nach oben skalieren zu können – eine Art „Größenwahnsinn“.

Wenn ihr euer Team aber trotz Weiterbildung, Teambuilding, Retros, Speedbacks und all den wunderschönen Methoden nachhaltig nicht ans Laufen bekommt, es also nicht zuverlässig liefert, sollten möglichst neutral folgende Fragen beleuchtet werden:

• Fehlen dem Team nachhaltig schlicht und einfach Fähigkeiten, die nicht durch Teammitglieder erlernt werden können? Wenn ja: Kann das Team durch Hinzufügen eines Teammitglieds in einen störungsfreien Zustand überführt werden?
• Ist es möglich, dass ein Teammitglied das Team in die Dysfunktionalität führt?

Falls wir uns entscheiden, dass es dem Team (und dem Gesamtorganismus) hilft, das Team zu vergrößern, dann sollten wir uns bewusst sein, dass das gesamte Team die Tuckman-Phase mit dem neuen Teammitglied durchlaufen wird. Das allerdings ohne Garantie, dass Dysfunktionen danach ausgelöst werden und weiterhin wird dies die Komplexität der Kommunikation erhöhen.

Wenn wir das Team um eine Person vergrößern, muss diese Person nicht nur „ins Team passen“ und das Team die Forming – Storming – Norming – Performing Phasen erfolgreich durchlaufen, sondern das neue Teammitglied muss mit allen anderen Teammitgliedern eine Kommunikation aufbauen.

Es wird also kontinuierlich komplexer und dies will ich nun visualisieren. Vielleicht wird es damit möglich sein, eine Richtline zu finden, ab wann wir vorsichtig werden sollten und ab wann es anfängt, wirklich Hürden zu entwicklen. Doch schauen wir uns das einmal an:

Bei 6 Teammitgliedern bedeutet das Hinzugügen einer weiteren Person, dass Kommunikationskanäle zu 6 Personen aufgebaut werden müssen.

Das ist im Fall der Erweiterung eines 6er-Teams auf ein 7er-Team nicht weiter bedenklich. Diese Person muss nur 6 Kommuniaktionskanäle aufbauen. Selbst eine Erweiterung eines 6er-Teams um zwei Personen auf ein 8er-Team hält die Anzahl der Kommunikationskanäle in einem überschaubaren Maß. Hier muss die letzte Person dann allerdings schon 7 Kommunikationskanäle aufbauen.

Generell können wir sagen: 6 (7 und 8) ist eine gute Sache!

Vereinen wir im Team aber bereits schon 8 Teammitglieder, sieht diese Sache selbst bei der Erweiterung um eine Person schon etwas komplexer aus, denn diese Person muss schon 9 Kommunikationskanäle aufbauen. Wenn wir dies visualisieren und vergleichen, sehen wir, dass es langsam anfängt, unüberschaubar zu werden.

Es sieht also wirklich so aus, als sollten wir ab 8 achtgeben.

Kommen wir gar auf die Idee ein 8er Team um drei Personen von 8 auf 11 Personen zu erweitern, wächst die Anzahl der Kommunikationskanäle bedrohlich. So sehen die Kommunikationskanäle bei 11 Personen aus:

Wir sollten uns also bewusst sein, dass die Anzahl der zu etablierenden Kommunikationskanäle von der bereits bestehenden Anzahl der Teammitglieder abhängt.

Das 12te Teammitglied müsste z. B. 11 Kommunikationskanäle aufbauen, womit dann 1+2+3+4+5+6+7+8+9+10+11 = 66 Kommunikationskanäle existieren würden. Dies ist ein signifikanter Unterschied zum Zustand von zuvor 55 Kommunikationskanälen bei nur einer Person weniger.

11 ist vermutlich schon eine Schnapsidee, aber ab 11 fängt es wirklich langsam an, eine ausgewachsene Schnapsidee zu werden.

Wir haben in Meetings Kommunikations- und Abstimmungsaufwände. Jedes Team hat diese, denn jedes Team muss Arbeit planen und ihren Stakeholdern Aussagen über Lieferumfänge und Fertigstellungswahrscheinlichkeiten liefern. Das Team muss die Anforderungen verstehen und sich über das WAS und WIE austauschen. Da ich persönlich viel im agilen Umfeld arbeite, will ich an drei Rechenbeispielen veranschaulichen, was verschiedene Teamgrößen im agilen Alltag bedeuten:

Daily

Ein Daily dauert in der Regel 10 Minuten mit einer Gruppe von 6 Devs.
Danach wird dann oft noch ein allgemeiner Austausch dran gehängt, in dem neue Aufträge, Mails, Urlaube, Weiterbildungen o. Ä. besprochen werden. Das kann auch noch einmal 10 Minuten dauern.

Also in der Summe 20 Minuten – nichts was wehtäte.

Bei einer Vergrößerung auf 12 Devs ist das Daily 2,5-mal so lang. Warum 2,5-mal?
Es sind nicht nur doppelt so viele Arbeiten am Board (das würde die Zeit verdoppeln), sondern bei jeder Arbeit können auch noch doppelt so viele Personen Wortbeiträge zusteuern. Der Austausch ist dann wieder eher nur doppelt so lang.

In der Summe also 50 Minuten. Das ist ein signifikanter Zeitfaktor und es nervt, denn es „hält von der Arbeit ab“ und zwar täglich – aber das Daily ist noch gar nicht das Problem.

Planning

Das Planning ist im Vergleich zum Daily schon viel eher ein Problem, denn hier schlagen unsere 66 Kommunikationskanäle zum Teil zu, da es beim Planning auch zu einzelnen Interaktionen kommt.
Wir vergleichen also eher 15 (1+2+3+4+5) Kommunikationskanäle bei 6 Devs mit 66 (1+2+3+4+5+6+7+8+9+10+11) Kommunikationskanälen bei 12 Devs. Dazu kommt die Verdopplung der Arbeit. Ein Planning mit 12 Devs ist eher 3-mal so lang als mit 6 Devs. Da ein Planning schnell mal eine Stunde mit 6 Devs dauert, braucht ein Planning derselben Tiefe mit 12 Devs eher 3 Stunden.

Speedback

Das Speedback ist hier ein Killer, weil die 2-Stunden-Marke im Einzelgespräch erreicht wird.

Bei einem Speedback wir sehr schnell ein sehr dichter Einzelaustausch erzeugt, der eine Wunderwaffe bezüglich Konflikten, Kennenlernen, Respekt, Offenheit und Feedback ist – eine Kultur-Wunderwaffe sozusagen. Doch was passiert da genau?

In Zweiergruppen wird sich 10 Minuten Zeit genommen. 5 Minuten redet die eine Person, die andere hört nur zu, 5 Minuten andersrum. In den 5 Minuten werden bis zu 3 Dingen genannt, die der einen Person an der anderen gefallen und 2 bei denen dieselbe Person Entwicklungspotenzial sieht, dann wie gesagt das Ganze andersherum. Wird ein Speedback alle 4-6 Wochen durchgeführt, wird es bald keine Leichen mehr im Keller geben und jeder weiß ganz genau, wen man vor sich hat und wie die Person tickt – ganz egal, ob man im Arbeitsalltag viel miteinander zu tun hat oder nicht und ganz egal, ob man remote arbeitet oder nicht.

Mit 6 Personen dauert ein Speedback 50 Minuten – alle 4-6 Wochen sind diese 50 Minuten sehr gut investierte Zeit und machen Spaß.

Mit 12 Personen allerdings dauert ein Speedback 110 Minuten, also mit dem Umsortieren der Gruppe 2 Stunden. 2 Stunden in Einzelgesprächen mit 11 Kolleg:innen ist nicht spaßig. Bei dieser Gruppengröße ist man besser beraten, sich ein anderes Format zu überlegen. Ich kenne allerdings keines, was so gute Ergebnisse erzielt.

Summa Summarum

Das waren nur ein paar Beispiele, aber ihr seht, wie sich das durch alle Meetings und Scrum-Artefakte oder Kanban-Kadenzen zieht. Das Team wird dadurch schwerfällig und in Konsequenz wird oft der Sprintzyklus verlängert, was die Reaktionszeit verlangsamt. Eine gute Lösung ist das allerdings nicht.

Wie immer gibt es kein Patentrezept, denn ein Team ist einzigartig und die Fähigkeiten, die es mitbringt, sowie die Aufgaben, die es zu erfüllen hat auch. Dennoch gibt es eine Orientierung mit der wir ins Rennen gehen können:

Ein guter Startpunkt kann bei einer Teamgröße von 6 Entwicklern mit PO und Scrummaster also bei 8 liegen, je nachdem welche Fähigkeiten in der Crossfunktionalität abgebildet werden sollen. Ab 11 wird die Kommunikation so komplex, dass Retros nicht mehr einfach zu handeln sind und das Team zusätzlich Gefahr läuft, „Subteams“ zu bilden. Fehlinformation ist nahezu vorprogrammiert. Kurz gesagt:

Je größer, desto Wollknäuel.

Gebt eurem Team also die Chance, gut funktionieren zu können.

Über die Autorin:

Ich heiße Gina, lebe seit 30 Jahren in Hamburg und beschäftige mich mit agilen Arbeitsmethoden und Organisationsentwicklung. Ich bin akkreditierte Kanban-Trainerin der Lean Kanban University und habe im Laufe meiner beruflichen Laufbahn einigen Firmen bei der agilen Transition geholfen. Bei intersoft bin ich seit 1,5 Jahren als PO tätig und wirke dabei während der alltäglichen Arbeit auf die agile Transformation ein.

Während und nach meinem Meteorologie-Studium habe ich am Max-Planck-Institut für Meteorologie gearbeitet, wo ich mit der Open Source Welt in Kontakt kam. Seit 2003 war ich diesbezüglich stark engagiert, Vize Präsident der TYPO3 Association, danach ein Neos-Core-Team-Member und Direktorin der Neos Foundation.

Privat liebe ich es, durch die Welt zu reisen, zu schwimmen und Kajak zu fahren. Ich bin Tauchlehrerin, GUE Höhlentaucherin und segle ab und zu auf einem Traditionsschiff namens Windsbraut.