
Agile Coach | Softwareentwickler
10. Januar 2024

Man stelle sich einen altehrwürdigen Hafenmeister vor, in dessen Hafen drei Schiffe vor Anker liegen. Die Kapitäne sind unruhig und fordern lautstark als erstes entladen zu werden, um wieder schnell den Hafen verlassen zu können. Zeit ist schließlich Geld.
Da der Hafenmeister seine Ruhe haben möchte, sendet er seine drei Hafenarbeiter aus, um die Schiffe entladen zu lassen. Jeder Hafenarbeiter benötigt für „sein“ Schiff 3h. Alle werden gleichzeitig bedient, alle Kapitäne sind zufrieden, es wird ja schließlich auf dem eigenen Schiff gearbeitet. Nach drei Stunden können alle drei Schiffe wieder auslaufen.
Alle sind zufrieden, nur der Reeder nicht, der sich das Schauspiel von oben angesehen hat. Nach einem Telefonat soll der Hafenmeister das nächste Mal doch anders vorgehen. Am nächsten Tag fahren erneut drei Schiffe in den Hafen ein. Dieses Mal erklärt er den Kapitänen, dass die Schiffe nacheinander entladen werden und sendet seine drei Mitarbeiter zu dem ersten Schiff. So ist das erste Schiff bereits nach einer Stunde entladen und kann auslaufen, das Zweite nach zwei Stunden. Das dritte Schiff kann nach drei Stunden auslaufen, es benötigt jedoch nicht länger als die Schiffe an dem Vortag. Die Arbeit für die Hafenarbeiter ist an beiden Tagen identisch.

Natürlich kann dieses Prinzip nicht eins zu eins in die reale Welt übertragen werden. Es gibt Zeiten der Anfahrt, des Wechsels und auch Abhängigkeiten. Dennoch hat dieses einfache Prinzip, einfach angewendet hohes Potential. Kunden können frühzeitig Ergebnisse erleben und ihre Roadmap ggf. anpassen. Die Termintreue verbessert sich und der Ressourcenverbrauch nimmt ab. In Summe fördert es eine agile Vorgehensweise. Es zeigt sich, dass Effizienz nur eine Messgröße von Wirtschaftlichkeit ist, jedoch gibt es weitere Dimensionen wie z.B. die Durchlaufzeit.
Was einen durchaus verblüffen kann (wo sind die drei Stunden geblieben?) wird speziell in dem ersten und dritten Prinzip des agilen Manifests deutlich. „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen“ und „liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“ Der Begriff „Software“ lässt sich entsprechend durch Produkte, Dienstleistung oder sonstige mehrwertbringende Erzeugnisse ersetzen.

Interessant beim Schreiben dieses Artikels, offenbar kannte weder Wikipedia noch ChatGPT das Hafenmeister-Prinzip. Zeit es bekannter zu machen 😊.

Tobias Lauffer
Ich bin Agile Coach und Softwareentwickler bei pep.digital. Als überzeugter Agilist verbinde ich technisches Entwicklungs-Know-how mit fundierter Methodenkompetenz in Scrum und agilen Frameworks. In der Softwareentwicklung liegt mein technischer Schwerpunkt auf Frontend-Systemen – von sauberem, wartbarem Code bis zu robusten barrierefreien Anwendungsarchitekturen in der Individualentwicklung. Als Systemischer Coach begleite ich Teams und Unternehmen dabei, agile Werte nicht nur einzuführen, sondern wirklich zu leben – von der ersten Retrospektive bis zu skalierten Prozessen in der Individualentwicklung. Als Certified Scrum Professional (Scrum Master (CSP-SM), Certified Scrum Developer (CSD), Certified Scrum Product Owner (CSPO)) bringe ich methodisch gesichertes Fachwissen in jedes Projekt und jeden Blogsartikel ein und teile konkrete Erfahrungen aus Kundenprojekten bei pep.digital: von Kundenportalen über Produkterweiterungen bis zu Digitalisierungsvorhaben im Mittelstand.
Quellen
Weitere interessante Artikel
Wir möchten hier nicht nur über Neuigkeiten aus dem Unternehmen berichten, sondern auch das Wissen und die Erfahrung unserer Experten teilen.

In diesem Artikel zeigen wir, wie ein Proxy Product Owner die Arbeit in Softwareprojekten erleichtern kann. Ein Proxy PO unterstützt den Product Owner, indem er Aufgaben übernimmt, für die der Product Owner oft nicht die Zeit oder Erfahrung hat. Dazu gehört die Ermittlung von Kundenbedürfnissen, das Erstellen von User Stories, die Planung der nächsten Schritte und die Klärung fachlicher Fragen. So werden Engpässe vermieden und das Entwicklungsteam bleibt produktiv.

Karin Neubauer
Business Analystin

Eine einfache Lösung in C# zur Konvertierung von römischen Zahlen. C# setzen wir auch gerne bei der Umsetzung unserer Kundenprojekte ein.

Kevin Erath
Geschäftsführer








.webp&w=3840&q=90)





