In der Softwareentwicklung stößt man immer mit mehr oder weniger Freude auf sogenannte „U-Boot-Projekte“. In diesem Blog möchte ich Ihnen einmal zeigen, wie man diese Art von Projekte erfolgreich verhindern kann.
U-Boot-Projekt?
Als U-Boot-Projekte versteht man im Bereich der industriellen Forschung & Entwicklung ein Projekt, welches ohne offizielle Genehmigung und ohne Kenntnis der verantwortlichen Organisationsleitung innerhalb der Organisation bearbeitet wird. Dazu existiert keine ausgearbeitete Projektplanung und den Projekten sind formell keine Ressourcen und Produktionsmittel zugewiesen.
https://www.grin.com/document/302702#:~:text=Als%20U%2DBoot%2DProjekte%20versteht,innerhalb%20der%20Organisation%20bearbeitet%20wird.
Wenn wir diese Definition lesen treffen wir auf viele positive Faktoren, die in der agilen Softwareentwicklung zur Tugend gehören sollten. Da ist eine Forschung, zu der dann auch das Experimentieren gehört und die Selbstorganisation der Teams, welche bei jeder Kleinigkeit eine Genehmigung einholen müssen. Trotzdem haben wir ein Problem in der agilen Softwareentwicklung
Warum ist es ein Problem?
Das Problem besteht im Nebensatz „ohne Kenntnis der verantwortlichen Organisationsleitung innerhalb der Organisation bearbeitet wird“. Aus meiner Sicht ist die zentrale Nachricht des agilen Manifestes die vertrauensvolle Zusammenarbeit auf Augenhöhe. Mit einem U-Boot-Projekt wird dieses zentrale Verhältnis gestört. Warum werden U-Boot-Projekte trotzdem durchgeführt? Grund hierfür ist eine Spannung zwischen der Führung und den Software-Entwickler. Der Software-Entwickler hat eine gute Idee, welches von der Führung abgelehnt wird. Diese Ablehnung wird in internen Gesprächen oft mit „Mir doch egal, ich mach das eh anderes“ kommentiert.
Warum fällt es nicht auf?
Die Arbeit des Softwareentwicklers ist sehr komplex und die Dauer zur Umsetzung eines Features ist schwer zu kontrollieren. Diese Ungenauigkeit nutzt der Mitarbeiter aus oder macht dies unbewusst, da er nicht mit voller Geschwindigkeit am eigentlichen Thema arbeitet. Schlimmer geht es für die Führung natürlich noch, wenn der Entwickler einen Großteil seiner Gehirnenergie dafür nutzt sich darüber aufzuregen, warum seine gute Idee nicht umgesetzt wurde und er diese Aufgabe jetzt „falsch“ machen muss. Klingt nach einem unmotivierten Mitarbeiter? Ist aber sehr menschlich und die Führung ist daran schuld.
Addicted to yes
Natürlich sollte man als Führung nicht alles durchwinken, aber sofern keine offensichtliche Probleme existieren, sollte man seine Mitarbeiter enablen und ihnen den Freiraum lassen, das richtige für das Unternehmen zu tun. Wichtiger ist es hier richtige Rahmenbedingungen zu setzen. „Gerne! Probier es aus, aber lass es uns auf 1 PT Timeboxen“ – „Natürlich kannst du das machen, aber stell sicher das Sicherheitsrichtlinie xy sichergestellt wird.“
An dieser Stelle muss einmal der Konsent als verbesserter Konsens erwähnt werden. Ein Konsent existiert, wenn keiner dagegen ist. Eine Kombination schafft einen sehr kreativen Boden Dinge auszuprobieren und dadurch erfolgreiche Produkte zu erstellen. Ein möglicher Rahmen ist die Einführung von sogenannter Slacktime.
Was ist wenn es schief geht?
Natürlich kann ein Vorhaben eines Mitarbeiters auch schief gehen und als Führung hat man es natürlich von Anfang an gewusst. Trotzdem wurde es geschafft diese Gedanken des Mitarbeiters zu löschen und dieser kann dadurch wieder fokussiert arbeiten.
Wie verhalte ich mich als Mitarbeiter
Sofern man Ablehnung erfährt, sollte man nicht einfach ein U-Boot-Projekt starten. Sofern man sich sicher ist, dass dies der richtige Weg ist, sollte man für seine Idee einstehen. Vielleicht gibt es ja tatsächlich relevante Gründe, warum dies doch keine so gute Idee ist. Auch hier sollte man eine offene Kommunikation auf beiden Seiten einfordern.
Fazit
Offene Kommunikation ist ein Schlüssel in der modernen Softwareentwicklung. Durch die Transparentmachung dieser Ideen in, z.B. einem Daily, können anderen Kollegen profitieren und es wird ein ehrlicher Umgang gepflegt. Als Führungskraft sollte man die guten Ideen der Mitarbeiter natürlich nicht unterdrücken, sondern es fördern das diese transparent kommuniziert werden. Nur so kann am Ende auch retrospektiv auf den Erfolg oder Misserfolg geschaut werden.
