„Was wir aus der agilen Softwareentwicklung lernen können“
Laterale Führung ist das Führen ohne Weisungsbefugnis. Unternehmen haben heute komplexe Aufgaben zu erledigen. Der Projektverlauf ist nicht planbar, weil mehr unbekannt ist als bekannt. In einer globalisierten Welt ist das Wissen das ein Unternehmen hat, das größte Potenzial. Ursache ist in eine sich ständig wandelnde Welt. Die Geschwindigkeit der Veränderung wird schneller und schneller. Unternehmen sind im Wissenszeitalter weitgehend netzwerkartig strukturiert. Bereichsgrenzen und Hierarchiestufen spielen eine immer kleinere Rolle. Unternehmensübergreifende Teams strukturieren sich, um Projekte gemeinsam durchzuführen.
John Kotter, der amerikanische Experte für Change, hat in den letzten Jahren die Erkenntnis gewonnen, dass Hierarchien kontraproduktiv sind, wenn es gilt dem beständigen Wandel zu begegnen.
Videos von Kotter:
Organizational Hierarchy – http://www.youtube.com/watch?v=CxLC3BXZ1Ek
The Evolution of the 21st Century Organization – http://www.youtube.com/watch?v=Pc7EVXnF2aI
Teamwork statt Einzelkampf
Die Softwareentwicklung hat in den letzten Jahren ein Maß an Komplexität angenommen, dass Unternehmen die erfolgreich in ihrem Markt bestehen, wollen das gesamte Potenzial ihrer Mitarbeiter nutzen müssen. Das funktioniert nur dann, wenn die Summe aller Teile mehr ist, als der Einzelne. Teamwork ist Trumpf. So hat sich die agile Softwareentwicklung durchgesetzt. Statt starrer Prozesse gibt es hier einen Rahmen, der die Spielregeln bestimmt. Dieser wird von dem Team ausgefüllt. Bei der agilen Methode Scrum gibt es den Scrum Master. Dieser hilft dem Team die Spielregeln mit Leben zu füllen und Konflikte zu lösen.
Das muss man sich so ähnlich wie beim Fußball vorstellen. Der Trainer sitzt während dem Spiel auf der Tribüne und kann nur auf freiwillige Gefolgschaft setzen.
Spielregeln statt Chaos
Teamwork braucht Spielregeln, genau wie bei einem Fußballspiel. Diese funktionieren nur dann, wenn Konsens darüber besteht, welches Spiel wir spielen: Fußball oder Rugby?
Scrum stellt einen Satz Spielregeln dar, der einem Team als Basis Rahmenpaket dient. Dies ist eine gemeinsame Grundentscheidung und jeder muss sein Committment dazu geben und seine Bedenken äußern dürfen. Zusätzlich dazu gibt es Vereinbarungen im Team und mit dem Management. Diese müssen immer wieder neu ausgehandelt werden.
Führung via Feedback
Weiterentwicklung durch institutionalisierte Reflexion und Wertschätzung wird groß geschrieben. Das schwäbische Motto „Nix gesagt ist genug gelobt“ reicht nicht aus, um immer neu zu lernen. Das bedarf einer gewissen Kritikfähigkeit. Dazu ist es sinnvoll, wenn alle Beteiligten empathische Kommunikationstechniken üben, wie die Methode der „Gewaltfreien-Kommunikation“ von Marschall Rosenberg. In agilen Projekten evaluieren wir das Ergebnis zusammen mit den Kunden im Review Meeting. Hier wollen wir wertschätzendes konstruktives Feedback und kein Lob, Tadel oder Beifall. Es ist Kommunikation auf Augenhöhe. Diese müssen wir lernen.
Führen mit Zeitboxen
Ein Sprint ist eine Etappe mit fester Zeiteinheit. Am Anfang steht die Planung und am Ende das Feedback. Es ist ein Irrtum zu glauben, dass agile Führung ohne Planung auskommt. Die geplanten Einheiten sind überschaubar und damit eine Risikoeinheit. Es geht vor allem darum, den aktuellen Plan immer wieder zu korrigieren und sich Feedback von Kunden und Stakeholdern einzuholen. Es geht natürlich auch um das Committment den ursprünglichen Plan einzuhalten. Wenn sich der jedoch als falsch herausstellt, dann ist es notwendig so schnell wie möglich Korrektur einzuleiten. Diese Korrekturen sind mit kleinen Zeitspannen einfacher durchzusetzen. Die Zeiteinheit sollte also so kurz sein, dass das Risiko welches das Management eingeht, wenn das Team in die falsche Richtung marschiert, kalkulierbar ist.
Führen mit Zielen
In einem Projekt kann es unterschiedliche Ziele und Motivationen geben. Die Produktvision sollte bei einer Produktentwicklung immer im Vordergrund stehen. „Was“ bauen wir hier eigentlich.
Eine zweite Frage, die wir uns stellen müssen ist das „warum“. Diese Frage wird jeder anders beantworten. Ein Dienstleister der ein Produkt umsetzt, hat ein anderes „warum“, als der eigentliche Product Owner. Für ein Entwicklerteam ist das „warum“ die stärkste Motivationsquelle und deshalb sollte diese Frage für alle Mitglieder die gleiche Antwort haben.
Fazit
Laterale Führung ohne Weisungsbefugnis muss motivieren und kann nicht auf alt bewährtes wie Belohnung durch Bonus, Strafe, Verführung durch Statussymbole oder Geheimwissen zurückgreifen.
