23. Februar 2019

Scrum in der Vorentwicklung: Transparenz führt zu Veränderungen

SMART DEVELOPMENT NEWS 02/2019

Sie kennen das Problem: Zu Beginn der Vorentwicklung sind die genauen Markt- und Kundenanforderungen häufig noch unklar. Genauere Aussagen bezüglich einzelner Projektziele wie Zielkosten oder der möglichen Leistung sind schwierig, sodass viele Kollegen der Vorentwicklung nur wenig Beachtung schenken. „Die sind ja noch weit weg vom Markt“, hallt es durch die Flure, während die Mitarbeiter sich anderen Projektbaustellen widmen.

Diese Sichtweise ist kontraproduktiv. Wenn Sie nicht bereits in den frühen Phasen der Vorentwicklung wissen, in welche Richtung es gehen soll, entwickeln Sie Ihr Produkt im schlimmsten Fall „am Markt vorbei“.

In einem volatilen Marktumfeld helfen uns klassische Prozesse allerdings nicht mehr weiter. Klassisches Projektmanagement ist meistens zu starr und stößt mit Blick auf die wechselhaften Anforderungen von Markt und Kunden an Grenzen, die wir ohne neuartige Ansätze nicht überwinden können.

Agile Frameworks wie Scrum unterstützen uns hingegen, mit Anforderungsänderungen strukturiert umzugehen. Dadurch können wir sie sogar zu unserem Marktvorteil nutzen. Kurze Iterationen sorgen hierbei für kontinuierliches Lernen am Produkt und im Prozess. Regelmäßige Reviews mit den richtigen Stakeholdern führen gerade in der Vorentwicklung zur Klärung unbekannter Markt- und Kundenanforderungen und schaffen „ganz nebenbei“ von Anfang an Verbindlichkeit im Projekt – sowohl im Team als auch im Management.

Wie funktioniert agile Vorentwicklung?

Wie in klassischen Projekten auch benötigen Sie zu Beginn ein Budget, verfügbare Ressourcen und einen zeitlichen Rahmen. Parallel dazu empfiehlt es sich, den Product Owner für das Projekt festzulegen. Er ist für den Projekterfolg verantwortlich und erstellt in Abstimmung mit den Stakeholdern und in Ableitung der Strategie eine Product-Vision. Diese kann im weiteren Projektverlauf weiter detailliert werden, sollte aber bereits die wesentliche Richtung für die Entwicklung vorgeben. Darüber hinaus erstellt der Product Owner auf Basis der Product-Vision einen initialen Backlog. Mit diesen Eingangsgrößen sind Sie in der Lage, das Development-Team so zusammenzustellen, dass es die Kompetenz besitzt, den größten und wichtigsten Teil der Ergebnisse zu erzeugen.

Haben Sie alle Rollen besetzt und den Projektrahmen definiert, findet zum Start des Vorentwicklungs-Projektes ein Kick-off-Meeting statt. Hierbei stellt der Product Owner die Product-Vision sowie den initialen Product Backlog vor und beantwortet Fragen aus dem Team.

An diesem Punkt zeigt sich, inwiefern die Zusammensetzung des Teams passt oder ob andere Rahmenbedingungen für einen erfolgreichen Projektstart fehlen. Oft sind beispielsweise die eingeplanten Team-Mitglieder noch nicht frei für ihre neue Aufgabe. Das ist selbstredend keine gute Voraussetzung für den Start Ihres Projektes – daher müssen Sie konkret nachhaken und die erforderlichen Maßnahmen treffen, um Ihren Team-Mitgliedern ausreichend Kapazitäten zu geben.

Nach unserer Erfahrung hat es sich darüber hinaus bewährt, im Kick-off auch das Working Agreement und die „Definition of Done“ gemeinsam im Team zu erstellen. Zur Erinnerung: Das Working Agreement beinhaltet nicht nur formale Punkte wie die zeitliche Festlegung der Scrum Events, sondern auch konkrete Verpflichtungen, wie das Team in Zukunft zusammenarbeiten möchte.

Hier könnten Vereinbarungen stehen wie:

• „Wir erscheinen zu unseren Events immer pünktlich“
• sowie „Smartphones und Telefone sind während der Daily Scrum Meetings auszuschalten“
• oder „Arbeitsfortschritte werden immer offen und ehrlich kommuniziert“.

Mithilfe solcher Vereinbarungen erzeugen Sie in Ihrem Team Verbindlichkeit in Bezug auf die angestrebte Arbeitsweise.

Die ersten Sprints

Haben Sie das Kick-off-Meeting erfolgreich abgeschlossen und alle Rahmenbedingungen definiert, steht dem Start des Projektes nichts mehr im Weg. Die erste Sprintplanung kann beginnen.

Im Verlauf der Sprints nähert sich das Team iterativ dem Markt und dem Kundenbedarf. Hierbei lernen die Mitglieder nicht nur in den Sprint Reviews und dem täglichen Arbeiten am Produkt, sondern auch von der Zusammenarbeit. Maßgeblich zur Verbesserung dieser Zusammenarbeit trägt die Sprint Retrospektive bei.

Von vielen Teams unterschätzt bringt dieser regelmäßig stattfindende Event grundlegende prozessuale und rahmenbedingte Hindernisse und Ineffizienzen zum Vorschein. Das ist für die praktische Projektarbeit von großem Wert, denn häufig sind die Hindernisse und Ineffizienzen in lange bestehenden Strukturen entstanden – entsprechend schwierig ist es, sie zu identifizieren und zu beseitigen.

In diesem Zusammenhang fällt in der Vorentwicklung oft der Begriff „Fürstentümer“. Er steht sinnbildlich für die Fülle an Macht und Ressourcen in einem bestimmten Unternehmensbereich, welcher von einem „Fürsten“ beherrscht wird. Hier stehen Scrum-Teams immer wieder vor der Herausforderung, ihre Anliegen (z. B. bezüglich Ressourcen oder der Eigenverantwortung der Team-Mitglieder) durchzusetzen. Dabei brauchen sie oftmals Unterstützung von ihrem Scrum Master. An dieser Stelle zeigt sich also deutlich, ob Sie diese Position optimal besetzt haben – oder ob Ihre Entscheidung womöglich die Falsche war.

Worauf es in der Praxis ankommt

Sie sehen: Eine Anwendung von Scrum in der Vorentwicklung bietet viele Vorteile und ist an sich nicht schwer zu verstehen. Folglich steht Ihrem Projekterfolg mithilfe agiler Methoden per se nicht viel im Wege – solange Sie einige wichtige Regeln befolgen.

Dazu zählen:

• Wählen Sie Ihren Product Owner sorgfältig aus: Er muss Markt- und Kundenanforderungen und deren Veränderungen während der Projektlaufzeit für das Development-Team in seinem Product Backlog sinnvoll filtern, strukturieren und priorisieren. Die konsequente Pflege und Priorisierung des Product Backlogs ist ausschlaggebend für den Erfolg des Projektes. Besonders der Kontakt zum Kunden (ob intern oder extern) darf nicht verloren gehen.
• Binden Sie das Management von Beginn an ein: Zum Beispiel in der Rolle als Stakeholder über das Backlog Refinement und die Teilnahme an Sprint Reviews. Halten Sie den Kontakt zu den Stakeholdern im fortschreitenden Projekt weiter aufrecht, da hierbei eine gemeinsame Arbeitskultur und Projekthistorie entstehen. Stakeholder, die mitten im Projekt auftauchen, Fragen stellen, die schon beantwortet waren, und ein paar gute Ideen hinterlassen, um dann wieder zu verschwinden, sind genauso unangenehm wie Linienvorgesetzte, die Helikopter-Management betreiben.
• Sorgen Sie für eine geeignete Infrastruktur, Ressourcen und Rahmenbedingungen: Stellen Sie Ihrem Scrum Team beispielsweise einen separaten Raum zur Verfügung. Nur unter guten Rahmenbedingungen wird das Team auch eine herausragende Performance liefern können!
• Bleiben Sie dem originären Scrum Framework solange es geht treu: Jedes Element in Scrum hat seinen Sinn und einen daraus resultierenden Nutzen. Verändern Sie bereits zu Beginn das Framework, geht mindestens ein Teil oder sogar der gesamte Nutzen verloren. Hier hilft Ihnen ein gut ausgebildeter und erfahrener Scrum Master bei der Umsetzung.

Eine Sache sollten Sie sich von Anfang an klar machen: Scrum ist weder Ursache noch Lösung Ihrer Probleme. Es ist ein methodischer Rahmen, der Transparenz schafft, welche zu Veränderungen führen kann. Es liegt nun an Ihrem Management sowie an den einzelnen Betroffenen, auf Basis dieser Transparenz Veränderungen zu ermöglichen. Veränderungen, mit denen Sie in Ihrem Vorentwicklungsprojekt deutlich vorankommen und sich gegenüber Ihrer Konkurrenz mit neuen Produkten abheben.

Gerade in Unternehmen, die noch keine Erfahrung mit Scrum und anderen agilen Methoden gesammelt haben, sind die ersten Projekte mitunter eine Herausforderung. Unsere Berater haben bereits viele agile Projekte in der Hardwareentwicklung erfolgreich begleitet. Sie wissen, worauf es bei einer Implementierung von Scrum ankommt. Profitieren Sie von unserer breiten Erfahrung bei der Einführung von Scrum in hardwareorientierten Entwicklungsfeldern!