Ungefähre Lesedauer: 2 Minuten

In vielen Branchen ist die agile Produktentwicklung mittlerweile zum Standard geworden (besonders bei der Softwareentwicklung). Das bedeutet, dass Produkte von kleinen, selbstorganisierten und funktionsübergreifenden Teams inkrementell entwickelt werden und kontinuierlich mit Hilfe von Kunden-Feedback verbessert werden. Im Agilen Manifest ist das ziemlich gut beschrieben – ersetzen Sie lediglich den Begriff „Software” mit „Produkt” (es ist nämlich nicht softwarespezifisch).

Das ist alles wunderbar. Allerdings wird alles natürlich viel komplexer und mühsamer, je mehr Teams über die Grenzen innerhalb der Organisation hinaus zusammenarbeiten. Auch wenn die gesamte Organisation akkurat in Scrum Teams eingeteilt wurde, kann es am Ende ein heilloses Durcheinander geben. Vielleicht kommt Ihnen das bekannt vor:

Agiles Chaos

Muss es wirklich so kompliziert sein?

Bevor Sie versuchen, Herr über dieses Chaos zu werden, fragen Sie sich: „Muss es wirklich so umfangreich und kompliziert sein?”. Vielleicht versuchen Sie ja, alles auf einmal zu schaffen. Vielleicht sind Ihre Teams nach Funktionen gegliedert und verursachen so zu viele Abhängigkeiten. Vielleicht ist Ihre Architektur zu starr, zu instabil oder zu sehr gekoppelt.

Beginnen Sie also damit, Dinge zu vereinfachen. Ein kluger Mensch hat einmal gesagt: „Don’t scale Agile – descale your org”. Das bedeutet im Grunde, dass nicht mehr Agile, sondern abgespeckte Organisationen die Lösung sind. Vielleicht können Sie eine Umgestaltung der Organisation bewirken, bei der ein oder zwei Teams an ein und demselben Ort zusammenarbeiten, die zu 100 % fokussiert sind und direkten Kundenkontakt haben. Sie sind mit hoher Wahrscheinlichkeit sehr gut im Stande, das gleiche Produkt in der Hälfte der Zeit mit nur der Hälfte der Kosten zu bauen! Halten Sie sich nicht an der Idee fest, dass mehr Leute automatisch besser sind. In einigen Fällen sind mehr Leute von Vorteil, aber das Einzige, wobei Sie sich wirklich sicher sein können, ist die Tatsache, dass mehr Leute höhere Kosten und erhöhte Komplexität bedeuten. Die potentiellen Vorteile sind und bleiben eben nur potentielle Vorteile.

Aber gut. Manchmal muss einfach ein ganzer Haufen Teams, Abteilungen und Verkäufer gemeinsam an etwas Großem und Komplexem arbeiten. Gehen wir einfach mal davon aus, dass das so ist.

Wenn das der Fall ist, benötigen Sie höchstwahrscheinlich einen Leader! Das ist jemand, der sich voll und ganz darauf konzentriert, die unterschiedlichen Teams zu koordinieren, alles aufeinander abzustimmen und im Blick zu behalten. Und genau darum geht es in diesem Artikel.

Agile sowie Scrum vertrauen auf Selbstorganisation, welche super effektiv ist (wenn man es richtig macht). Mit mehr als einer Handvoll Teams braucht jedoch auch die Selbstorganisation Unterstützung – also jemanden, der eine Umgebung schafft und erhält, die die Selbstorganisation erst möglich macht. Dazu gehören Dinge wie ein klares Ziel, kurze Feedbackschleifen, effektive Kommunikationswege usw. Im Grunde geht es darum, dass aus „1+1=1,5” (durch schlechte Anpassung) „1+1=3” (durch Synergien) wird.

Nennen wir diese Person den Agile Leader. Seine Hauptaufgabe ist es, Alignment (dt.: Anpassung, Harmonisierung) zu schaffen.

Agiles Alignment

Auf Teamebene gibt es bei agilen Methoden bereits führende Rollen wie den Product Owner und den Scrum Master. Bei der Zusammenarbeit mehrerer Teams ist jedoch keine formelle Führungsrolle definiert. Der Grund dafür ist, dass kleinere Projekte o. ä. normalerweise einfach keinen Leader brauchen – der Erfolg von Scrum hat uns gezeigt, dass eine effektive Führung nicht auf eine konkrete Führung angewiesen ist. Jedoch kann man sagen, dass man eher einen bestimmten Leader benötigt, je mehr Leute involviert sind. Das muss jemand sein, dessen Vollzeit-Job es ist, sich zu kümmern – egal, ob es sich dabei um ein „Projekt”, ein „Programm”, ein „Produkt” oder was auch immer handelt, bei dem mehrere Teams involviert sind.

Diese Führungsrolle ist nicht notwendigerweise auf eine einzige Person beschränkt. Es können auch zwei Personen oder ein kleines Team sein, solange sie eng zusammenarbeiten und mit einer Stimme sprechen. Der Einfachheit wegen gehen wir in diesem Artikel aber mal von einer einzelnen Person aus.

Ein Beispiel:

Bei Spotify werden die meisten mittleren bis großen Initiativen von einem „TPD-Trio” geleitet – einem kleinen Führungsteam, bestehend aus drei Personen aus den Bereichen Technologie, Produkt und Design. Auf diese Weise ist sichergestellt, dass alle drei Perspektiven berücksichtigt werden. Bei größeren Initiativen, die weit über diese drei Bereiche hinausgehen, ist ein solches Trio jedoch nicht genug. Sollte das Trio vergrößert werden oder sollte es eine zusätzliche Führungsrolle geben? Und wie sollten wir eine solche Rolle nennen? Damit experimentieren wir immer noch.

Nehmen wir einfach erst einmal die Bezeichnung „Agile Leader” als Platzhalter für den Namen, den Sie der Rolle geben möchten. Es hängt auch ein wenig davon ab, wie Sie Ihre Arbeit organisieren. Entscheiden Sie sich für eine Rollenbezeichnung, die in Ihrem Kontext am passendsten ist: Technischer Leiter, Projektmanager (bei einem Projekt), Chief Product Owner, Programm-Manager, Koordinator, Projekt-Coach oder was auch immer. Egal, wie Sie die Rolle nennen, sie hat eine sehr wichtige Funktion und wird bei jedem komplexen und funktionsübergreifenden Unterfangen benötigt, in dem mehrere Teams zusammenarbeiten. Die Personen, die diese Rolle übernehmen, müssen motiviert, engagiert und qualifiziert sein.

Ich nenne sie in diesem Artikel bewusst Agile Leader. Das Wort „Agile” soll noch einmal betonen, dass es in diesem Artikel um den Kontext der agilen Produktenwicklung geht, der sich stark von einem Wasserfall-Kontext unterscheidet. Statt „Manager” benutze ich den Begriff „Leader”, weil in gut funktionierenden agilen Organisationen nun mal der Großteil des „Managements” von den Teams selbst erledigt wird. Das Hauptziel dieser Rolle ist eben Leadership und nicht Management. Zu 100 Prozent lässt sich das natürlich nicht voneinander trennen.

Der Sinn dieses Artikels ist es, ein klareres Bild eines tollen Agile Leaders zu schaffen, damit Sie viel einfacher diese Person finden, heranziehen oder selbst werden können. Der Artikel soll auch dabei helfen, dass Ihre Teams erfolgreicher zusammenarbeiten können. Das ist keine offizielle Definition dieser Rolle sondern meine ganz persönliche.

Zusammengefasst bedeutet das also: Versuchen Sie, große, komplexe und teamübergreifende Arbeiten zu vermeiden. Sollte das nicht möglich sein, stellen Sie zumindest sicher, dass Sie einen großartigen Agile Leader haben.

Ist das denn kein Projektmanager?

Vielleicht, aber nicht notwendigerweise. Ein „Projekt” ist nur eine von vielen Möglichkeiten, Arbeit zu organisieren, und oft ist es für die Produktentwicklung unpassend. Wenn Sie jedoch mit dem Konzept von Projekten arbeiten und diese Projekte ziemlich groß und komplex sind und eine Synchronisierung der vielen unterschiedlichen Teams und Organisationen erforderlich ist, dann ist der Agile Leader natürlich in gewisser Weise ein Agile Project Leader, also ein agiler Projektleiter. Ich habe auch einen anderen Artikel mit dem Titel What is an Agile Project Leader (dt.: Was macht einen agilen Projektleiter aus) geschrieben, in dem das Projektmodell im Allgemeinen behandelt wird. Im Bezug auf die eigentliche Rollenbeschreibung ist der Artikel jedoch mit diesem hier verknüpft.

Und wieder ist die Wahl des Rollennamens sehr stark vom Kontext abhängig. Sinn und Zweck dieses Artikels ist einfach nur, klarzustellen, welche Art von „Leader” Sie benötigen, um die Rolle auch auf agile Art und Weise ausführen zu können.

 Sie wollen mehr erfahren? Besuchen Sie unsere Trainings  Zu den Trainings
Was tut ein Agile Leader?

Mein Kollege Babar von Spotify hat das toll zusammengefasst, indem er einen Sport-Vergleich angestellt hat:

  1. Wie sieht es aus, zu gewinnen? Vision/Mission
  2. Was ist der Plan? Strategie und Taktik
  3. Wie ist der Spielstand? Fortschritt, Status, Feedbackschleifen
  4. Was hält uns vom Gewinnen ab? Kontinuierliche Verbesserung, Menschen, Teams, Strategie, Taktik

Wissen wir alle, warum wir hier sind und wie es aussieht, zu gewinnen? Kennen wir den Plan bzw. die Strategie? Können wir irgendwie feststellen, an welchem Punkt wir uns gerade befinden? Erkennen wir Hindernisse, die uns ausbremsen? Versuchen wir permanent, diese Hindernisse zu beseitigen?

Die Antwort auf einige dieser Fragen ist höchstwahrscheinlich „Nein” (sollte es anders sein, gratuliere ich. Weiter so!) Das ist also die Aufgabe von einem Agile Leader: zu tun, was auch immer nötig ist, um diese Fragen mit „Ja” beantworten zu können. Das ist zwar keine Garantie für Erfolg, erhöht aber erheblich Ihre Chancen darauf.

Bei kleineren Vorhaben mit Scrum wird diese Arbeit von den bereits existierenden Rollen und mit Hilfe der Zusammenarbeit mehrerer Teams mit dem Bottom-up-Ansatz erledigt. Bei größeren Unterfangen geht die Abstimmung der vielen Teams oft schief und manche Dinge gehen zwischen den unterschiedlichen Bereichen in der Organisation einfach unter. Der Agile Leader legt seinen Schwerpunkt also hauptsächlich auf die Kommunikation und die Schaffung von Klarheit. Wenn alle Involvierten die gleiche Auffassung davon haben, wo man sich befindet, wo man hin will und warum, dann ist die Wahrscheinlichkeit wesentlich höher, dass man gemeinsam in diese Richtung gehen wird.

Jetzt bitte etwas konkreter! Was macht ein Agile Leader jetzt tatsächlich?

Was bedeutet das alles jetzt in der Praxis? Was konkret tut ein Agile Leader?

Ich sage es nicht gerne, aber es kommt darauf an! So, jetzt habe ich es gesagt.

Fragen Sie sich immer wieder: „Was muss geschehen, das jetzt noch nicht geschieht? Was kann ich tun, damit es geschieht und zwar ohne dass ich selbst zum Bottleneck werde?”

Noch ein Beispiel:

Sie merken, dass das Releasen nicht besonders gut funktioniert und dass eine bessere Release-Koordination der Teams nötig ist. Anstatt herumzurennen und zu versuchen, alles selbst zu koordinieren, teilen Sie das Problem einigen Teams Ihrer Teams mit. Sie hören nach, ob die Teammitglieder zustimmen, dass es wirklich ein Problem ist, und besprechen, wie man damit umgehen sollte. Sie beschließen, regelmäßig ein Meeting abzuhalten, in dem sich die Leute treffen, die etwas zu releasen haben, damit sie sich synchronisieren können und ein gemeinsames Dokument erstellen können, in dem jeder die anstehenden Releases einsehen und bearbeiten kann. Anfangs leiten Sie diese Meetings selbst, später werden sie aber von alleine laufen. Sie fordern die Teams dazu auf, das Release Management so weit wie möglich zu automatisieren. Mit der Zeit wird das Meeting überflüssig werden, weil die Teams direkt miteinander sprechen und somit ist die Releasekoordination kein Thema mehr.

Auch wenn ich Ihnen jetzt nicht konkret sagen kann, was ein Agile Leader tun sollte, kann ich Ihnen doch eine Liste mit Beispielen geben. Stellen Sie es sich so vor, dass Sie als Leader durch unterschiedliche Brillen schauen müssen. Einige dieser Dinge können Sie selbst tun. Zum Großteil sollten Sie aber einen Kontext schaffen, in dem diese Dinge ohne Ihr Zutun erledigt werden.

Anmerkung: Im Folgenden benutze ich den Begriff „sicherstellen”, denn natürlich kann auch ein „Leader” diese Dinge nicht erzwingen. „Sicherstellen” bedeutet in diesem Fall also „Tue alles nötige, um einen Kontext zu erschaffen, in dem diese Dinge geschehen können.” In der Praxis kann das Folgendes beinhalten: unterstützen, ermutigen, diskutieren, herausfordern, Meetings organisieren, Dokumente erstellen, Sachen visualisieren, informelle Gespräche usw.

Hier also eine Liste mit Dingen, um die sich ein Agile Leader kümmern muss:

  • Vision/Mission: Stellen Sie sicher, dass die Arbeit ein eindeutiges Ziel hat, eine klare Hypothese, klare Grenzen bzw. Umfang („was machen wir nicht”) und eindeutige Erfolgskennzahlen, die sich eher auf den Business Impact (Auswirkungen für das Unternehmen) beziehen anstatt rein auf das, was geliefert wird. Stellen Sie sicher, dass das jedem Involvierten vollkommen klar ist – den Teams ebenso wie den Kunden und anderen Stakeholdern.
  • Iteratives und inkrementelles Ausliefern: Stellen Sie sicher, dass die Arbeit in kleinere Teile aufgeteilt wird, sodass sie iterativ und inkrementell ausgeliefert werden kann und man nicht nur ein großes Release ganz am Ende hat. Vermeiden Sie, wenn möglich, große Projekte und versuchen Sie stattdessen, die Arbeit in eine Reihe kleinerer Projekte aufzuteilen.
  • Adaptives Planen: Stellen Sie sicher, dass Pläne erstellt und dann allen mitgeteilt werden. Stellen Sie sicher, dass Pläne eher adaptiv als vorhersehbar sind und aktualisiert werden, sobald man etwas dazugelernt hat. Stellen Sie sicher, dass Fristen bekannt gegeben werden und, wenn nötig, Prognosen erstellt werden. Auch diese sollen anhand empirischer Daten angepasst werden, während die Arbeit voran geht. Stellen Sie sicher, dass jeder über alle Einschränkungen (Frist oder Umfang) bescheid weiß.
  • Feedback: Stellen Sie sicher, dass es eine kurze Feedbackschleife mit enger und regelmäßiger Kommunikation zwischen Teams und Kunden gibt. Gemeinsames Planen, Demos usw. stellen sicher, dass Hypothesen und Annahmen früh in der Praxis getestet werden und dass man kontinuierlich dazulernt. Stellen Sie sicher, dass der Fortschritt anhand von tatsächlichen Releases, Feedback und Business Impact gemessen wird und nicht an der Einhaltung eines Plans.
  • Kontinuierliche Verbesserung und Teilen von Wissen: Stellen Sie sicher, dass Lernen und Verbesserung kontinuierlich geschehen während die Arbeit voranschreitet (also nicht nur am Ende) und dass die wichtigsten Erkenntnisse mit den Teams und mit allen Teilen der Organisation geteilt werden.
  • Fokus und Übereinstimmung: Stellen Sie sicher, dass alle Teilnehmer fokussiert und engagiert sind (kein Multitasking) und dass sie die gleichen Prioritäten haben. Vermeiden Sie Silos. Stellen Sie sicher, dass die Leute sich darauf konzentrieren, den größtmöglichen Business Impact mit dem kleinstmöglichen Aufwand bzw. Mitteln zu erreichen (etwas schaffen, anstatt geschafft zu sein!).
  • Beseitigung von Hindernissen: Stellen Sie sicher, dass Waste und jegliche Hindernisse visualisiert, priorisiert und systematisch beseitigt werden. Ermuntern Sie die Teams dazu, sich selbst für ihre Probleme verantwortlich zu fühlen und sie, wenn möglich, selbst zu beseitigen. Arbeiten Sie mit anderen Managern zusammen und nehmen Sie sich den Hindernissen an, die in höhere Führungsebenen weitergereicht werden müssen.
  • Entscheidungsfindung: Stellen Sie sicher, dass Entscheidungen „Just-in-time” von den Leuten erledigt werden, die den besten Einblick in die Materie haben – und das auf möglichst dezentrale Weise. Stellen Sie sicher, dass niemand zum Bottleneck beim Treffen von Entscheidungen wird (auch nicht Sie selbst). Minimieren Sie die Menge der Entscheidungen, die Sie selbst treffen müssen.
  • Visualisierung von Status und Fortschritt: Stellen Sie sicher, dass jeder das „Gesamtbild” sehen kann. Das beinhaltet beispielsweise Dashboards, die zeigen, wo man hin will und warum, wo man sich aktuell befindet, welche Hindernisse es gibt usw. Halten Sie es auf einem hohen Niveau und überlassen Sie die Details den Teams.
  • Fluss: Richten Sie die Optimierung auf einen lückenlosen Wertefluss aus und nicht auf die Ressourcennutzung. Halten Sie Ausschau nach Bottlenecks und Stellen, an denen sich etwas staut. Nutzen Sie Systemdenken und die Lean-Prinzipien, um das Liefern von „Business Value” zu optimieren.
  • Selbstorganisation und Autonomie: Verdeutlichen Sie, wie das Ziel und die aktuelle Situation aussehen, damit die Leute unabhängig denken und arbeiten können, ohne dass Sie Ihnen sagen müssen, was sie tun sollen. Stellen Sie sicher, dass den Leuten – anstelle von zu erledigenden Aufgaben – Probleme vermittelt werden. Nutzen Sie die kollektive Intelligenz der Gruppe, anstatt zu versuchen, alles alleine zu lösen.
  • Personal- und Kapazitätsplanung: Arbeiten Sie mit den Managern zusammen und stellen Sie auf diese Weise sicher, dass die richtigen Mitarbeiter und Teams zur richtigen Zeit verfügbar sind, denn so wird man schneller und die Erfolgschancen größer.
  • Budgets und Einschätzungen: Stellen Sie sicher, dass alle budgetbezogenen und vertraglichen Einschränkungen bekannt sind und gemanagt werden. Stellen Sie sicher, dass Einschätzungen von dem Team vorgenommen werden, das am meisten mit der aktuellen Arbeit zu tun hat, dass sie auf einem hohen Niveau gehalten werden und dass sie bei Bedarf angepasst werden. Stellen Sie sicher, dass Einschätzungen auch als solche behandelt werden – und nicht als Versprechen. Machen Sie die Kosten transparent.
  • Abhängigkeiten: Stellen Sie sicher, dass team- und unternehmensübergreifende Abhängigkeiten visualisiert und effektiv gemanagt werden und dass die Teams keinen Leerlauf haben, weil sie aufeinander warten müssen.
  • Funktionsübergreifende Zusammenarbeit: Nutzen Sie Möglichkeiten wie einen gemeinsamen Arbeitsplatz und funktionsübergreifende Kommunikationskanäle, um Silodenken zu vermeiden und eine bessere Optimierung zu erreichen.
  • Kommunikation: Erschaffen Sie ein Umfeld, das die Kommunikation mit hoher Bandbreite (höhere Häufigkeit und höhere Qualität der Informationsweitergabe) erleichtert und den Bedarf für überflüssige Dokumente, E-Mails und andere Kommunikation mit niedrigerer Bandbreite minimiert. Dokumente sollten dazu dienen, die Kommunikation zu unterstützen, und nicht, sie zu ersetzen.
  • Schnelles Scheitern: Schaffen Sie einen Kontext, in dem kleinere Fehlschläge früh und oft passieren können, wodurch das Risiko eines großen Fehlschlages ganz am Ende verringert wird.

Und noch ein besonderer Punkt: Motivation. Motivation ist die wichtigste Währung für jedes kreative und komplexe Unterfangen – und sie ist viel wichtiger als die Anzahl der Arbeitsstunden. Motivierte Menschen entwickeln schneller bessere Produkte. Der Unterschied kann erstaunlich sein! Motivation ist aber kein separater Punkt – man kann Menschen nicht einfach „motivieren”. Menschen werden durch Dinge wie Autonomie, Können und ein Ziel intrinsisch motiviert.

Ein gutes Grundprinzip ist folgendes: „Motiviere nicht die Menschen, sondern beseitige, was sie demotiviert!” Wenn die Leute mitbekommen, wie Sie echte Hindernisse aus dem Weg schaffen und ein vertrauensvolles Umfeld erschaffen, in dem sie effektiv arbeiten können, dann wird das diese Leute sicherlich mehr motivieren als ein Casual Friday, Freigetränke oder eine Tischtennisplatte.

Das ist aber eine lange Liste! Wo fange ich jetzt nur an?

Reduzieren Sie die Liste passend für Ihren Kontext!

Beispielsweise können Sie sich mit einigen Leuten zusammensetzen und die einzelnen Punkte bewerten. Stellen Sie sich dazu die Fragen „Wie wichtig ist das für uns?” und „Wie gut funktioniert das im Moment?”. Dann kürzen Sie die Liste auf die fünf Dinge, die am wichtigsten sind und im Moment nicht so gut funktionieren. Das können Sie dann als Grundlage für Ihre Suche nach einem passenden Agile Leader nehmen (oder, wenn Sie selbst derjenige sind, um die Arbeit zu priorisieren).

Wie sieht es mit der Verantwortung aus?

Ist der Agile Leader nun also der einzige Verantwortliche? Ist er der Einzige, der seinen Kopf hinhalten muss, wenn etwas schief geht?

Nein, definitiv nicht! Jeder der involviert ist, ist auch verantwortlich. Allerdings sollte man für sein Verhalten verantwortlich gemacht werden, nicht für die Ergebnisse.

Das mag zuerst etwas verrückt klingen, aber denken Sie einen Moment darüber nach…Hier weiterlesen./hypotext]

Ein Produkt kann scheitern, auch wenn das Team alles richtig gemacht hat – das kann aus willkürlichen Gründe passieren. Es kann auch fehlschlagen, weil irgendetwas passiert ist, worüber das Team keine Kontrolle hat. Und andersherum kann ein Produkt auch trotz schlechter Arbeit des Teams und der Teamleiter ein Erfolg werden – aus purem Glück oder weil es keine Konkurrenz gibt. Das alles wird noch schwieriger, weil man Erfolg und Misserfolg grundsätzlich nur schwer definieren kann und es dazwischen eine große Grauzone gibt.

Ein Agile Leader sollte dafür sorgen, dass, wenn eine Sache scheitert, sie zumindest so früh wie möglich scheitert. Das erreicht man mit schnellen Feedbackschleifen (regelmäßige Releases für den Kunden, „Validated Learning” etc.). Außerdem muss man dafür sorgen, dass man aus den Misserfolgen lernt und diese Erkenntnisse beim nächsten Produkt oder der nächsten Iteration des jetzigen Produkts einsetzt.

Wenn wir Fehler bestrafen, geben wir den Anreiz, Fehler verstecken zu wollen, und verringern so den Lerneffekt. Wenn wir Fehler bestrafen, geben wir außerdem den Anreiz, jegliches Risiko zu vermeiden, und ersticken damit Innovationen. Fehlschläge (und das damit verbundene Lernen) sollten zelebriert werden, nicht bestraft! Natürlich in einem gewissen Maße. Halten Sie die Feedbackschleifen kurz, damit Fehler keine schweren Folgen nach sich ziehen können.

Obwohl der Agile Leader nach außen hin sozusagen das „Gesicht” des Projekts/Programms/Produkts/etc. darstellt, wird er/sie nicht für Erfolge und Misserfolge verantwortlich gemacht. Allerdings ist der Agile Leader natürlich dafür verantwortlich, sich so zu verhalten, dass die Erfolgschancen möglichst hoch sind. Aber auch das trifft natürlich auf alle Beteiligten zu, nicht nur auf den Agile Leader.

Wer ist gut für diese Rolle geeignet?

Ein Agile Leader sollte auf jeden Fall (meiner Meinung nach):

  1. eine Leidenschaft für Produkt, Kunden, Nutzer und Business Impact haben.
  2. von der Rolle des Agile Leaders begeistert sein und sich zu 100 Prozent darauf konzentrieren wollen.
  3. an die meisten Punkte der oben genannten Rollenbeschreibung glauben und sich dahingehend entwickeln wollen.
  4. in irgendeiner Weise Erfahrungen in einer Führungsposition gesammelt haben (egal, in welchem Kontext).
  5. in irgendeiner Weise schon praktische Erfahrung mit agilen Arbeitsmethoden gemacht haben (in welcher Rolle auch immer).
  6. gewillt sein, Training/Coaching/Betreuung anzunehmen, um fehlende Eigenschaften zu erlangen und ausbaufähige Eigenschaften zu verbessern.
  7. gewillt sein, dazuzulernen und seine Eigenschaften als Agile Leader permanent zu verbessern.

Es gibt keinen perfekten Agile Leader, aber im Folgenden finden Sie die Definition eines wirklich grandiosen Agile Leaders. Ich erwarte von keinem, all diese Punkte zu erfüllen, aber je mehr desto besser:

  • Sie verfügen über unternehmerisches Denken und haben Freude daran, Leuten ein gemeinsames Ziel näher zu bringen.
  • Sie haben Erfahrung damit, große funktionsübergreifende Vorhaben zu managen (wo Dinge wie Entwicklung, Marketing, Inhaltserstellung, rechtliche Fragen, etc. zusammenlaufen). Egal, ob das mit Agile zu tun hat oder nicht. Einige der besten Leader, die ich jemals kennengelernt habe, hatten große Fehlschläge hinter sich – sie wissen, wie man ein Projekt leitet.
  • Sie sind flexibel und pragmatisch bezüglich der Methoden und Prozesse und sind in der Lage, zu entscheiden, welches Modell und welcher Ansatz am besten in Ihren Kontext passt.
  • Sie haben ein tiefes Verständnis und Erfahrung im Hinblick auf Agile und Lean. Außerdem haben Sie etwas Erfahrung mit konkreten Frameworks wie Scrum, Kanban, Lean Startup und Continuous Delivery.
  • Sie meiden Wasserfall-Projekte, wissen aber auch, dass in Agile Planung und Architektur nicht grundsätzlich ausgeschlossen sind.
  • Sie wissen, wie Sie gut führen können, ohne zum Bottleneck zu werden.
  • Sie wissen, wie man Leute inspiriert und ihnen ein höheres Ziel nahelegt.
  • Sie verstehen, dass Menschen nun mal Menschen sind – und keine Ressourcen – und dass Konzentration und Motivation wichtiger sind als viele Arbeitsstunden.
  • Sie haben verstanden, dass Leute am motiviertesten und effektivsten sind, wenn sie ein Problem lösen sollen anstatt eine vorgegebene Lösung umzusetzen.
  • Sie wissen, wie Sie Mitarbeiter verschiedener Abteilungen und über andere organisatorische Grenzen hinweg dazu bringen, miteinander zu sprechen. Sie lassen sich von der Unternehmenspolitik nicht abschrecken.
  • Sie wissen, wie Sie die Selbstorganisation bei großen, funktionsübergreifenden Unterfangen unterstützen können und wie Pull-basierte Zeitplanung in der Praxis funktioniert.
  • Sie wissen, wie Sie alles Wichtige sichtbar machen können.
  • Sie haben ein Talent dafür, Waste zu erkennen und darauf aufmerksam zu machen.
  • Sie verstehen, dass Pläne wichtig sind, aber auch, dass sie lediglich ein Tool und kein Ziel darstellen und dass sie anhand von neuen Erkenntnissen aktualisiert werden müssen.
  • Sie verstehen, dass Ungewissheit zur Innovation dazu gehört und am besten mit kurzen Feedbackschleifen statt mit detaillierter Planung gemanagt wird.
  • Sie machen die Leute eher für ihr Verhalten als für ihre Ergebnisse verantwortlich. Sie belohnen sie für neugewonnene Erkenntnisse, anstatt sie für Fehler zu bestrafen.

Schlusswort

Ich hoffe, dass dieses Dokument Ihnen helfen wird, die Erfolgsquote bei der Zusammenarbeit mehrerer Teams zu verbessern. Aber denken Sie daran, dass das Ausweiten von Projekten usw. auf mehrere Teams immer das letzte Mittel sein sollte, denn es ist immer ein Nachteil, egal, wie gut man damit umgeht. Daher sollte man die Dinge so klein wie möglich halten.

Vielen Dank an Alistair Cockburn, Mary und Tom Poppendieck, Anders Haugeto und einige Leute von Spotify und Crisp, die mir alle geholfen haben, diesen Artikel zu schreiben. Ich fühle mich geehrt, so tolle Ratgeber zu haben!

Ich möchte betonen, dass dies meine persönliche Meinung zum Thema Agile Leader ist. Vielleicht ist jemand anderer Meinung, aber das ist auch in Ordnung.

Dieser Text stammt aus dem Blog von Crisp und wurde von uns ins Deutsche übersetzt.

 

Das könnte dich auch interessieren

Ein Team hat ein gemeinsames Ziel Wann ist man ein Team? Im Moment bin ich Teil eines wirklich tollen Teams. Wir haben zwar nicht einmal einen vernünftigen Backlog aber e...
Wie man in Agile das Beste aus seinen Fehlern macht   Schief gelaufen?!   Mir wurde einmal diese hypothetische Frage gestellt: Wenn jemand einen großen Fehlschlag für ein...
Produkte, die Nutzer lieben: Von der Idee zum Backlog Vision und Backlog Scrum bietet einen perfekten Rahmen, um ein Produkt mit den passenden Features zu entwickeln. Scrum hilft dem Product Ow...