Startseite » Agile Systemgrenzen managen

Agile Systemgrenzen managen

Eine Diskussion, die immer wieder aufkommt und meiner Meinung nach, ein Thema, was in jedes Reinschnuppern in agile Methoden gehört. Ich bin ja froh, wenn hierrüber trefflich gemeinsam gegrübelt wird. Wenn das nicht der Fall ist, dann ist eher ein häufiger Effekt ein „bei uns geht das ja gar nicht“ vorwegzunehmen. Und das wären dann schon seeeehr frühe Scheuklappen.

Mein klassisches Statement:

Jede agile Organisation hat Systemgrenzen zu nicht agilen Bereichen.

Das ist leicht zu postulieren, denn die ganze Welt ist nun mal nicht agil und vor allem arbeiten wir auch nicht mit „der ganzen Welt“ „gemeinsam“ an „einer Vision“ und „identifizieren und mit einheitlichen Zielen“ (schön wärs).

Fangen wir also gedanklich vorne an:

In einem bestimmten Umfang sind wir auf dem Weg agil zu arbeiten. Das mag ein kleines 3er Team sein, ein größeres Team, eine ganze Abteilung oder vielleicht sogar das komplette Unternehmen. Und außerhalb dieses Systems tickt die Welt eben nicht nach unserem agilenHerzschlag.

Komplexität:Wir scheitern Pin

Der agile Grundgedanke ist entstanden, um Komplexität zu begegnen. Komplexität Produkt aus Dynamik und Kopplung. Durch autonome Teams in einer Größe von 7 +/- 2 Personen und einem limitierten Produktionsrhythmus von z.B. 2-4 Wochen entkoppeln wir uns aus dem System temporär und reduzieren die Komplexität. That’s it! Das heißt wir als Team haben unsere Welt unseren gemeinsamen Nenner und sind flexibel, weil wir unabhängig schaffen können.

Hand aufs Herz: damit ist eigentlich schon das agile Nachbarteam außerhalb unserer Systemgrenzen und erfordert einen „besonderen“ Umgang. Es ist nicht in unserem direkten Entscheidungsradius.

Also: es ist gar nicht so „besonders“, sondern Standard sich über die Systemgrenzen bewusst Gedanken zu machen. Und natürlich ist das agile Nachbarteam wohl eher die kleinere Hürde, denn die wissen ja genau wie wir ticken.

In der Scrum-Methodik ist das mit der Aufgaben-Definition der Scrum-Master-Rolle gelöst. Der muss als Außenminister dafür sorgen, dass das Team anständig und frei arbeiten kann. Ich finde einen ganzheitlichen Blick in Form von Beispielen hilfreicher und vor allem für das Reindenken in agile Arbeitswelten greifbarer.

Was sind klassische Beispiele für Systemgrenzen der agilen Arbeit?

…mit einigen Ansätzen, wie man damit umgehen könnte. Natürlich gibt es da keine pauschalen Rezepte, sondern Ideen, wie ich mich nähern würde.

agile Systemgrenzen Pin
agile Systemgrenzen

Mein Management will steuern und Reporting haben

Das Team macht sich auf den Weg, der Teamleiter ist an Board, die Ebene drüber möchte nicht über agil nachdenken. So geht es in vielen Organisationen los. Dabei ist das Cross-funktionale Team gar nicht der Störfaktor, das sehe ich mittlerweile häufiger auch ohne agiles Vorgehen. Sondern der Wunsch nach KPI, Zielvorgaben & Co., wie ihn das Management auch in der Vergangenheit gewohnt war.

Der Weg des geringsten Widerstands ist hier das Reporting zu liefern, als Task abzuarbeiten, die Ziele als Team anzunehmen und in Stories zu bearbeiten, sowie den Product Owner oder Team Leiter als Empfänger für „Steuerimpulse“ zu etablieren. Der wichtige „neue“ Punkt ist eigentlich die ungestörte Phase der Abarbeitung, so dass keine Störimpulse in die Produktion kommen.

Erziehungsimpulse in Richtung Management könnten sein, dass die Arbeitsweise transparent gestaltet wird. Das kann Vertrauen schaffen, wenn immer klar ist wo gerade der Arbeitsstand ist. Ein solches Verständnis kann dann auch helfen „Steuerimpulse“ zu hilfreichen Zeitpunkten im Prozess zu geben und in sinnvollen Portionen zu denken. Management kommt dann gedanklich Stück für Stück mit. Wenn die Ziele entsprechend kleiner werden und häufiger besprochen werden, kann auch klar werden wie greifbar und flexibel agil für das Unternehmen wird. Und wenn dann noch das Reporting so gestaltet wird, dass es hilfreich für das Team ist und nicht nur der Rechtfertigung dient, sind wir schon sehr nah am Ziel.

Hilfreiches Reporting aus dem agilen Team für „Klassische Managementköpfe“ ist aus meiner Erfahrung ein gemeinsamer Nenner, worauf wir als Zahlen schauen wollen und dann z.B. auf Monatsbasis die 3 Fragen zu diesen Zahlen / Themenbereichen zu beantworten:

  • Was haben wir im letzten Monat erreicht?
  • Was wollen wir im nächsten Monat erreichen?
  • Was steht uns im Wege?

Zack, damit hat man gleich im 3. Punkt Hausaufgaben ans Management verteilt.

Wir haben Liefertermine einzuhalten

Auch hier mal wieder das Vorurteil beackert:
„Agil bedeutet wir fangen mal an und schauen, was dabei rauskommt.“.

Nein, agil …

  1. ist ständiges Messen von Fortschritt und Erfolg
  2. versetzt uns in die Lage häufig nachzusteuern und
  3. sorgt dafür, dass wir den maximalen Wert aus Zeit und Geld für das Unternehmen generieren.

Klingt das nach „Liefertermine spielen keine Rolle“? Das bedeutet der Fokus auf einen Liefertermin ist stets präsent und wir sollten uns nach jeder Iteration an dem Liefertermin und seiner Erreichbarkeit messen. Und zwar passiert das so viel regelmäßiger und konsequenter als in klassischen Produktionen und es kann viel früher reagiert werden.

Ich denke das ist aber nur die halbe Antwort hinter dem Einwand. Ein Liefertermin lässt sich einfach schön visualisieren in einem Wasserfall, in einem Gannt-Chart und erweckt den optischen Eindruck der Unverrückbarkeit. Die Vorstellung den Termin in einem stets beweglichen Backlog zu verwirklichen ist im ersten Augenblick manchmal schwierig.

Aber sind wir mal ehrlich zu uns selbst: Wie solide ist der Termin im Gannt-Chart? Eher wackeliger als in einer Umgebung, die stets misst und nachsteuert. Es geht also darum den Liefertermin immer im Auge zu behalten und die Abarbeitung in diese Richtung zu managen.

  • Warum prangt dann nicht dieser EINE Termin stets groß über dem Backlog?
  • Oder ist nicht eine knallrote Story als „Lieferung“ mit einem Termin vermerkt?

Im klassischen, wie im agilen ist ein Mensch für die Verpflichtungen in die „Außenwelt“ verantwortlich. Dieser Mensch ist in der agilen Welt der Product Owner und der verantwortet was wann umgesetzt wird – also den erzeugten Business Value. Der muss den Termin ständig auf der Uhr haben! Die Visualisierung ist ggf. sein Werkgzeug stetig das Team mitzunehmen.

In unserer Linien-Organisation haben wir keine Cross-funktionalen Teams (aka agil geht nicht)

Das Team ist der Motor von agil und gemeinsam an Zielen zu arbeiten – eine unabdingbare Grundlage. Ein Cross-funktionales Team ist „nötig“, um fertige Produktinkremente zu liefern.

Wenn es keine Cross-funktionalen / interdiziplinären Teams gibt, kann man dennoch agil arbeiten. Sich auf den Weg zu machen in die agile Arbeitswelt hat oftmals nicht als ersten Schritt die Organisation umzukrempeln. Das passiert häufig erst nachgelagert, weil dann die Sinnhaftigkeit auf breiterer Ebene gesehen wird.

Was ist also die Lösung? Jedes Team erzeugt Ergebnisse, sonst wäre es überflüssig. In diesem Kontext zu definieren: Was ist eigentlich unser Produkt, für wen erzeugen wir welchen Wert? Ist damit der erste Schritt. Interessanterweise haben das Teams oft gar nicht so klar für sich und diese Fragen zu beantworten sind schon ein erster kleiner Change zu Transparenz und Klarheit. Wenn diese Klarheit geschaffen ist, kann im Team agil gearbeitet werden, und zwar zu 100 %.

Das muss aber nicht! Ich sehe 6 Elemente, die für ein agiles Arbeiten in jedem Team funktionieren und hilfreich sind:

  1. das Team hat sein gemeinsames Ziel klar
    (Was wollen wir für wen erreichen?)
  2. es arbeitet gemeinsam als Team
    (Es gibt keine Einzelkämpfer, alle stehen für das Ergebnis ein)
  3. es tauscht sich regelmäßig über Resultate und Fehler aus
    (über Reviews und/oder auch Dailies)
  4. es generiert die Optimierung als Selbstverständnis
    (über regelmäßige Retrospektiven)
  5. und arbeitet in einer festen Taktung
    (als Hilfestellung, damit die o.g. Punkte nicht unter gehen)
  6. Es wird entschieden, was wir aktuell nicht bearbeiten
    (Priorisierung und Fokus)

(s. auch Cheat Sheet aka agiler Spickzettel)

Sich also als Team Schritt für Schritt agile Elemente zu erarbeiten und sie zu etablieren ist ein softer Change-Prozess in ein agiles Arbeiten. Allein dieses interne Projekt kann das erste agile sein, das anhand eines Taskboards abgearbeitet wird und somit agile Erfahrung gesammelt werden kann.

Wir brauchen immer wieder Ressourcen aus anderen Teams

Auch das ist kein Show-Stopper, sondern eine typische Situation. Hier gibt es wenig Ratschläge, außer frühzeitig in die Kommunikation zu gehen. Wenn wir uns an den Grundgedanken „Entkopplung“ erinnern, wäre es hilfreich die Zuarbeit eines anderen Teams so zu gestalten, dass wir deswegen nicht auf der Stelle treten, sondern weiterhin produktiv sein können. Wie genau die „anderen Teams“ typischerweise arbeiten, reagieren und zuliefern ist höchst individuell und schwer mit pauschalen Ratschlägen zu bedienen.

Wie arbeiten wir mit anderen agilen Teams zusammen?

Ja, genau. Auch komplett agile Organisationen müssen sich mit anderen Einheiten synchronisieren und abstimmen. Und diese Einheiten sind außerhalb unserer Einflussgrenzen. Das Verständnis für die Arbeitsweise ist vorhanden, also wird es sicher einfacher.

Es kann ein guter Auftakt sein, sich gegenseitig in den Teams mal „zu besuchen“. Zum Beispiel als Mäuschen im Daily bei anderen Teams gelegentlich dabei zu sein. Sich auf fachlicher Ebene zwischen Product Ownern, Scrum Mastern oder mit fachlichen Kompetenzen auszutauschen. So entstehen Netzwerke, die helfen und vor allem ein Wissens- und Erfahrungsaustausch.

Bei regelmäßigen Schnittstellen kann es Sinn machen ein gemeinsames Planning für diese Punkte im Kalender zu haben. Bei unregelmäßigen Wünschen an das andere Team, kann es Sinn machen mit deren Product Owner eine Story einzuplanen und im Planning dabei zu sein. Wie schon erwähnt sicher mit mehr Vorlauf als im eigenen Team.

Mein Rat: macht Euch in kleinen Schritten auf den Weg. Die ersten opportunistisch erscheinenden und einfachen Schritte zu gehen, Erfahrungen zu sammeln hilft dann auch mal die ein oder andere größere Hürde zu nehmen.

Weiterführende Artikel


Wie hilfreich war dieser Beitrag?

Klicke auf die Sterne um zu bewerten!

Durchschnittliche Bewertung 4.8 / 5. Anzahl Bewertungen: 6

Bisher keine Bewertungen! Sei der Erste, der diesen Beitrag bewertet.

Schreibe einen Kommentar

Neues per E-Mail?