Beiträge

Die Montageplanung eines süddeutschen Automobilunternehmens entwickelt bisher ihre Prozesse und Systeme nach klassischer Wasserfall-Vorgehensweise. Nun soll ein neues Montage-Steuerungsplansystem auf Basis von Scrum realisiert werden. Der agile Ansatz verspricht schnellere Resultate und engere Zusammenarbeit zwischen der Fach- und IT-Seite. Das Problem dabei: die beauftragte Fachabteilung ist mit Scrum und dem notwendigen Product Backlog nicht vertraut. Wie soll das Team innerhalb kurzer Zeit ein fundiertes Backlog für die technischen Entwickler liefern?

Problem: Umstieg auf Scrum in der Fachabteilung – ein Product Backlog muss her

„Agil, agil, agil – ich kann das Wort langsam nicht mehr hören!“. Elke Berlitz – Leiterin der Montageplanung Automotive – stöhnte leicht und drehte frustriert ihren Kopf zur Seite. Ihr gegenüber saß Jens Karstens, ein junger IT-Projektleiter, der zuvor bei einem Technologie Start-up tätig gewesen war. Seit 1999 war Elke Berlitz jetzt in der Firma. Bisher hatte sie und ihre Kollegen Prozess- bzw. IT-Systementwicklungen klassisch mit einem Grob- und mit einem Fachkonzept definiert. Das Dokument übergab ihr Team dann an den verantwortlichen IT-Projektleiter. Dieser trieb die Implementierung voran und lieferte was die Fachseite zuvor spezifiziert hatte.

Soweit, so gut. Zumindest für ihre knapp 20 Jahre im Unternehmen. Nun sollte dieses bewährte Wasserfall-Vorgehen aus Analyse, Design, Umsetzung, Test und Roll-out abgelöst werden. Statt die einzelnen Phasen nacheinander zu durchlaufen, war Berlitz und ihr Team nun für ein sogenanntes Product Backlog verantwortlich. Eine Liste mit Anforderung, die Tag für Tag wuchs, stetig im Fluss war und als dynamische Diskussionsgrundlage mit den Entwicklern diente.

„Für das neue Montage-Steuerungsplansystem brauchen wir ein solides Product Backlog.“ insistierte Jens Karstens und ergänzte „Dieses untergliedert sich in Epics, die wiederum einzelne User-Stories enthalten. Jede User Story verfeinert ihr durch mehrere Akzeptanzkriterien und weist ihr schließlich eine Priorität zu. Was ist daran so kompliziert?“. Elke Berlitz rollte mit den Augen. „Jens, Du hast gut reden. Du kennst agile Entwicklungsverfahren wie Scrum von Deinem früheren Arbeitgeber. Doch bei uns? Backlog, Stories, Epics – das sind für die Fachkollegen doch alles nur böhmische Dörfer.“.

Jens Karstens ließ nicht locker: „Ich verstehe, der Scrum Ansatz ist hier neu. Doch beachte seine Vorteile. Statt ein großes Fachkonzept bis zur Perfektion zu treiben, nähern wir uns schrittweise der Ideallösung. In wenigen Monaten haben wir ein erstes lauffähiges IT-System auf Basis dessen Ihr Eure optimierten Fachprozesse umsetzen könnt. Stück für Stück erweitern wir dann dieses System.“. Berlitz nickte. Tatsächlich bot ein agiler Ansatz mehrere Vorteile. Nicht umsonst hatten sich ihre Chefs diesem neuen Modell verpflichtet. Doch half ihr das in Sachen Backlog auch nicht weiter.

Da das Meeting gleich zu Ende war, warf Frau Berlitz ein: „Ich schlage vor, wir lassen uns bei unserem ersten Product Backlog durch einen externen Experten unterstützen.  Jemanden, der die Struktur, das Vorgehen und die Eigenschaften eines guten Backlogs genau kennt. Ein Dienstleister, dem wir vertrauen können und der die Sache in unserem Sinne mit hoher Qualität vorantreibt.“. „Klingt gut.“ entgegnete Jens Karstens „An wen hast Du gedacht?“.

Vorgehen: Gemeinsame Arbeit an den User Stories – nach agilem Ansatz und klaren Kriterien

Elke Berlitz zögerte nicht lange und kontaktierte die fachkundigen Requirements Engineering Experten von mosaiic. In der Vergangenheit hatten diese für Ihr Unternehmen exzellente Grob- und Fachkonzepte in der Montageplanung verfasst. Von einem Kollegen aus dem Elektronik/Elektrik-Bereich hatte sie gehört, dass mosaiic auch den Scrum Product Owner bei der Erstellung des Product Backlogs zur Seite stand. Erfreut, Elke Berlitz unterstützen zu können, erfassten die mosaiic Berater zunächst den funktionalen Scope des Systems. Dazu klärten sie folgende Fragen:

  • Welche System- und Kontextgrenzen besitzt das Montage-Steuerungsplansystem?
  • Welche Anforderungsquellen sind zu berücksich-tigen (Dokumente, Systeme, Experten)?
  • Neben User Stories: wie soll das Montage-Steuerungsplansystem noch beschrieben werden?

Die Ergebnisse erfassten die Consultants in einem Big Picture (siehe Abbildung). Dem gesamten Team war damit jederzeit klar, aus welchen Quellen die Anforderungen kamen, wie das Product Backlog aufgebaut sein sollte und welche Ergebnisse neben dem Backlog Einträgen noch entstehen würden.

Montage-System: Von den Anforderungsquellen zum ausgereiften Product Backlog

Abbildung: Montage-System: Von den Anforderungsquellen zum ausgereiften Product Backlog

Die Berater bestanden darauf, mit der fachlich wichtigsten Epic zu beginnen – der Anlage eines Montage-Steuerungsplans. In einer Serie von zwölf 90-minütigen Arbeitssitzungen spezifizierten sie gemeinsam mit Elke Berlitz und ihren Kollegen rund 50 User Stories inklusive Akzeptanzkriterien. Grundlage war das aus Scrum bekannte CCC-Prinzip. Jede User Story fixierte das Team auf einer eigenen Karte (Card) Card, nutzte die Story als Gesprächsgrundlage (Conversation) und reicherte sie peu à peu mit Akzeptanzkriterien (Confirmation) an. Geprüft wurde eine User Story anhand der Scrum INVEST- Kriterien: Unabhängigkeit (Indenpent) der User Story von anderen, Verhandelbarkeit (Negotiable) des Story-Inhalts, fachlicher Wertbeitrag (Valuable), Schätzbarkeit (Estimable), handhabbare Größe in einem Entwicklungszyklus (Small) sowie Testbarkeit (Testable).

Zusätzlich zu den textuellen Epics, User Stories und Akzeptanzkriterien fertigten die mosaiic Berater Bildschirmmasken mit Microsoft Visio an. Die Masken halfen den Fach- und IT-Kollegen ein gleiches Verständnis von der graphischen Benutzerschnittstelle zu entwickeln.  Eine User Story verwies direkt auf die ihr zugehörigen Masken. Auch Begleitpapiere wie Wertetabellen, Schnittstellendetails und Attributlisten verknüpfte das Team direkt mit den User Stories. Alles war so an einer Stelle.

Ergebnisse: ein ausgereiftes Product Backlog, bereit für die technische Umsetzung

In weniger als drei Wochen stand die erste Fassung des Product Backlogs mit den beiden wichtigen Epics ‚ Montage-Steuerungsplan anlegen’ und ‚Montage-Steuerungsplan anzeigen’. Alle Stories waren spezifiziert, priorisiert sowie bereit für die Aufwandsschätzung und einer anschließenden technischen Umsetzung. Auf Empfehlung der mosaiic Consultants setzte sich Elke Berlitz noch vor Monatsende mit Jens Karstens in Kontakt.

Nun war die IT an der Reihe, auf Basis des Backlogs eine präzise Schätzung abzugeben und in die Implementierung zu gehen.

Frau Berlitz war zufrieden mit den Ergebnissen. Backlog, Bildschirmmasken sowie weiterführende Dokumente entsprachen ihren Erwartungen an Inhalt und Qualität. „Hoffentlich gehen die IT-Entwickler im Scrum Team ähnlich schnell und fokussiert zu Werk.“ sagte sie zu sich selbst „Wie gut, dass ich als Product Owner für das Team weiter zur Verfügung stehe.“.

Sie wusste, dass ihre Arbeit und die Unterstützung von mosaiic noch lange nicht zu Ende waren. Die User Stories mussten teilweise präzisiert und weitere Epics definiert werden. Der Weg bis zum fertigen Montage-Steuerungsplansystem war noch lang. Doch war nun ein erster wichtiger Schritt getan. Elke Berlitz war bereit die nächste Etappe in Angriff zu nehmen – gemeinsam mit mosaiic.

mosaiic Case zum Download
Laden Sie die Fallstudie als praktischen PDF 2-Seiter herunter.

Sie planen die Prozesse und Systeme ihrer Montageplanung agil weiterzuentwickeln? Gerne unter-stützen wir Sie in Ihrer Rolle als Product Owner mit unserem praxiserprobten Know-How und fundierten Methodenwissen. Sprechen Sie uns an.

Ansprechpartner: Tobias Smuda

Text: Dr. Christopher Schulz

2018 werden in immer mehr Unternehmen die Geschäftsprozesse digitalisierst, Abläufe durch Software Lösungen teilweise bis vollständig automatisiert. Doch bevor ein neues Tool die Arbeit aufnimmt, muss es am Markt gefunden, angepasst und aufgesetzt werden. Gerade der Such- und Auswahlprozess gestaltet sich herausfordernd. Fast immer offeriert der Markt eine Fülle mehr oder weniger vergleichbarer Lösungen unterschiedlicher Hersteller. Für die Fach- und IT-Bereiche stellt sich die Frage, welche Software aus finanziellen, fachlichen und technischen Gesichtspunkten die perfekt passendste für das Unternehmen ist. Vor der Entscheidung steht eine Tool Evaluierung, die systematische Bewertung von möglichen Software Alternativen. Im mosaiic Impuls geben wir Ihnen vier Tipps für eine bessere Software Auswahl.

Weiterlesen