Agile Projekte reparieren

Kürzlich habe ich in dem Blogbeitrag Gründe, warum agile Projekte scheitern tiefer analysiert, welche Anzeichen und Verhaltensweisen den Erfolg von Projekten gefährden können. Genau diese Indikatoren aus dem Artikel sollten im Projektrisikomanagement beachtet werden. Individuell und vom Vorhaben abhängig, empfiehlt es sich Eintrittswahrscheinlichkeiten und Auswirkungen im Sinne einer Risikobetrachtung zu überwachen.

Meine Erfahrung zeigt, dass das Verletzen der Agilen Prinzipien, Effektivitätsverlust bringt, dem Projekt schadet oder das Vorhaben zerstört.

In den folgenden beispielhaften Szenarien zeige ich, wie das Besinnen auf das Agile Manifest und die Verantwortung in den Rollen des Product-Owners, des Scrum-Masters und des Development Teams helfen, schwierige Situationen zu meistern.

Das Grundmuster folgt immer dem gleichen Konzept:

1. Die Vision definiert den Zielkorridor und die Richtung
2. Features, welche einen messbaren Nutzen erzeugen, werden entwickelt und dem Produkt hinzugefügt
3. Das Produkt wird im Markt am Endanwender getestet und  das Feedback wird zur Überarbeitung von Vision und Bewertung der nächsten Features verwendet.

Product Owner Schach-Matt gesetzt

Jede Rolle im Prozess trägt mit Ihren Verantwortlichkeiten zum Erfolg bei. Die Faktoren Vertrauen, emotionale Bindung und Prozesstreue bilden eine Symbiose in deren Dialog der Mehrwert erzeugt werden kann.

Anhand der Vision und der Features sind strategische und taktische Produktziele gegeben. Der Product Owner erzeugt die notwendige Transparenz für das Team, welches die Stakeholder identifiziert.

Der Product Owner verantwortet auch die Produktroadmap und plant gemeinsam mit dem Team Sprints, Liefergegenstände und Qualitätskriterien.  Dabei berücksichtigt er die Rückmeldungen der Stakeholder und lässt diese, wo nötig in Produktvision und Featureliste einfließen.

Wird der Product Owner daran gehindert, seinen Aufgaben nachzukommen, sind die Ziele des Projektes gefährdet.

1. Ist keine aktuelle und validierte Vision vorhanden, dann steht dem Team keine Entwicklungsrichtung zur Verfügung. Entscheidungen über die Priorität oder den Wertbeitrag von Features sind nicht durchführbar.
2. Steht dem Projekt kein validiertes Backlog zur Verfügung, ist das Vorhaben nicht transparent und durchgehend messbar. Es sind keine Aussagen zu dem benötigten Investment und Return on Invest (RoI) möglich.
3. Ist eine emotionale Bindung nicht aufbaubar? Erfolgsfaktoren im Scrum sind Selbstorganisation und Verantwortung für das Ergebnis. Wenn das Team nicht vom Erfolg des Vorhabens überzeugt ist, wird das Projekt scheitern.

Symptom: „Die Stakeholder sind durch die Organisation definiert, in der Realität kaum verfügbar, treffen keine verbindlichen Aussagen zu Abnahme- und Qualitätskriterien“

Agile Produktentwicklung lebt von kurzen Feedbackschleifen. Eine Vision wird zu Beginn formuliert, mit Stakeholdern validiert und durch das Ausformulieren von Wertbeiträgen konkretisiert. Ob ein Feature auch einen „Nutzen“ bringt, kann nur durch Überprüfung im Sprint Review und ultimativ im Markt gemessen werden. Fehlen Abnahme- und Qualitätskriterien, kann eine Lieferung nicht bewertet werden.

Indikatoren und Messpunkte

Ich habe auf verschiedenen Wegen Stakeholder kennengelernt, welche aus Tradition, Unwissen oder Organisationsprotest, erfolgreiche Zusammenarbeit verweigern.

1. Einladungen zu Anforderungs-Workshops werden abgelehnt oder nicht wahrgenommen. Angenommene Einladungen werden halbherzig besucht. Die Mitarbeit reduziert sich auf ablehnende Anwesenheit. Die Folgen sind Features, welche über Annahmen definiert sind. Das ist die Basis einer erfolgreichen Fehlinvestition.
2. Es werden keine verbindlichen Aussagen getroffen. Getroffene Vereinbarungen werden mehrfach verschoben, ultimativ jedoch nicht eingehalten. Die Folgen sind falsch priorisierte und ungenau beschriebenen Features. Die Fehlinvestition wird erst spät erkannt, Vorteile des agilen Vorgehens zahlen sich nicht aus.
3. Die Definition von Messpunkten, Abnahmekriterien und Qualitätsmerkmalen wird verweigert. Testfälle sollen erfahrungsgemäß durch IT Personal antizipiert werden. Die Mitarbeit im Projekt wird emotional aus Angst vor Verpflichtung abgewehrt.  Die Folge ist die Schaffung einer Laborbedingung, in welcher die Qualität gegen Annahmen geprüft wird. Ein fehlerhaftes Verhalten des Produktes wird zu spät erkannt.

Welchen Ausweg gibt es?

Zunächst gilt es zu klären, wieso die Mitarbeit der Stakeholder nicht gegeben ist. Naheliegend ist die Unwissenheit über den agilen Prozess und die Verpflichtungen, die sich daraus für die Organisation und die Mitarbeiter ergeben. Hier lässt sich durch eine Schulung kurzfristig und mit Coaching nachhaltig gegensteuern. Wichtig ist die permanente Prüfung, ob die Maßnahmen erfolgreich gelebt werden.

Entlarven Sie eine Laborsituation als Simulation!  „Wir prüfen das mit Testern aus der Qualitätssicherung“ entspricht keinem Produktrelease und ist damit nicht als Markttest zu qualifizieren.

Ist die unbefriedigende Situation verursacht durch Protest oder aus der Ablehnung von Veränderung, muss der Sachverhalt nachweisbar gemacht werden. Die notwendige Eskalation in die verantwortliche Führungsebene muss:

• sachlich
• messbar
• frei von Emotion
• und transparent

erfolgen. Merke: Eine Eskalation ist nur erfolgreich, wenn man eine Alternative anbieten kann. Diese setzt sich zusammen aus:

• Welche Ressourcen werden mit
• welchen finanziellen Mitteln benötigt, um in
• welchem Zeitrahmen

ein Risiko zu minimieren, oder ein vergleichbares Ergebnis zu erreichen.

Ist der Austausch von Stakeholdern nicht durchführbar und die Herausforderung in der Organisation selbst gelagert, dann ist der Product-Owner verpflichtet, das Vorhaben zu stoppen. Der Verbrauch von Ressourcen ohne Annäherung an ein valides Ziel ist keine Option und beschädigt ultimativ den Product-Owner selbst.

Symptom: „Teammitglieder werden in der übergeordneten Organisation als Ressourcen gesehen und in Full-Time-Equivalents (FTE) berechnet und verteilt.“

Die Features für das Produkt sind im Product-Backlog erfasst und beschrieben. Das Team ist dafür verantwortlich, eine Sprintplanung durchzuführen und das Sprint-Backlog zu erzeugen. Dieser Aufgabe kann es nur gerecht werden, wenn die Vision für das Produkt verstanden wurde. Optimale Ergebnisse entstehen, wenn das Team eine emotionale Bindung zum Produkt und ihren Aufgaben aufgebaut haben.

Indikatoren und Messpunkte

In komplexen Projektstrukturen, in denen auf externe Unterstützung durch einen oder mehrere Dienstleister zurückgegriffen werden muss, konnte ich die folgenden Situationen beobachten.

1. Undurchsichtige Verfügbarkeiten von Projektmitgliedern mit einer Kapazität von einem Tag pro Woche, für den Product-Owner intransparent bereitgestellt. Dies führt zu unklaren Bearbeitungs- und Fertigstellungsständen der übernommenen Aufgaben. Nicht abgeschlossene Tasks werden erst im Sprintreview kommuniziert. SCRUM-Dailys kommunizieren keinen Fortschritt. Die Planung von Releases wird unmöglich. Agile Projekte ohne Transparenz sind nicht durchführbar.
2. Teilnahme an Meetings kurzfristig bestätigt oder abgesagt. Planungssicherheit in Frage gestellt. Aussage „Ich stehe dem Projekt nach Bedarf zur Verfügung“ – Hier ist jedoch selten der Bedarf des Projektes gemeint, sondern die Ressourcenverteilung der „payable hours“ im Interesse des Dienstleisters. Die Folge ist fehlende emotionale Bindung zum Vorhaben. Es findet keine Identifikation mit den Zielen des Produktes statt. Der Entwicklungsfortschritt ist nicht messbar, der Product-Owner ist nicht mehr befähigt die Frage „Was ist noch zu tun?“ zu beantworten.
3. Mitarbeiter sind durch die übergeordnete disziplinarische Organisation anhand ihrer fachlichen Expertise über mehrere Projekte verteilt. Schlüsselkompetenzen müssen mit anderen Projekten geteilt werden. Die Folge sind zeitintensive Kontextwechsel. Die Erfahrung zeigt, dass etwa 5% der zur Verfügung stehenden Arbeitsleistung für jedes zusätzliche Projekt verloren gehen.

Welchen Ausweg gibt es?

Ralph Jocham stellt in dem Buch „The professional Product-Owner“ fest, dass es einem Entwicklungsteam an Leidenschaft und Motivation fehlt, die beste Leistung zu bringen, wenn die Mitglieder als Ressource gesehen werden. Ohne Wertschätzung, Respekt, Anerkennung und Leidenschaft ist das agile Projekt mittelfristig nicht effektiv ausgestattet. Langfristig wird die Geschwindigkeit in der Bereitstellung von Mehrwert abnehmen. Das Produkt wird also später mit höheren Kosten fertig gestellt. Ultimativ wird das Vorhaben stoppen und scheitern.

Das primäre Ziel muss sein, Transparenz und Planungssicherheit herzustellen. Zunächst ist die Ursache für das Problem zu klären.

Sind die beteiligten Personen bereits erfahren in der Umsetzung von Agilen Projekten? Stellen Sie die Wichtigkeit von Transparenz, verlässlicher Planung und offener Kommunikation dar. Der Product-Owner trägt die Verantwortung, also muss er die Verbindlichkeit der Mitarbeiter einfordern. Bei einem externen Dienstleister sollte dies vertraglich vereinbart werden.

Fordern Sie exklusiven Zugriff auf das Team. Kontextwechsel kosten wertvolle Zeit, verhindern langfristige emotionale Bindung und führen zu höheren Kosten.

Sollte das nicht möglich sein, muss der Product-Owner diese Situation seinem Auftraggeber transparent machen. Ist das agile Projekt nicht mit den notwendigen Mitteln ausgestattet, kann es die erwarteten Ergebnisse (Zeit, Budget, Qualität) nicht erzeugen!

Auch hier gilt: Kann das Vorhaben nicht mit den notwendigen Ressourcen ausgestattet werden, dann ist der Product-Owner verpflichtet, das Vorhaben zu stoppen. Andernfalls wird ultimativ der Product-Owner selbst beschädigt.

 

Mangelnde Professionalität des Projektteams

Symptom: „Wenn fertig nicht fertig ist“

SCRUM ist angelegt, agile Vorgehensmodelle ideal zu unterstützen. Fail-Fast gilt als hilfreiches Mittel, um zügig ausloten zu können, ob eine Technologie nutzbar und nützlich ist. Dauerhafte Investition in nicht erfolgversprechende Lösungen wird auf die Länge eines Sprints minimiert. Ebenfalls wird durch zügiges Veröffentlichen ein zeitnahes Erproben der Geschäftsideen am Markt unterstützt. Damit dies funktioniert, muss mit jedem Sprint ein fertiges und potentiell auslieferbares Produkt bereitgestellt werden.

Indikatoren und Messpunkte

An folgenden Punkten habe ich beobachten können, wie Aufgaben nicht vollständig fertig gestellt werden.

1. Dokumentation unvollständig, entspricht nicht den Erwartungen. Das Feature kann in die Produktion genommen werden, jedoch ist die Verständlichkeit und Wartbarkeit eingeschränkt. Es wird technische Schuld aufgebaut, die Entwicklungsgeschwindigkeit in der Zukunft bremst.
2. Installations- & Upgrade-Skripte sind nicht auf dem aktuellen Stand, automatisierte Bereitstellung zeigt unzuverlässiges Verhalten. Continuous-Integration und Delivery Prozesse sind dadurch gestört. Mittelfristig sinkt messbar die Qualität – langfristig erhöhen sich die Produktkosten durch Fehleranalysen und manuelle Qualitätssicherung.   
3. Integration mit externen Komponenten wird nicht vollständig vorgenommen. Das Feature scheint fertig, Fehler in der Integration bleiben unentdeckt. Mittelfristig werden daher in folgenden Sprints mehr Ressourcen für Bug-Fixing und Fehleranalysen verbraucht. Langfristig stehen keine Kapazitäten für Wertschaffung zur Verfügung – das Projekt ist zu stoppen.

Welchen Ausweg gibt es?

Zunächst muss festgestellt werden, wieso Arbeitspakete nicht den Erwartungen entsprechend abgeschlossen werden. Quality-Gates wie die Definition of Ready (DoR) und Definition of Done (DoD) sind innerhalb des Agilen Modells vorgesehen, um die Ergebnisse prüf- und messbar zu gestalten.

Mein erster Ansatzpunkt ist die Prüfung der eigenen Ergebnisse. Wenn in der Diskussion eine ungenügende Definition of Ready (DoR) festgestellt wird, ist diese zu überarbeiten und die Beschreibung der Features entsprechend anzupassen. Offene Kommunikation, konstruktive Kritik und kontinuierliche Verbesserung sind Teil des Agilen Vorgehens.

Nächster Prüfpunkt ist die Definition of Done (DoD). Diese muss vom Entwicklungsteam definiert und akzeptiert sein. Sinnvoll ist diese in Form einer Checkliste zu erstellen, die im Vier-Augen-Prinzip abgehakt werden muss. Der Artikel https://dzone.com/articles/definitions-done-practice bietet eine gute Beschreibung, wie eine DoD gestaltet werden kann.

Wird die Liste nicht abgearbeitet, dann wird das Feature nicht als „Fertig“ akzeptiert. Auch mit der Konsequenz, dass das Entwicklungsteam in dem gegebenen Sprint keinen Mehrwert bereitgestellt hat. Die DoD ist Teil des agilen Vertrages.

Abhängigkeiten des Entwicklungsteams von externen Gewerken stellen eine besondere Herausforderung dar. Hier habe ich erfolgreich auf die Definition von Eingangskriterien zurückgegriffen. Diese müssen den anderen Teams transparent kommuniziert werden, damit gemeinsam verstanden ist, welche Anforderungen gegenseitig erfüllt werden müssen. Werden die benötigten Zulieferungen nicht vereinbarungsgemäß bereitgestellt, muss der Product-Owner diesen Umstand seinem Auftraggeber transparent machen!

Symptom: „Doppelrollenzielkonflikt“

Die verschiedenen Aufgaben und Interessen, welche innerhalb von Scrum verfolgt werden, sind auf verschiedene Rollen verteilt:

Der Product-Owner ist der Eigner des Produktes. Seine Aufgabe ist es, mit den gegebenen Mitteln den höchstmöglichen Wert zu erschaffen. Sein Ziel ist die erfolgreiche Prüfung des Produktes und seiner Eigenschaften am Markt. Dazu spornt er kontinuierlich das Team zur Höchstleistung an.

Der Scrum-Master ist der Wächter über den Scrum-Prozess. Seine Aufgabe ist es, dem Entwicklungsteam die Mittel zur Verfügung zu stellen, die es für seine Arbeit benötigt. Gleichzeitig berät er das Entwicklungsteam in Fragen zur Selbstorganisation, Administration und Leben im agilen Umfeld. Sein Ziel ist die erfolgreiche Implementierung des Agilen Prozesses und die kontinuierliche Überwachung und Schutz der damit verbundenen Arbeitsschritte.

Das Entwicklungsteam identifiziert im Backlog die nächsten Features, die dem Produkt sinnvoll hinzugefügt werden können. Es plant daraus Sprints und stellt die Umsetzung der Anforderungen in Produktfunktionalität sicher.

Diese Rollen sind im Prozess gleichberechtigt. Das Zusammenspiel der Rollen und Interessen führt zu Check & Balances. Es wird sich also gegenseitig gefordert, gefördert und überprüft.

Indikatoren und Messpunkte

Aus eigener Erfahrung dürfen folgende Situationen nicht entstehen:

1. Der Product-Owner nimmt gleichzeitig die Rolle des SCRUM Masters an. Beide Rollen haben konträre Ziele, die Konzentration der Aufgaben auf eine Person stellt einen Interessenskonflikt dar. Das Prinzip von Checks & Balances ist gebrochen. Es entsteht meist ein höherer Lieferdruck auf das Team, mit schleichender, aber messbarer Abnahme von Qualität. Die Folge: höhere Kosten.
2. Da der Product-Owner Erfahrung als Architekt hat, möchte er Technologieentscheidungen treffen. Hier wird zusätzlich die Rolle eines Entwicklungsteammitarbeiters angenommen. Das Resultat ist ebenfalls ein Interessenskonflikt. Die Umsetzungsentscheidungen des Teams werden beeinflusst und sind nicht mehr unabhängig. Die Folge ist, dass das Team die Verantwortung für die Umsetzung nicht mehr tragen wird. Mit jedem Sprint entsteht mehr technische Schuld. Ultimativ erzeugt das Projekt keine Wertbeitrag und muss gestoppt werden.

Welchen Ausweg gibt es?

Doppelbesetzungen und damit einhergehende Zielkonflikte kommen häufig vor. Sie können direkt adressiert sein, wie die Zuweisung der Aufgabe Scrum-Master zusätzlich zum Product-Owner. Ziel muss es sein, den Zielkonflikt nicht erst entstehen lassen. Schaffen Sie Transparenz über den möglichen Zielkonflikt. Aus meiner Erfahrung hilft die Erkenntnis über die Konsequenz, diese Entscheidungen bereits zu verhindern.

Herausfordernder sind Zielkonflikte, die sich zunächst unbemerkt einschleichen. Es beginnt beispielsweise mit der Frage zu den Optionen, wie ein technisches Problem gelöst werden kann. Man beobachtet die Abgabe von Verantwortung, die primäre Hoheit des Entwicklungsteams ist.

1. Analyse, wieso die Verantwortung abgegeben wird.
   1. Fehlt Know-How im genutzten Technologie-Umfeld? à Schulung oder Experten zur Unterstützung hinzuziehen
   1. Unklares Rollenverständnis oder unerfahrenes Team? à Schulung & Stärkung des Scrum-Masters
2. Hat man den Zielkonflikt bereits erreicht, muss dieser umgehend aufgelöst werden.
   1. Sprint stoppen
   1. Retrospektive mit der klaren Kommunikation der Situation
   1. Eruierung der möglichen Optionen (Neuverteilung von Rollen, enge Überwachung)
   1. Festschreiben der Entscheidung & Prüfung der Umsetzung

Symptom: „Prozess wird vom Team nicht definiert und nicht gelebt“

Agile Prozesse tragen Engagement, Verpflichtung und Selbstverantwortung in ihrer DNA. Das zeigt sich besonders an SCRUM. In seinem Manifest wird ein Framework beschrieben. Agile Teams müssen das Framework als Baukasten verwenden und sich ihren eigenen Prozess definieren.

Der entstehende Prozess geht in die Verantwortung und das Eigentum des Teams über, erzeugt emotionale Bindung und Vertrauen in die Ergebnisse der einzelnen Teammitglieder.

Indikatoren und Messpunkte

1. Anweisung durch die Organisation, dass ein Standardvorgehen SCRUM zu nutzen ist.
2. Mitarbeiter verwehren Transparenz über Fortschritt und Blocker in ihren Aufgaben, Messbarkeit wird torpediert.

Welchen Ausweg gibt es?

In vielen Organisationen wurde eine Entscheidung zur Transition zu Agilen Vorgehensmodellen getroffen. Im Regelfall wird ein agiler Coach beauftragt, den Veränderungsprozess professionell zu begleiten. Um die Erwartung der Organisation zu erfüllen, wird ein standardisierter SCRUM-Prozess im Rahmen der Beratung installiert.

ABER: Es gibt keinen Standard-SCRUM-Prozess

Ist ein agiler Prozess definiert, wird aber nicht gelebt, hat sich folgendes Vorgehen bewährt:

1. Analyse, wieso der Prozess nicht gelebt wird. Ist er vom Team entworfen oder zentral angeordnet? Sind die Vorgehensmodelle transparent in der Organisation verankert? Ist ein erfahrener SCRUM Master dem Team zugeordnet?
2. Agile Workshop in der Organisation planen und durchführen.
3. SCRUM Prozess durch das Team entwerfen lassen, Definition of Ready und Definition of Done vereinbaren.
4. Veränderung messbar machen und kontinuierlich überprüfen.

Lässt sich das Problem durch Transparenz und Wissenstransfer nicht verbessern, liegt die Ursache in Personen, die Veränderung ablehnen. Es ist zu prüfen, ob gezielt ein Austausch vorgenommen werden kann.

Liegt die Herausforderung in der umgebenden Organisation, dann ist diese eventuell nicht geeignet einen agilen Prozess zu leben. Finale Eskalation:

1. Projektstopp
2. Transparenz schaffen über Investition, erwarteter Wertschöpfung und geschaffenen Werten.

---