Iterativ die beste Lösung finden – Hardwareentwicklung mit SCRUM

Anbieter zum Thema

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

PTC

alpha board gmbh

Wie SCRUM in der Hardwareentwicklung aussieht

Es geht hauptsächlich darum, dass wir nicht zwangsläufig am Ende eines Sprints neue Hardware fertigen lassen, die wir liefern. Sondern eben entweder Quick-&-Dirty-Prototypen, die wir selber basteln, oder auch Stromlaufpläne, Layouts oder ähnliches, die auch vom Kunden testbar sind. Oder wir liefern für bereits vorhandene (in früheren Sprints gelieferte) Prototypen-Hardware neue Funktionalität per Firmware.

Wir haben alle Projekte des Unternehmens auf unser Kanban-Board gebracht und machen vor diesem Board auch unseren Daily SCRUM. Das hat den Vorteil, dass alle wissen, wo was zwickt, und eventuell untereinander Hilfe-Stellung leisten. Projekte, die unter 20 Stunden dauern, haben nur eine Projektkarte, die wir mit einem Blitz versehen. Nur größere Projekte werden in User Stories und Aufgaben zerlegt. Diese haben aber auch eine Projektkarte.

Unser Kanban-Board hat die folgenden Spalten:

• Projekt (Name, Dauer, Team-Mitglieder)

• User Stories

• To Do (dort kommen die Aufgaben rein)

• WiP (Work in Progress: idealerweise steht hier nur 1 Aufgabe pro Mitarbeiter)

• Waiting (für Aufgaben, die auf äußere Einflüsse warten, z.B. Nachfragen, Lieferungen oder Freigaben)

• Done (Fertig)

• Testing (unterteilt in „To Test“ und „Test in Progress“)

• Ready for Review (zuerst mit dem Product Owner, dann mit dem Kunden)

Als Dienstleister müssen wir alle Anfragen erst einmal schätzen, um anzubieten, bevor überhaupt irgendwelche Projekte starten. Wir schätzen mit Planning Poker, weil aus unserer Erfahrung ein Team besser schätzt als einzelne Personen und Planning Poker die Diskussion vereinfacht.

Doch selbst dann war unsere Erfahrung, dass die geschätzten Aufwände nicht ganz zur Realität passen und wir oft falsch lagen. Also haben wir noch einen weiteren Schritt eingeführt, das sogenannte Grooming. Das heißt, ein Ingenieur schaut sich die User Story an, stellt Fragen (falls nötig) und beschreibt die geplante Umsetzung der Story.

Bevor wir den Aufwand für eine Anfrage schätzen, müssen die einzelnen User Stories erstmal gegroomt werden. Falls Fragen kommen, muss der Product Owner diese mit dem Kunden klären, bevor es mit dem Groomen weiter geht.

Der Aufbau unseres Grooming Boards sieht folgendermaßen aus:

• Ready to Groom (vorher werden die Stories dem Team vorgelesen)

• Grooming in Process

• Fragen

• Ready for Planning

Nicht gegroomte Stories werden nicht geschätzt, so lautet eine Vereinbarung mit dem Team. Damit das Team groomen kann, muss es Zeit haben, die von der täglichen Zeit abgeht, die für den Sprint zur Verfügung steht. Das berücksichtigt das Team beim Sprint Planning und es ist auch dem Management bekannt.

Fazit: Mit SCRUM wird alles gut

Wir arbeiten seit fast einem halben Jahr nach SCRUM, erst in einem Projekt-Team und nun mit allen Projekten unserer Firma. Bis heute lernen wir viel darüber, wie wir noch besser SCRUMmen können. Wir sind auch ganz sicher, dass die Art und Weise, wie wir das derzeit machen, noch nicht perfekt ist. Aber wir wissen, dass wir nicht mehr in die alte, SCRUM-freie Welt zurück wollen. Mit SCRUM haben wir mehr Transparenz, weniger Ärger und mehr Spaß an unserer Arbeit.

Literaturhinweise:

[1] Boris Gloger: SCRUM - Produkte zuverlässig und schnell entwickeln

Hier steht Blindtext für ein

[2] Mike Cohn: Agile Software-Entwicklung - Mit SCRUM zum Erfolg!

* Gregor Groß ist Geschäftsführer des Berliner Elektronik-Designhauses alpha-board.

(ID:42692142)