.st0{fill:#FFFFFF;}

Scrum im Maschinenbau und Anlagenbau 

Copyright Dr. Wüpping Consulting GmbH


Taugt die agile Entwicklungsmethode Scrum im Maschinen- und Anlagenbau?

Nahezu jeder, der sich mit Entwicklung befasst, ist schon mit den populären Themen agile Entwicklung und hier insbesondere Scrum konfrontiert worden. Scrum als Methode für das Management komplexer Projekte im Maschinen- und Anlagenbau findet zudem mehr und mehr Akzeptanz.

Doch was taugt die Methode wirklich, wie funktioniert sie und für wen und wann ist sie geeignet? Hiermit wollen wir uns in dem folgenden Beitrag einmal umfassend auseinandersetzen.

Scrum für die schnelle und aufwandsarme Produktentwicklung.

Schnelle und aufwandsarme Entwicklungsprozesse sind entscheidend im Wettbewerb. Die Komplexität der Kunden- und Marktanforderungen sowie die immer kürzer werdenden Entwicklungszeiten und das zunehmend erforderliche Zusammenspiel von Vertrieb, Produktmanagement, Produktion und Einkauf auf der einen Seite und Kunden sowie Lieferanten auf der anderen Seite, erfordern ein Überdenken der bisherigen Methoden. Zudem fällt vielen Unternehmen das Zusammenwachsen und die schlanke Verzahnung von Mechanik, Elektro und Software schwer, sei es in einem sequentiellen oder in einem teilweise parallelen Prozess. Darüber hinaus verlagert sich die Innovation und die Entwicklungslast im Maschinenbau mehr und mehr in Richtung Software, dem ursprünglichen und heute überwiegenden Anwendungsfeld von Scrum.

Scrum im Einsatz

Scrum: Agile Methode im Maschinenbau?

Viele Gründe und Veränderungen, die ein Überdenken der Entwicklungsprozesse erforderlich machen.

Fragen Sie Scrum-Verfechter, erhalten Sie häufig folgende Aussage: Gerade die zunehmende Dynamik und schnellen Änderungen in komplexen Projekten lassen sich mit Scrum flexibler auffangen und stellen die konventionellen Methoden oftmals in den Schatten.

Doch was ist Scrum? Zunächst einmal handelt es sich bei Scrum um ein Methoden- oder Frame-Set für die Selbstorganisation von Entwicklungsteams.

Die Ursprünge von Scrum liegen in der Softwareentwicklung.

In der Softwareentwicklung liegen die Anfänge von agiler Methodik. Heute nutzen mehr als 50% der SW-Unternehmen agile Methoden.

Ken Schwaber, Jeff Sutherland und andere formulierten Anfang der 90er Jahre die Grundlagen wie folgt:

  • Menschen und Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Produkte sind wichtiger als überbordende Dokumentation.
  • Zusammenarbeit mit Lead-Kunden ist wichtiger als die anfänglich formulierten Leistungsbeschreibungen.
  • Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.

Wie funktioniert Scrum und wie ist die Methode aufgebaut?

Im weitesten Sinne bietet Scrum ein Methodenset, bestehend aus wenigen Regeln. Diese Regeln definieren fünf Aktivitäten, drei Leistungswerke (sog. Artefakte) und drei Rollen, die den Kern von Scrum ausmachen.

Hintergrund und Ansatz ist die Annahme, dass viele Projekte zu komplex sind, um sie von vorne bis hinten durchzuplanen. Daher handelt es sich um einen erfahrungsbasierten, inkrementellen und iterativen Prozess. Sowohl Lösungsansätze als auch die Anforderungen sind zu Beginn nur teilweise klar. Anhand von Zwischenergebnissen und entlang des Entwicklungsverlaufes werden Anforderungen und Lösungstechniken iterativ entwickelt.

Scrum

Scrum: Methode und Framework

Der langfristige Plan (Product Backlog) wird kontinuierlich verfeinert. Dabei wird der Planungsprozess immer nur für den nächsten Zyklus (Sprint) erstellt und der Detailplan (Sprint Backlog) ist immer auf den wichtigsten nächsten Schritt fokussiert. Der Aufwand der Planung und Steuerung wird dabei auf ein Minimum reduziert.

Selbststeuernde Teams und häufiges Feedback.

Durch häufiges und frühes Feedback in den selbststeuernden Teams, wird die Interaktion mit den Kunden in der Produktentwicklung verbessert. Produkte werden für und nun auch mit dem Kunden entwickelt, ähnlich zu den Open-Innovation-Ansätzen. Durch die Eigenverantwortung des Entwicklungsteams und häufige Überprüfung der Ziele, werden nur die relevanten Funktionen des Produktes entwickelt.

Die Verbesserung basiert dabei auf folgenden drei Elementen:

  • Transparenz: Fortschritt und Hemmnisse werden regelmäßig für alle sichtbar dargestellt?
  • Überprüfung: In kurzen und regelmäßigen Abständen werden Ergebnisse (Anforderungen, Produktfunktionalitäten, Strukturergebnisse Produktarchitektur, einzelne Module) geliefert und sowohl das Produkt, die Plattform als auch das Vorgehen überprüft.
  • Anpassung: Anforderungen an das Produkt und an das Vorgehen werden erneut angepasst und festgelegt.

Detaillierte Lasten- und Pflichtenhefte sind Fehlanzeige. Wichtig ist jedoch ein Wechsel von der Technik- und Produktsicht auf die Funktions- und Anwendersicht – Also die Kundenbrille wird aufgesetzt.

Die maximale Transparenz für alle Beteiligten ist ein Grundsatz, der durch häufigen Informationsaustausch, einfache Visualisierungen und Einstellung aller Beteiligten erreicht wird. Klar definierte Verantwortung, hohe Verbindlichkeit und Selbstorganisation begründen den Erfolg der agilen Entwicklung.

Die Eigenschaften werden im sogenannten „Product Backlog“ in Form von Merkmalen und Ausprägungen aus Anwendersicht beschrieben.

Welche Rollen gibt es in einem Scrum Team:

Product Owner:

  • Der Product Owner verantwortet das Erreichen der Produktziele im Sinne der Produkteigenschaften, der Wettbewerbsfähigkeit und im Hinblick auf den wirtschaftlichen Erfolg. Er nutzt den sogenannte Product Backlog.

Entwicklungsteam:

  • Das Entwicklungsteam organisiert sich selbst und ist für die Erfüllung der Funktionalitäten verantwortlich. Das Entwicklungsteam sollte aus 4 bis 8 Mitgliedern bestehen und die jeweiligen Sprints in Eigenregie erfüllen können. Nach Erreichen der jeweiligen Sprints, können die Ergebnisse einem größeren oder erweiterten Kreis vorgestellt werden. Von den Teammitgliedern wird eine sehr interdisziplinäre Zusammenarbeit verlangt und nicht jeder Entwickler fühlt sich hier gut aufgehoben.

Scrum Master:

  • Der Scrum Master steuert, überprüft und passt an. Er ist der klassische Coach und Kümmerer (im positiven Sinne) und entscheidet maßgeblich über den Erfolg eines Scrum Projektes. Der Scrum Master sollte ein guter Kommunikator und Moderator sein, Treffen organisieren, die Zusammenarbeit fördern und Konflikte beilegen, und zwar im Team und nach Möglichkeit nicht durch Eskalationsstufen außerhalb des Teams. Dafür braucht es eine hohe Akzeptanz. Er führt das Projekt im Sinne eines Coachings, ist aber gegenüber dem Team nicht weisungsbefugt.

Außerhalb des Projektes gibt es noch die Stakeholder als Kunden (interne und externe), Anwender und das Management.

Welche Aktivitäten werden unterschieden:

1. Sprint Planning: 2 Fragen werden für jeden Sprint (z.B. 2 bis 4 Wochen) mit einem Aufwand von 1 bis 2 Stunden pro Woche beantwortet.

Was wird im kommenden Sprint entwickelt?

Verfeinerung der Produkteigenschaften im vorgelagerten Sprint. Extrem wichtig ist hierbei ein gemeinsames Verständnis, ansonsten funktioniert es nicht. Der Product Owner muss sich mit dem Entwicklungsteam auf die Bewertungskriterien verständigen, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist und das Ziel erreicht wurde oder nicht.

Anschließend entscheidet das Team bzw. schätzt das Team ab, wieviel Product-Backlogs im nächsten Sprint freigegeben werden können.

Wie wird die Arbeit erledigt?

Hier entscheidet das Team über das wie, also mit welchen Aufgaben und welcher Herangehensweise das Ziel erreicht wird.

2. Daily Scrum: Kurze tägliche Arbeitssitzung zu Beginn (max. etwa 15 Minuten).

Es werden fachlich und inhaltlich keine Probleme gelöst. Die Sitzung dient nur zum Informationsaustausch und kann in 10 bis 15 Minuten abgehandelt werden.

Fragen, die sich nicht beantworten lassen, werden dem Scrum-Master übergeben und separat behandelt.

3. Sprint Review: Überprüfung der Sprintergebnisse im Team.

Zum Ende eines jeden Sprints überprüft das Team die Ergebnisse und passt den Backlog an. Die Stakeholder besprechen die Ergebnisse. Der Product Owner bewertet die Ergebnisse und entscheidet über Annahme und Entlastung des Teams oder nicht. Defizite werden im Product Backlog aufgenommen und neu priorisiert.

4. Sprint Retrospektive: Überprüfung der Arbeitsweise im Team.

Zum Ende eines jeden Sprints überprüft das Team ebenfalls die Arbeitsweise hinsichtlich Anpassungs- und Optimierungsbedarf. Unangenehme Wahrheiten müssen hier offen geäußert werden dürfen.

5. Product Backlog Refinement:

Hier wird gemeinsam der Product Backlog verfeinert und weiterentwickelt. Hierbei können Einträge gelöscht, ergänzt, geordnet, priorisiert und weiter detailliert oder zusammengefasst werden.

Welche Hilfsmittel werden eingesetzt:

Hilfsmittel und Steuerungselement sind der

  • Product Backlog: Liste der Anforderungen.
  • Sprint Backlog: Jeweils aktueller Sprintplan mit den zu erledigenden Aufgaben.
  • Product Increment: Summe der Product Backlog Einträge, die bis dato fertiggestellt wurden.
  • Burn down Chart: Interessant ist sicherlich noch das Burn-Down-Chart, welches die bereits geleistete und noch verbleibende Arbeit sehr gut visualisiert.

Änderungen und Korrekturen sind bei Scrum erwünscht

Ziel ist es, in einem Prozess der ständigen Verbesserung individuelle Kundenwünsche in kurzen Rückkopplungs-Schleifen zu erfüllen. Ständige Änderungen und Korrekturen sind mit zunehmendem Entwicklungs- und Erkenntnisstand explizit erwünscht, um so früh wie möglich Fehlentwicklungen zu vermeiden und Anpassungen in Zielen und / oder der Entwicklung durchzusetzen.

Ziele werden dabei weniger als Anforderungen sondern mehr als Ergebnis beschrieben, aber eben aus Sicht des Kunden. Hiermit ist kein überbordender Requirements-Katalog gemeint, zumal sich die Dinge in der Entwicklung eh ständig ändern. Die Anforderungen werden nach Prioritäten geclustert und als kleine Arbeitspakete – den sogenannten Sprints – schrittweise abgearbeitet. Das Team organisiert hierbei Zeit und Methode. Nach jedem Sprint werden die Ergebnisse reflektiert und überprüft.

Mehr Eigenverantwortung ist gefordert.

Die Grundprinzipien der agilen Entwicklung basieren auf dem Lean Management-Prinzip. Zudem handelt es sich um eine ausgeprägt teamorientierte Entwicklungsmethode und verträgt sich nicht mit Hierarchiedenken. Durch ein schrittweises Vorgehen mit der Lieferung von Teilumfängen werden Hemmnisse und Änderungen im Fortschritt sehr schnell sichtbar. Hierfür sind kurze fast tägliche Meetings sinnvoll, um jeden über den Stand der Arbeiten zu informieren und das weitere Vorgehen abzustimmen. Optimalerweise sitzen die Teammitglieder in wichtigen Projekten räumlich zusammen.

Die Erfahrungen zeigen, dass die Teams mehr Eigenverantwortung an den Tag legen und gemeinsam die Ergebnisse getragen werden. Hierdurch entsteht mehr und mehr Gruppendynamik im Team, welches sich eigenverantwortlich in der Art und Weise der Zusammenarbeit selbst organisiert.

Dabei muss in der Teamzusammensetzung auf geeignete Persönlichkeiten geachtet werden, die mit dem Mehr an Verantwortung vertrauensvoll umgehen können. Eine Mischung aus Fachleuten und kommunikationsstarken Treibern ist der halbe Schlüssel zum Erfolg.

Fazit und unsere Erfahrungen mit der agilen Entwicklungsmethode.

Wir sehen im Einsatz der agilen Methoden in der Entwicklung komplexer Produkte mit Hardware- und Software-Komponenten die Chance, in Teilbereichen die Effizienz der Entwicklung deutlich zu steigern.

Allerdings sind wir der Meinung, dass die klassischen Entwicklungsprozesse sehr wohl fortbestehen und mit Scrum Methoden kombiniert werden können. Kleine Teilprojekte lassen sich beispielsweise gut nach Scrum Methoden integrieren. Daher ist es aus unserer Sicht kein Widerspruch.

Für bestimmte Einzelprojekte reichen die reinen Scrum Ansätze sehr gut aus und sind wesentlich schneller.

Welche Methode wann die richtige ist, muss jeder für sich selbst herausfinden. Machen Sie Ihre eignen Erfahrungen. Im Prozess entscheidet sich, mit welchem Verhältnis von Nutzen zu Aufwand, d.h. mit welcher Effizienz, das Ergebnis erzeugt wird.

Zusammenfassung Scrum:

  • Scrum ist in der Regel schneller, aber nicht immer geeignet.
  • Die agile Methode Scrum kann sehr gut mit herkömmlichen Methoden kombiniert werden.
  • Scrum reduziert weder die Komplexität der Aufgabe oder der Lösungsfindung, strukturiert sie aber in kleinere Inkremente und weniger komplexe Bestandteile.
  • In Scrum-Teams brauchen Sie eine offene Kommunikation und eine Fehlerkultur ist willkommen.
  • Hierarchiedenken verträgt sich nicht mit diesen Methoden.
  • Der Einsatz agiler Entwicklungsmethoden muss unbedingt auf die jeweilige Situation angepasst werden und ist in Teilbereichen oder bei Großprojekten nur bedingt zu empfehlen.

Wenn Sie sich für Scrum interessieren, nehmen Sie Kontakt zu uns auf, wir freuen uns Sie unterstützen zu können. Aus Erfahrung wissen wir, dass sich insbesondere in interdisziplinären Strukturierungs- und Plattformprojekten die Methoden sehr gut bewährt haben.


Ähnliche Beiträge:


Pricing in CPQ-Prozessen

Pricing in CPQ-Prozessen

Erfolgreiches Projektmanagement

Erfolgreiches Projektmanagement

Produktordnungssystem in CPQ-Prozessen

Produktordnungssystem in CPQ-Prozessen