Seit 2001 existiert das agile Manifest, an welchem sich agiles Arbeiten und auch Scrum anlehnen. Das dritte Prinzip dessen lautet: „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“
In Softwareproduktentwicklungen ist dieser Punkt meist einfach zu realisieren. Viele unserer Kunden sind aber nicht nur auf reine Softwareprodukte spezialisiert.
„Ja in der Software ist das kein Problem. Aber wie sollen wir unser Produkt inklusive Software, Platinen, Gehäuse, (beliebige weitere Komponenten hier einfügen) in 2-wöchigen Zyklen an den Kunden bringen?“
Der einfache Weg wäre zu behaupten, dass dies nicht ginge und sich darauf auszuruhen. Verinnerlicht man sich jedoch, dass ein Unternehmen, welche diese Herausforderung bewältigt einen entscheidenden USP generiert, wird es interessant.
Nehmen wir an, es gäbe ein Unternehmen, welches seit jeher alle 2 Jahre eine neue Version ihres Produktes auf den Markt bringt. Dieses, schafft es jedoch nicht, zum Zeitpunkt der Implementierung von Scrum alle 2 Wochen ein Potentially Shippable Product auf den Markt zu bringen.
Ist ein agiler Ansatz für dieses Unternehmen dann nicht erlaubt?
Das regelmäßige Kundenfeedback und das daraus resultierende Lernen ist einer der Stützpfeiler agilen Arbeitens. Den Kunden möglichst früh zu involvieren und regelmäßig zu konsultieren führt zu besseren Produkten und zufriedeneren Kunden. Wie reduziere ich aber einen Releasezyklus, wenn meine derzeitigen Rahmenbedingungen dies nicht zulassen?
Eine Möglichkeit, diese Fragestellung nicht abzuschreiben, sondern sich näher mit diesem Thema zu befassen bietet hier die
Definition of Undone Work
Die Grundgedanken zu diesem Konzept basieren auf der Definition eines Produkt Inkrementes aus dem LeSS (Large Scale Scrum) Kontext.
Dort (https://less.works/less/framework/definition-of-done.html) heißt es:
Potentially Shippable = Definition of Done + Undone Work
Ein potentiell auslieferbares Produkt, besteht aus den Punkten der Definition of Done plus den offenen „Nicht-erledigten“ Aufgaben.
Genau hier greift folgende Idee:
Gemeinsam mit dem Team versucht man hier den Status Quo zu visualisieren:
- Welche Arbeiten verstehen wir im Moment unter der Definition of Done, welche wir alle 1-4 Wochen als „Done“ anerkennen? (Ein neues Team würde sich hier die Frage stellen, welche Arbeiten sinnvoller Weise innerhalb dieses Zeitrahmens zu erledigen sind)
- Welche Arbeiten machen wir nur vor wichtigen Terminen? (Gibt es hier Prototypen-/Betatester-/Kundenakzeptanzphasen?)
- Welche Arbeiten erledigen wir immer erst kurz bevor unser Produkt in die Produktion geht?
Allein durch die Visualisierung dieses Status Quos gewinnt man im Normalfall Einsichten, welche das Team wertschätzt.
Im nächsten Schritt kann man sich dann die Frage stellen, ob und wie man diese Situation verändern möchte:
Im ersten Schritt analysiert das Team die Tätigkeiten, welche normalerweise nur im Rahmen eines Prototyps oder der Produktion erledigt werden. Gemeinsam wird überlegt ob und wie Sie diese Arbeiten automatisieren und/oder vereinfachen können. Im Anschluss kann das Team sich die Schritte überlegen, die nötig sind um diese Punkte in die DoD eines Sprints mit einzubeziehen.
Im zweiten Schritt kann man dann – da der Aufwand für die Erstellung eines Prototypen und/oder eines Produktionsrelease gesunken ist – über eine Verkürzung der Releasezyklen sprechen.
Auf diese Weise kann man den aktuellen Status Quo akzeptieren und gleichzeitig ein Entwicklungspotential für die Zukunft erarbeiten. Punkte die sich heute für diesen Prozess vielleicht noch surreal anfühlen (Technische Sicherheitsabnahmen durch Drittparteien, Staatliche Zulassungsprozesse, etc.), könnten in Zukunft vielleicht geringere Hürden darstellen. So einige erwartete Stolpersteine könnten sich gar als einfache Veränderungen entpuppen.
Beispiele aus unserem Alltag:
- Eine Dokumentation nach ISO 9001 (Bsp. Abschnitt 6.2.1) kann mit geringen Aufwänden schon in einem Sprintrhythmus abgeschlossen werden. Grob, muss dokumentiert sein, Wer sich Was mit welchem Nutzen gewünscht hat. Ein gut gepflegtes Product Backlog mit qualitativen UserStories erfüllt dies.
- Eine Platine für einen Test kann man heutzutage schon mit Herstellungs- und Lieferzeiten von unter einer Woche bekommen. Zwar ist dies teurer als eine Eigenproduktion; aber zum Testen und Weiterentwickeln reicht dies allemal.
- 3D Drucke können schnell ein Gehäuse aus Aluminium ersetzen. Während der Entwicklung ist die Stabilität und Dauerbelastbarkeit meist nicht so entscheidend wie Passform und Optik. Ein schneller Druck über Nacht bringt hier deutlich schnelleres Feedback.
Wollen auch sie in einer agilen Welt einen USP durch Geschwindigkeit am Markt erreichen? Sprechen sie uns gern unter info@emendare.de an oder melden sie sich zu einem unserer Trainings an.
