Nach diesen vier Prinzipien gehe ich dabei vor:

• Für welche Zielgruppe lösen wir Probleme bzw. welches Bedürfnis welcher Zielgruppe adressieren wir?
• Welche Ziele verfolgen dieses Vorhaben?
• Was soll das Vorhaben umfassen, was liefert es?
• Und zuletzt: Wie kann das Vorhaben schnell starten?

Das Vorgehen zieht sich kompakt über 2-4 Wochen. Das kann für einige Organisationen echt sportlich sein, fördert aber schnelle Generierung von Erkenntnissen und Durchführung von konkreten Experimenten. Je schneller sich ein Team weg von Planung und Überlegung bewegt, desto besser. Treiber des Vorgehens sind in der Regel Product Owner oder Projektleiter. Teilnehmer sind darüber hinaus relevante Stakeholder/Nutzer und natürlich das gesamten Team (oder Teile davon). Folgende Tätigkeiten wähle ich üblicherweise bei der Vorgehensweise:

1. Stakeholder identifizieren und einordnen

Zuallererst lohnt es sich, alle Stakeholder zu identifizieren und diese zu klassifizieren. In allen Nachfolgeschritten werden nur die relevanten Stakeholder eingebunden. Und diese Gruppe sollte so klein wie nur irgendwie möglich sein. Alle weiteren Schritte im Vorhaben sind eher zu meistern, wenn nicht jeder Stakeholder mitredet und mitbestimmt. Zu groß ist das Risiko, dass Ziele und Inhalte verwässert werden, wenn die Anzahl der Stakeholder zu groß ist. Hier heißt es, konsequent zu sieben, was meist unangenehm ist. Dafür bietet sich die Power-Interest-Matrix an, die Roman Pichler hier vorstellt.

Siehe dazu auch dieser Beitrag von mir.

Um die Stakeholder – Auftraggeber, Nutzer etc. – zu sieben, werden sie anhand vier Kategorien aufgeteilt:

• Player –  z.B. verantwortliche Produktmanager, Auftraggeber und Manager aus Fachabteilungen mit denen das Team eng zusammenarbeitet.
• Subjects – z.B. interessierte Produktmanager und abhängige Produktteams, die die Marschrichtung des Teams nicht spürbar beeinflussen, deren Feedback oder Beratung jedoch wichtig ist.
• Context Setters – z.B. mittleres und höheres Management. Nehmen nicht an der Produktentwicklung teil, schaffen jedoch organisatorische Rahmenbedingungen.
• Crowd –  Alle anderen, die über das Produkt informiert werden, jedoch keinen Einfluss auf Produktentwicklung haben.

Üblicherweise fallen viele Stakeholder in die „Crowd“ – diese wird zukünftig nur noch informiert. Die Player werden in Konzeption, Planung und Priorisierung eingebunden, Subjects in Tests und Interviews.

Hört sich sehr einfach an, ist es in der Praxis natürlich nicht. Insbesondere in Organisationen, die an „Jeder muss bei allem mitreden“ gewöhnt sind. Aber auch hier hilft es, die Player frühzeitig zu identifizieren. Sie helfen dem Team als erster Ansprechpartner und sind Proxy für ihre jeweilige Organisation.

2. Auftrag klären und Ausrichtung geben

Zu Beginn eines Vorhabens steht immer eine Idee oder ein Auftrag – ausgehend vom Team oder von außerhalb. Um einen ersten Navigationspunkt zu setzen, empfehle ich daher den Auftrag zu klären. Welches Problem soll eigentlich gelöst werden? Warum? Und welche messbaren Ziele verfolgen wir? Erst durch diese Klärung entsteht eine klare Ausrichtung, an der sich Team und Stakeholder orientieren. Ohne messbare Ziele und ohne Klarheit über den Problemraum startet ein Vorhaben schnell schwammig und orientierungslos. Ein gutes Werkzeug zur Auftragsklärung ist der gleichnamige Steckbrief von Xing.

Der Steckbrief verfügt über sieben Felder.

• Situation – Was ist die Ausgangssitutation des Vorhabens?
• Complication – Was ist der Auslöser des Vorhabens?
• Higher Intent – Wie zahlt das Vorhaben auf die Vision (Team-, Produkt- oder Unternehmensvision)?
• Intent – Was wollen sie mit dem Vorhaben wirklich erreichen?
• Boundaries – Was darf nicht passieren? Was nicht Teil des Vorhabens?
• Hypotheses – Welche Annahmen zum Mehrwert des Vorhabens machen sie?
• Input – Welche Rollen/Skills benötigen wir? Wie sieht der finanzielle Rahmen aus?
• Output – Was bekommen die Kunden zu sehen? Timings?
• Outcome – Woran messen wir den Erfolg des Vorhabens?

Ich empfehle, pro Feld maximal vier, besser nur zwei präzise formulierte Punkte zu verfassen. Besser ausgedrückt, ist die fertige Auftragsklärung schnell verständlich und eingängig. So eine Auftragsklärung nehme ich in kurzen Workshops (2-3 Stunden) vor. Teilnehmer einer Auftragsklärung sind PO, mindestens Teile des umsetzenden Teams und die relevanten Stakeholder.  Zu jedem Feld sollte es aber kurze Analysen im Vorfelde geben. Besonders zu „Complication„, „Hypotheses und „Outcome„. Hier gilt es noch nicht, alles bis ins kleinste Detail zu durchleuchten, aber schon früh sich darüber einig zu sein, was als wichtigstes Problem angesehen wird, welche Ideen/Hypothesen es gibt, diesen zu lösen und wie die Lösung grob aussehen könnte. So holen wir alle Beteiligten früh ins Boot.

3. Lösungen entwerfen

Okay, nachdem wir das Vorhaben umrissen haben, durchleuchten wir den Problemraum weiter und entwerfen wir die erste Lösung. Das lässt sich am besten mit einer Product Discovery umsetzen. Die Product Discovery lässt PO, Team und Stakeholder das neue Produkt entdecken. Welches Problem löst das neue Produkt? Wie macht es das? Wie sieht es aus? Die Discovery läuft über einen Sprint (wieder sehr sportlich, fördert aber Ergebnisorientierung), das Ergebnis sind Artefakte wie ein Produkt-Steckbrief, Scribbles von der User-Journey und am besten auch ein erster Prototyp. Eingangsdaten sind wiederum Kundenfeedback, Daten (z.B. Tracking, Transaktionen etc.) usw. alles was man kriegen kann, um den Problemraum besser zu durchdringen und um erste Anregungen für neue Ideen zu haben.

Wichtig ist, hier offen und breit zu denken. Es geht darum, möglichst viele Lösungsoptionen zu generieren und deren Hypothesen prototypisch zu beweisen oder zu widerlegen. Lange Diskussionen oder persönliche Befindlichkeiten bringen niemand weiter. Was zählt ist Feedback vom Kunden und das wollen wir hier schnell einholen.

Der Ablauf einer Product Discovery ähnelt dem Design Thinking. Infolgedessen läuft sie so ab:

1. Den User verstehen (viele Daten heranziehen, Erkenntnisse daraus ziehen)
2. Das Problem verstehen (verdichten – welche Probleme sind besonders schwerwiegend?)
3. Lösungsoptionen entwerfen (aufspannen – möglichst viele Ideen generieren)
4. Einschränken (verdichten – auf die vielversprechendsten Ideen beschränken)
5. Validieren (ausprobieren, Hypothesen testen, Feedback einholen)

Eine hervorragende Sammlung von Methoden für Product Discoveries findet sich im Product Discovery Activity Guide der New York Times. Der einwöchige Google Design Sprint ist ebenfalls ein exzellentes Vorgehen hierfür.

Am Ende der Discovery muss klar sein, welches Problem gelöst werden soll. Warum ist es das wichtigste Problem? Für welche Zielgruppe wird das Problem gelöst? Das gleiche gilt für das Produkt: Was liefert das Produkt? Wie sieht es für die Zielgruppe aus? Welche Geschäftsziele verfolgt oder unterstützt das Produkt? Sind all diese Fragen beantwortet und strukturiert erfasst (Steckbriefe, Steckbriefe, Steckbriefe!), so ist eine starke Ausrichtung für das Vorhaben geschaffen. Die Leitplanken sind gesetzt, in dem sich die Umsetzung zukünftig bewegt.

4. Das Vorhaben strukturieren

Sind die Leitplanken gesetzt, können Product Owner und Team sich einen Überblick über notwendige Features/Stories und Umfang des gesamten Vorhabens verschaffen. Dazu empfiehlt sich eine Story Map. Das Vorhaben wird zunächst nach potentiellen Vorgängen (z.B. „Bezahlung“, „Produktsuche“) unterteilt. Die Vorgänge werden nach ihrer in der Praxis vermuteten zeitlichen Reihenfolge sortiert.

Zu jedem Vorgang sammeln PO und Team nun die notwendigen Features/Stories.

Nun haben wir einen sehr guten Überblick über die Stories unseres Vorhabens, nur sind nicht alle gleichermaßen wichtig. Daher wird die Map nach Releases aufgeteilt. Stories können verschoben werden, so dass sie für ein bestimmtes Release geplant werden. Im Zuge dieser Planung gibt es auch immer wieder Stories die einfach unwichtig sind und gestrichen werden können.

Im Laufe der Umsetzung sammelt ein Team kontinuierlich Erkenntnisse, die neue Features hervorbringen oder bestehende überflüssig werden lasse. Daher ist eine einmal erstelle Story Map auch nicht beständig und erfüllt ihren Zweck für mich vor allem in den ersten Wochen eines Vorhabens. Üblicherweise lasse ich nach den ersten Sprints die Features des Vorhabens in die Roadmap (die aber auch – je nach Geschmack – eine kontinuierlich gepflegte Story Map sein kann) einfließen. Nur Stories für die nächsten 2-3 Sprints liegen ausformuliert im Backlog.

Gute Artikel zum User-Story-Mapping finden sich hier und hier.

5. Schnell anfangen, schnell scheitern

Nach Erstellung der ersten User-Story-Map, kann die Umsetzung grundsätzlich beginnen.

Eine gute Methode, um einen ersten Prototyp zu erstellen, ist das Walking Skeleton. Das Walking Skeleton ist ein möglichst schnell errichteter Prototyp eines Vorhabens. Daten fließen vom Anfang bis zum Ende und berühren alle beteiligten Systeme. Dabei kommt es nicht auf Vollständigkeit, Stabilität, Eleganz oder Performance an. Das Walking Skeleton macht möglichst früh transparent , wo große technische Risiken (üblicherweise: Infrastruktur und unbekannte Technologien) schlummern und wie sie sich in der Praxis bemerkbar machen. So erhält das Team früh ein Gefühl dafür, wie es damit umgehen will. Lassen sich einzelne große Risiken isoliert betrachten, empfiehlt sich eher ein Spike. Diese Methode lässt sich während der gesamten Umsetzung immer wieder einsetzen.

Ein potentielles Ergebnis dieses risikobasierten Vorgehens kann auch sein, dass sich das Vorhaben nicht umsetzen lässt. Aber so wird es früh transparent und eben nicht erst zum Ende.

The post Komplexität kontern appeared first on Reza Nazarian.

Doch was passiert, wenn das besagte Team anfangen will, agil zu arbeiten? Zunächst hilft es, wenn das Team cross-funktional aufgestellt wird. Das Team verfügt über alle Fähigkeiten, sein Produkt mit möglichst wenig spürbaren externen Abhängigkeiten umzusetzen. Beispielsweise kann ein cross-funktionales Entwicklungsteam sein Produkt entwickeln, testen, produktiv stellen und betreiben. Und es organisiert sich dabei selbst, so dass Umsetzung, Zusammenarbeit und Vorgehensweise selber bestimmt werden. Zweck und Sinn des Produkts sind klar herausgearbeitet. Der Fokus des Teams liegt darauf, kontinuierlich wertvolle Produktinkremente zu liefern und nah am Kunden zu sein.

Erste Hürde: Alte Organisationsstruktur

Das erste was Teams in der Transition zur Cross-Funktionalität und Selbstorganisation im Wege steht sind alte Organisationsstrukturen. Und ist das agile Team mit Spaß und Selbstbewusstsein unterwegs, stellt es auf einmal diese alten Strukturen infrage und lässt diese (hoffentlich) bröckeln. Aber wie kommt es dazu? In einer hierarchischen Organisation gibt es funktionale Teams (Entwickler, Projektleiter, Tester etc.). Ein cross-funktionales Team setzt sich aus Mitgliedern der funktionalen Teams zusammen – die Hierarchie bleibt aber bestehen. Die Mitarbeiter des cross-funktionalen Teams, die sich eigentlich auf das eine Produkt ausrichten möchten, berichten weiterhin ihren ursprünglichen Abteilungsleiter. Das heißt, dass das Team weiterhin im Einflussbereich von mehreren Abteilungsleitern steht. Das führt zu Konflikten, wenn jeder Abteilungsleiter seine Abteilungsinteressen weiterhin in dem Team verfolgt und verhindert, dass das Team seinen Job gut macht.

Erste Hilfe: Abbau von Organisationsstruktur

Nach der Einführung von Agilität auf Teamebene, ist der nächste Schritt also die Veränderung der Organisationsstruktur. Genauer gesagt, der Abbau. Eine Matrix-Organisation hilft aus meiner Sicht erstmal wenig. Sie ist nur ein Versuch, die alte Struktur zu retten. Die Matrixorganisation hat ihren Fokus eher darauf, die Auslastung zu optimieren. So fördert sie auch weiterhin Abteilungsinteressen und weniger die Leistungsfähigkeit von Produktteams. Was hierarchische Organisationen hervorgebracht haben, sind Misstrauen, Kontrolle, Intransparenz und Distanz.

Der Abbau von alten Strukturen bedeutet, dass jedes Produktteam zu einer abgeschlossenen Organisationseinheit wird. Doch was für einen Schritt muss die Organisation hierfür gehen? Keinen kleinen, soviel ist klar. Denn es findet ein Wechsel weg von Misstrauen, Kontrolle, Intransparenz und Distanz (die alte Industriekultur) statt. Weniger Führungskräfte als vorher sind für ein Produktteam verantwortlich. Verantwortlich in dem Sinne, dass sie alles tun, damit Teams gut arbeiten. Weniger Führungskräfte bedeutet auch Aufbau des Vertrauens, Förderung der Verantwortung (für erste Schritte empfehle ich Delegation Poker) – bei gleichzeitiger Erhöhung der Transparenz (woran arbeitet ein Team? Warum? Ist das Team erfolgreich?).

Das alles umfasst die beiden Prinzipien von Agile Leadership: Servant Leadership und Alignment.

Servant Leadership – Alles tun, damit Teams gut arbeiten

Mit diesem neuen Begriff tun sich viele Leute schwer. Mit Servant – Diener – verbinden Führungskräfte Machtverlust und Unterwürfigkeit. Aber es beschreibt sehr gut die neue Rolle der Führungskraft. Diese sorgt zukünftig dafür, dass das Team seine Arbeit gut machen kann. Dazu gehört, dass dem Team Hindernisse aus dem Weg geräumt werden. Ein Beispiel dafür sind die eingangs erwähnten alten Organisationsstrukturen. Hier wird auch klar, was der Unterschied zum ScrumMaster ist, der auf Teamebene ebenfalls Hindernisse beseitigt. Der agile Leader ist Führungskraft und hat das Mandat, dem Team innerhalb der Gesamtorganisation den Weg zu bahnen. Weitere Beispiele sind die Neuorientierung von Verträgen mit Dienstleistern und Zulieferern.

Als Führungskraft hat der agile Leader die Aufgabe, die passenden Rahmenbedingungen für das Team zu schaffen. Ein typisches Beispiel hierfür ist die Schaffung eines Recruiting-Prozesses, der so gut wie möglich auf das Team zugeschnitten ist.

Alignment – Ausrichtung geben

Jedes Produktteam möchte seine Produkte erfolgreich sehen. Doch was ist eigentlich Erfolg? Und wie weit ist das Team vom Erfolg entfernt? Hier kommt die zweite wichtige Eigenschaft des agile Leaders ins Spiel: Alignment. Die Führungskraft gibt nicht mehr vor, was zu tun ist. Sie definiert für ein oder mehrere Produktteams Ziele und Metriken, um die Zielerreichung zu messen.

Gemessen wird kontinuierlich, damit alle wissen, wie weit die Zielerreichung noch entfernt ist. Die Artefakte einer Führungskraft sind hier Vision, Roadmap und Strategie. Je klarer und je messbarer diese Artefakte sind, desto eher ermöglichen sie dem Team Ausrichtung für dessen Arbeit. Eine klare Ausrichtung ist die Grundlage für Priorisierung von Themen und die Auswahl von Features (was ist wichtig, was nicht? was ist Pflicht, was ist Kür?).

Das Produktteam plant basierend auf der Ausrichtung des agile Leaders seine Produktvision, seine Produktroadmap und sein priorisiertes Backlog. Die Führungskraft führt hier durch konsequente Ausrichtung.

Verschwinden nun die meisten Führungskräfte?

Agile Führungskräfte fokussieren sich auf Servant Leadership und Alignment. Um diese beiden Eigenschaften auszufüllen, rückt die Führung wieder in den Vordergrund. Es kommt bei einem agile Leader weniger darauf an, dass er nach jahrelanger guter fachlicher Arbeit befördert wird. Vielmehr kommt es darauf an, dass ein agile Leader gute Führungseigenschaften mit sich bringt. Sind sie Führungskraft? Überlegen sie sich doch mal für sich selbst: Wie viel beschäftigen sie sich mit Management, wie viel mit Führung (siehe auch dieser Artikel dazu)?

Um auf die obige Frage zu antworten: Jein. Die meisten Führungskräfte verschwinden nicht. Sie richten sich vor allem neu aus, aber das wird sicherlich nicht jedem liegen. Schließlich geht es weg von steiler Hierarchie, hin zur Arbeit auf Augenhöhe. Ob einzelne Führungspositionen wirklich wegfallen, hängt stark von der Komplexität der Führungsstrukturen im Unternehmen ab. Je komplexer und je mehr Führungskräfte, desto höher die Wahrscheinlichkeit, dass für gut selbstorganisierte und ausgerichtete Teams weniger Führungskräfte benötigt werden.

Artikelbild lizensiert von shutterstock

The post Agile Leadership – Wo bleiben die Führungskräfte? appeared first on Reza Nazarian.