Agilität, agile Führung, agiles Arbeiten sind nicht nur Buzzwords, sondern moderne Arbeitsweisen, ohne die Unternehmen der Komplexität unseres Wirtschaftslebens nicht mehr begegnen können. Wenn ein Unternehmen nun agile Arbeitsweisen einführen möchte, ist eines entscheidend: die Organisationsstruktur darauf auszurichten – sonst krachen traditionelle hierarchische und moderne nicht-hierarchische Strukturen aufeinander und es gibt Konflikte unterschiedlichster Art. Schlussendlich wird der agile Ansatz als Schuldiger identifiziert, den es dann so schnell wie möglich wieder abzuschaffen gilt. Hier stelle ich Ihnen ein Modell vor, das dies verhindert und mit dem sich agiles Arbeiten gut in eine bestehende Organisationsstruktur einführen lässt.

Betriebssystem 1 und Betriebssystem 2: zwei verschiedene Organigramme, ein Unternehmen

Am erfolgreichsten ist der Ansatz, zusätzlich zum hierarchischen Organigramm bzw. „Betriebssystem 1“ ein zweites, agiles Organigramm aufzubauen, das „Betriebssystem 2“. Konkreter Anlass dafür ist oft die Entwicklung eines neuen Produkts oder einer Dienstleistung, die dann agil vonstattengehen soll. Dafür kann dann z.B. ein Scrum Team aufgebaut werden.

Im Betriebssystem 1 ist der Geschäftsführer dafür zuständig, gewisse Ziele vorzugeben, Vision, Mission, Roadmaps etc., sein Pendant im Betriebssystem 2 ist der Product Owner. Vision, Mission und Strategie für das Betriebssystem 2 kommen jedoch zu Beginn des Prozesses aus dem Betriebssystem 1, und zwar von einem agilen Führungsteam. Dieses Team besteht zunächst sicherlich mehrheitlich aus Personen des Betriebssystems 1. Der Product Owner und der Scrum Master aus dem Betriebssystem 2 gehören aber definitiv auch dazu. Dieses agile Führungsteam schlägt nun Vision, Mission und Strategie beispielsweise für die Entwicklung eines neuen Produkts vor. Wichtiger Erfolgsfaktor für die Umsetzung von Vision, Mission und Strategie: Der Product Owner aus dem Betriebssystem 2 muss voll und ganz davon überzeugt sein – sonst kann er die Product Vision nicht mit voller Energie in sein Team tragen und umsetzen.

Beide Betriebssysteme optimal miteinander verbinden

Im Unternehmensalltag macht das agile Führungsteam schon sehr bald keine strategischen Vorgaben mehr, sondern die Menschen aus beiden Betriebssystemen werden Sparringspartner auf Augenhöhe. Denn im Laufe der Zeit sammelt der Product Owner mehr und mehr Erfahrung, Kundenfeedback etc. und kann im Zuge dessen selbst die Verantwortung für die Vision, Mission und Strategie übernehmen. Er passt dann die Geschäftsstrategie des Betriebssystems 2 permanent an. Ein wesentliches Merkmal agilen Arbeitens ist es, dass die Erfahrungen von Kunden mit dem Produkt ständig in den Entwicklungsprozess einfließen. Dies macht die Anpassung der Strategie nötig. Für die Roadmap, EPIC Ziele und Sprint Ziele ist er natürlich ebenfalls von Anfang an selbst verantwortlich.

Das Agile Leadership Team dagegen kümmert sich mit dem Fortschritt des Prozesses primär um die Transformation der Firma. Das Vorschlagen der Vision für das Betriebssystem 2 war davon ein kleiner Teil. Das Agile Leadership Team ist keinesfalls eine lenkende Einheit für das Betriebssystem 2! Es macht gewisse Vorgaben und redet mit, aber nur auf strategischer, nie auf operativer Ebene. Auf diese Art und Weise werden beide Betriebssysteme optimal miteinander verbunden – und das Scrum Team ist nicht in die Hierarchie hineingezwungen, sondern kann innerhalb seines Rahmens frei agieren.

Transparenz des Betriebssystems 2

Dabei erzeugt das Scrum Team durch Reviews volle Transparenz gegenüber den Stakeholdern. So legt der Product Owner beispielsweise in einem Public Product Backlog oder in einer Public Roadmap, auf die alle lesend zugreifen können, die aktuelle Priorisierung, die Roadmap etc. offen. Ganz wichtig dabei: Auch das Agile Leadership Team ist „nur“ ein Stakeholder.

Den Stakeholdern ist es jederzeit freigestellt, ihre Anforderungen und Wünsche zu äußern. Sie können auch argumentieren, welchen bereits bestehenden Anforderungen eine höhere Priorität eingeräumt werden sollte. Jedoch liegt die letztendliche Entscheidung darüber ausschließlich beim Product Owner. Sind aus Sicht des Product Owner andere Dinge für das Produkt, die Produktvision und den Produktwert wichtiger, dann ist das so. Der Product Owner ist der Verantwortliche und (wie ich ihn immer nenne) der Wert-Maximierer/Value-Maximizer. Diesen Fakt zu akzeptieren, fällt jedoch nicht allen Stakeholdern leicht. Der Product Owner steht eigentlich immer kurz vor der Kündigung – denn in den Regelterminen versuchen Investoren meist deutlich, die Strategie, die Roadmap usw. zu beeinflussen, ganz ungeachtet der Tatsache, dass sie im Betriebssystem 1 verankert sind und im Betriebssystem 2 inhaltlich und fachlich nicht wirklich zu Hause. Der Product Owner hat dagegen immer im Fokus, was die Kunden wollen und das Produkt damit erfolgreicher macht– und nicht das, was Geschäftsführer und Investoren wollen. Daraus ergeben sich in der Praxis ganz klassische Interessenskonflikte, die dann auf die Person des Product Owners projiziert werden.

Ein Modell für agiles Arbeiten

Was viele Unternehmen falsch machen: Sie gehen von der Annahme aus, dass die agilen Scrum Teams keine Strukturen brauchen. Tatsächlich ist es jedoch so, dass diese Teams mehr Strukturen brauchen! Allerdings keine Strukturen, die den Teammitgliedern vorschreiben, was sie zu tun haben, sondern ihnen vielmehr einen Rahmen bieten, innerhalb dessen sie festlegen können, wie und was sie tun. Dafür bietet sich folgendes Modell an:

• Vision: Wo willst du in 50 Jahren sein?
• Mission: Wie willst du in den nächsten vier bis fünf Jahren voranschreiten?
• Strategie: Wie willst du in den nächsten drei Jahren vorgehen?
• Roadmap: Welche konkreten Schritte planst du in den nächsten 12 Monaten?
• Epic Ziele: Was hast du in den nächsten drei Monaten vor?
• Sprint Ziele: Was planst du in den nächsten ein bis vier Wochen zu tun?
• Story-Akzeptanz-Kriterien: In der User Story werden der Nutzer des Produkts, sein Wunsch und der Produktnutzen umrissen. Die Story-Akzeptanz-Kriterien beschreiben, welche Kriterien das Produkt erfüllen muss, damit es den Bedürfnisse des Nutzers entspricht.

Existiert kein solches Modell und entsprechend keine Vision, Mission, Strategie etc. im Betriebssystem 2, dann herrscht im Team Unruhe und Unsicherheit. Es fehlt der Rahmen, keiner weiß, wo es langgeht, niemand ist motiviert.

Wichtig dabei ist, dass Vision, Mission, Strategie und Roadmap permanent überarbeitet werden. Denn sie werden immer wieder angewandt beziehungsweise benötigt, um beispielsweise Kunden, Investoren und das agile Führungsteam etc. zu informieren. Die Strategie ändert sich aus meiner Erfahrung ca . alle sechs Monate, die Roadmap alle drei Monate.

Kunden in die Entwicklung einbeziehen

Agil zu arbeiten, bedeutet einen Mindshift zu vollziehen, Herangehensweisen komplett zu ändern. Der wesentliche Unterschied besteht darin, zu akzeptieren, dass Produkte und Dienstleistungen nicht in einem jahrelangen Prozess bis ins letzte Detail (und schlimmstenfalls am Markt vorbei) entwickelt werden, sondern schon in einem sehr frühen Entwicklungsstadium den Kunden präsentiert werden. Deren Rückmeldung fließt dann in die weitere Entwicklung mit ein.

Der Product Owner übernimmt dabei die Rolle eines Orchestrierers: Er holt sich die Inputs aus seinem Team (z. B. von den Entwicklern), von den Kunden, und er erzeugt volle Transparenz bei den Regelterminen im agilen Führungsteam, diskutiert dort die Strategie und gewährt Einblick in die Roadmap. Der Product Owner bringt alle diese Quellen zusammen und in Einklang, was nicht immer leicht ist.

Die Product Owner sind oft ehemalige Projektmanager. Um erfolgreich in einem agilen Umfeld zu arbeiten, müssen sie ihre Herangehensweisen ändern: Wo vorher Planungstools für Ressourcen und Meilensteine regierten und Kundenwünsche nichts verloren hatten, geht es im agilen Umfeld darum, früh und schnell Erfahrungen mit der Zielgruppe eines Produkts oder einer Dienstleistung zu sammeln und zu akzeptieren, dass man eher Unrecht hat beziehungsweise nichts weiß und deshalb am besten die Kunden fragt. Ehemalige Projektmanager können sehr gute Product Owner sein, keine Frage, vorausgesetzt, sie haben die entsprechende Ausbildung durchlaufen. Und sie müssen auch zulassen, dass sie und ihre Mitarbeiter sich gegenüber anderen Einflüssen öffnen und beispielsweise zu anderen Unternehmen gehen, sich mit ihnen vernetzen, sich austauschen, ihr Wissen teilen – und es nicht ängstlich hinter verschlossenen Türen halten.

Den Absatzmarkt intensiv und kontinuierlich reflektieren macht krisenfest

Letztlich geht es darum, gerade auch in Krisenzeiten, den Absatzmarkt für künftige Produkte und Dienstleistungen immer und immer wieder zu reflektieren und entsprechend darauf zu reagieren. Wenn im Betriebssystem 1 der Fokus sehr stark auf dem Betriebswirtschaftlichen liegt – Ziele werden meistens an Umsatzzahlen festgemacht, und Visionen sind etwas, was eingekaufte Berater im Nachhinein festlegen –, so steht im Betriebssystem 2 die Vision am Anfang. Die betriebswirtschaftlichen Aspekte sind zwar wichtig – Income, Outcome, Erstellung von Abschlussberichten, Liquidität und die Aussicht auf Rentabilität muss sichergestellt sein – keine Frage! Aber im Fokus steht die Vision, das Produkt und der Nutzen, den es stiftet. Die betriebswirtschaftlichen Werkzeuge sind genau das: Werkzeuge. Aber kein Selbstzweck. Der eigentliche Motivator ist die Produktvision. Sie sorgt dafür, dass die Menschen morgens gerne zur Arbeit kommen und Freude und Enthusiasmus dabei entwickeln. Die erfolgreichsten Unternehmen der Welt gründen nicht auf der Vision, innerhalb einer bestimmten Zeitspannen 100 Millionen Umsatz zu generieren. Sondern beispielsweise Menschen in Verbindung zu bringen, das Telefonieren so einfach wie möglich zu machen oder jeden Haushalt auf dieser Welt mit einem Computer auszustatten, um nur einige Beispiele zu nennen. Umgekehrt gilt: Alle Unternehmen, die in Schwierigkeiten stecken, haben an einem bestimmten Punkt ihre Produktvision verloren und sind lediglich zahlengetrieben.

Letztlich bringt uns die agile Arbeitsweise mit all ihren Rahmenbedingungen dazu, wieder den zentralen Faktor Nummer 1 für erfolgreiche Unternehmen in den Blick zu nehmen: den Absatzmarkt gründlich und kontinuierlich zu reflektieren. Mit den (potenziellen) Kunden zu reden. Aufgrund unserer Historie und Erziehung fällt das uns das oft schwer. Aber wer sein Unternehmen gut durch Krisen aller Art steuern will, hat keine andere Chance.

Mehr Praxiswissen zum agilen Arbeiten

Welche Aufgaben hat ein Agile Leadership Team? Wie schreibt man konkret eine Vision für ein Produkt oder eine Dienstleistung? Wie setzt man das oben dargestellte Visionsmodell in der Praxis ein? Wenn Sie zu diesen Themen oder zum agilen Arbeiten generell einen Sparringspartner suchen, melden Sie sich bei mir. Ich bin Maddox Tugendreich, bin seit dem ich zwanzig Jahre alt bin Entrepreneur, freiberuflicher agilitäts-Berater und Visionär. Mein Wissen und meine Erfahrung teile ich gerne mit Ihnen.