Agil entwickeln mit der SCRUM Methode

Agil entwickeln mit der SCRUM Methode

Agil sein bedeutet beweglich und wendig zu sein.

Diese Eigenschaften machen die SCRUM Methode zu einer der besten: Anstatt starre Regeln zu verwenden, die letztlich nicht eingehalten werden, lebt die SCRUM Methode von Flexibilität.

Ursprünglich hat man die Methode für Software-Entwickler erfunden. Allerdings ist sie aber auch bestens bei Geräten und Komponenten sehr gut anwendbar – damit ihre Produktentwicklung in Bewegung bleibt.

Häufig nennt man Agilität als eine notwendige Eigenschaft für die Zukunftsfähigkeit eines Unternehmens.

Doch was das genau bedeutet und wie sich dies auf die Abläufe und die Arbeits- und Verhaltensweisen der Mitarbeiter auswirkt, ist wiederum oftmals unklar.

Unter Agilität versteht man allgemein das flexible Agieren einer Organisation um notwendige Veränderungen einzuführen.

Übertragen auf die Produktentwicklung bedeutet Agilität erfahrungsgemäß, möglichst bis kurz vor Serienstart Kundenanforderungen oder Wettbewerbsanforderungen in das Produkt einfließen zu lassen.

Festlegungen zu Design, Funktionen und Merkmalen legt man nicht, wie bisher gewohnt, im Voraus fest, sondern ändert diese gerne kurzfristig.

Dies, dann wenn möglich, bis kurz vor Produktionsbeginn.

Agile Entwicklung

Einer der Ursprünge für die agile Produktentwicklung liegt in der Software-Branche.

Dazu gab es zwei Gründe  die Softwarefirmen vorrangig dazu bewogen, sich auf Agilität einzulassen:

  1. Zum einen haben die Forderungen von Kunden während der Projektlaufzeit immer mehr zugenommen, und damit natürlich auch die Anzahl der Änderungen
  2. Zum anderen sind die Kosten für die Projekte selbst explodiert.

Wie funktioniert SCRUM?

Die Scrum-Methode wirkt diesen Faktoren maßgeblich entgegen. Denn, bei ihr wird in getakteten Zeitfenstern entwickelt, getestet und es werden voll funktionsfähige Module geschaffen.

Die wesentlichen Elemente bezeichnet man dabei als:

  • Rollen
  • Aktivitäten
  • Ergebnisdokumente
Hierbei zählen zu den Rollen:
  • der Product-Owner
  • der Scrum-Master
  • das Mitglied im Projektteam
Zu den Aktivitäten gehören:
  • Das Sprint-Planning
  • Das Daily-Scrum-Meeting
  • Die Sprint-Retrospektive
  • das Sprint-Review
  • sowie das Erstellen und Pflegen des Product-Backlogs

Letztlich gehören zu den Ergebnisdokumenten das Scrum-Board, das Sprint-Backlog und das Product-Backlog.

Weiter wurde dem Dreieck des Projektmanagements, Zeit, Qualität und Kosten, eine vierte Dimension hinzugefügt: der Scope des Produkts.

Jedes Teammitglied hat seine Aufgabe

Die detaillierte Betrachtung der einzelnen Elemente zeigt die Herausforderungen auf, die von den Unternehmen bei der Anwendung zu lösen sind.

Der Product Owner

Der Product-Owner ist die für das Produkt verantwortliche Person. Dabei sammelt und interpretiert er die Kundenanforderungen und stimmt diese über die gesamte Entwicklungsdauer mit den jeweiligen Kunden ab.

Des Weiteren erstellt und pflegt er das Product-Backlog und erläutert dem Entwicklungsteam die Hintergründe der Kundenforderungen.

Der Scrum-Master

Der sogenannte Scrum-Master ist für das Einhalten der Methode verantwortlich.

Dabei stellt er sicher, dass man die Daily-Scrum-Meetings einhält, die Merkmale priorisiert und die Sprint-Backlogs entstehen. Hierbei moderiert auch der Scrum-Master die Scrum-Meetings, das jeweilige Sprint-Review und die Sprint-Retrospektive.

Das Team ist aus allen notwendigen und wichtigen Funktionen zusammengesetzt, um ein funktionsfähiges Modul oder Objekt fertigzustellen.

Aus diesem Grund entscheidet das Team auf Basis der Wertigkeit der einzelnen Funktionen und Merkmale, was in einer definierten Zeitdauer von beispielsweise vier Wochen, also dem sogenannten  Sprint  zu entwickeln, zu testen, freizugeben und einzuführen ist.

Das Team lässt zusammen das Modul oder Objekt entstehen und pflegt das Sprint-Backlog. Zudem trifft sich das Team auch zum täglichen Sprint-Meeting.

Das Sprint-Meeting

Im Sprint-Meeting zeigt man kurz den Fortschritt und die Schwierigkeiten auf und, falls erforderlich, leitet man entsprechende Maßnahmen ein.

Dabei dokumentiert man den Fortschritt auf dem Scrum-Board und informiert gegebenenfalls den Product-Owner.

Das Team ist zu hundert Prozent für dieses Projekt eingesetzt. Deshalb hat es auch keine weiteren Projekte in der definierten Zeit.

Die entsprechende Zeit ergibt sich aus der definierten Dauer und der Anzahl der Sprints.

Product-Backlog

Im Product-Backlog werden alle Kundenforderungen in Funktionen und Merkmale übersetzt und dann weitergehend um die Bedeutung für den Kunden ergänzt.

Das dient einerseits dazu, dem Team die Wichtigkeit erläutern zu können und andererseits gegenüber den Kunden eine Entscheidungshilfe zu haben, den Scope zu verringern.

Dies allerdings nur sofern die Zeit oder die Kosten gefährdet sind.

Sprint Backlog

Im Sprint-Backlog sind die notwendigen Elemente und Anordnungen definiert, um die für diesen Sprint ausgewählten Kundenforderungen, Funktionen und Merkmale zu realisieren.

Scrum Board

Über das Scrum-Board verfolgt man den Status der Produktentwicklung.

Von Software zum physischen Gut

Was einfach bei der Entwicklung von Software möglich ist, ist nicht eins zu eins auf die Entwicklung von physischen Gütern übertragbar.

Denn, ein physisches Produkt benötigt eine Mindestzahl von Modulen, um überhaupt funktionsfähig zu sein. Ein Faktor, der kaum übertragbar ist, ist die Veränderung des Scope, also des Inhalts- und Umfangsmanagements.

Der Scope physischer Güter setzt sich zu guter Letzt aus den Bauteilen und Baugruppen zusammen, die für das Erfüllen der Kundenwünsche benötigt werden.

Abstriche kann man hier zum Beispiel machen, wenn eine Modularisierung der Produkte in Funktionsmodule erfolgt.

Darüber hinaus hilft eine geschickte Produkt-Roadmap, in der die Funktionsumfänge der Produkte und damit die Anzahl der Bauteile beziehungsweise Module gezielt konfiguriert, ausgebaut oder reduziert werden.

Weiter ist es bei physikalischen Gütern kaum möglich, sofern es sich nicht um den Sondermaschinenbau handelt, immer im direkten Kontakt mit dem spezifischen Kunden zu stehen und mit diesem permanent die Notwendigkeit und Wertigkeit seiner Forderung abzugleichen.

Auch ist notwendig, dass bereits entwickelte, getestete Module vorhanden sind, die lediglich einer Anpassung unterliegen.

Die Zielsetzung, innerhalb eines Sprints ein getestetes Modul zu entwickeln, kann ansonsten nicht erreicht werden.

Erfahrungsgemäß benötigt das Testen von physikalischen Modulen ein erheblich größeres Zeitfenster als das von Software.

Die 7 Elemente zur erfolgreichen Einführung der agilen Produktentwicklung

Die Elemente aus der agilen Produktentwicklung und Scrum kann man sehr gut nutzen. Diese muss man allerdings anpassen.

Es gibt sieben Elemente, die bei der erfolgreichen Einführung agiler Produktentwicklung helfen:

  1. Eine Produktstruktur, die modular aufgebaut ist und die es ermöglicht, Module weitgehend unabhängig voneinander zu entwickeln beziehungsweise weiterzuentwickeln.
  2. Eine Stelle innerhalb des Unternehmens, die enge Kontakte zu bestehenden und potenziellen Kunden aufbaut. Ihre Aufgabe ist es, deren Wünsche und Forderungen zu erkennen, diese in Funktionen und Merkmale zu übersetzen sowie deren Bedeutung zu bestimmen.
  3. Ein gut gepflegtes Product-Backlog oder Lastenheft, welches sich im Laufe der Entwicklung konkretisiert und permanent überprüft und angepasst wird.
  4. Angepasste Produktentstehungsprozesse, die beispielsweise zwischen funktionalen und technischen Prototypen unterscheiden und dadurch auf genaue technische Vorgaben in einer Frühphase noch nicht angewiesen sind.
  5. Ein konsequentes Monitoring des Risikos über den gesamten Entwicklungsprozess und die Sprints.
  6. Die Entwicklung und Auslegung nicht auf Nennmaße, -größen und Toleranzen, sondern auf Lösungsräume.
  7. Eine Organisationsstruktur, in der funktionsübergreifende Teams zusammenarbeiten und eigenständig über die Realisierung entscheiden dürfen.

Fazit

An sich ist es möglich, den Anforderungen einer agilen Entwicklung gerecht zu werden.

Allerdings benötigt man dazu ein gut ausgeprägtes Fachwissen im Bereich der agilen Entwicklung.

Sollten Sie jetzt festgestellt haben, dass einiges in diesem Artikel neu für sie ist und wollen ihr Fachwissen erweitern, dann zögern sie nicht uns zu kontaktieren.


Bitte beachten Sie, dass Kommentare vor der Veröffentlichung freigegeben werden müssen

Diese Website ist durch reCAPTCHA geschützt und es gelten die allgemeinen Geschäftsbedingungen und Datenschutzbestimmungen von Google.