Projektmanagement: In der Component Factory

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Manchmal werde ich gefragt, was so schlecht daran ist, Features zu entwickeln. Nichts ist daran schlecht, wenn es jemanden gibt, der die Features möchte und braucht. Doch ist das bei der eigenen Arbeit überhaupt der Fall? In der sprichwörtlichen Feature Factory ist das kaum zu erkennen. Es fühlt sich für viele Menschen nicht gut an, wie am Fließband Tickets zu bearbeiten, von denen Dritte sagen, dass sie nützlich sind. Selbst einzuschätzen, wie wertstiftend die eigene Arbeit ist, kann aus vielen Gründen schwierig sein. Ein Grund: Man arbeitet nicht an einem Produkt, sondern an einer Komponente eines Produkts.

Als Beispiel verwende ich gerne die (vereinfacht betrachtete) Entwicklung eines Autos. Angenommen, die Entwicklung findet in drei Teams statt: eines für den Motor, eines für die Karosserie, eines für das Fahrwerk. Wenn jedes Team nur seine eigene Aufgabe erledigt und das vollständige Auto nirgends zu sehen ist, ist es eigentlich keine Autoentwicklung. In den drei Reviews sind jeweils nur einzelne Komponenten zu sehen und die lösen das ursprüngliche Problem nicht (“Bring Menschen von A nach B”). Man kann auch keine (Auto-)Käufer fragen, wie sie den Zwischenstand des Autos finden.

Für firmeninterne Stakeholder, die am Auto interessiert sind, bedeutet das, sie müssen in drei Reviews gehen und ein wenig Fantasie mitbringen, um die Komponenten gedanklich zu integrieren.

Diese Arbeitsweise halte ich für so absurd, dass ich immer wieder glaube, Unternehmen sind aus diesem Stadium längst hinaus. Im agilen Kontext geben sich die Skalierungsframeworks die Klinke in die Hand, um unter anderem das geschilderte Szenario zu vermeiden. Trotzdem begegnen mir isolierte Komponententeams immer noch. Also stellt sich die Frage, was ich als Mitglied eines solchen Teams selbst tun kann, um aus dem Silo herauszukommen.

Hier ein paar praxiserprobte Vorschläge:

Erstens. Geh in die Reviews oder vergleichbare Meetings der anderen Komponententeams. Wenn du dafür sorgfältig aufgebaute Silogrenzen (aka Abteilungs-/Teamgrenzen) überschreiten musst, ist dein Feingefühl gefragt. Es kann passieren, dass die anderen Menschen irritiert sind. In so einem Fall frage ich erst mal höflich, ob ich zuhören darf. Das ist meistens ok. Nur sehr selten stoße ich auf Ablehnung.

Des Weiteren ist es gut, darauf zu achten, wie bisher die Koordinierung der Teams stattfindet. Wer trägt die Informationen von einer Seite zur anderen? Wer schneidet die Aufgaben in Komponententickets? Hier kommen viele Rollen infrage. Vielleicht macht es der Product Owner oder eine Softwarearchitektin? Sprich mit dieser Person, um ihr nicht auf die Füße zu treten!

Im zweiten Schritt kannst du die Kolleginnen und Kollegen aus den anderen Komponententeams in euer Review einladen. Das kann dann wiederum zur Irritation bei deinen eigenen Leuten führen. Auch hier hilft es, vorher den Boden zu bereiten. Sag deinen Teamkolleginnen und -kollegen, dass du im Review gerne mal eine Rückmeldung der Nachbarteams bekommen möchtest.

Wenn beide Verhaltensweisen akzeptiert sind, lautet der nächste Schritt: Versuch ein Meeting zu organisieren oder dich zu einem einladen zu lassen, indem das vollständige und integrierte Produkt zu bestaunen ist. In vielen Fällen gibt es das schon, weil schließlich irgendwer die Integration vornehmen muss. Wenn es eine QA-Abteilung, eine Testabteilung oder Ähnliches gibt, ist es eine gute Idee, sich über deren Arbeit zu informieren. Vielleicht findet dort die Integration statt.

In seltenen Fällen habe ich erlebt, dass es keine ordentliche Integration während der Entwicklung gab. Der Plan lautete, dass die Integration erst stattfinden soll, wenn alle Komponenten fertig sind. Die Arbeit an den Schnittstellen stand im Vordergrund und die Komponententeams haben sehr lang ausschließlich gegen gemockte Schnittstellen getestet. Ich hoffe, das ist die Ausnahme.

Fazit

Mit etwas Glück ist dieser Blogbeitrag für niemanden interessant. Jedoch beobachte ich mit Staunen, dass es immer noch Unternehmen gibt, in denen mehrere Teams an einem Produkt oder Service arbeiten, ohne dass die Teammitglieder die eigene(!) Erfahrung des gesamten Produkts machen können, an dem sie arbeiten. Doch niemand muss auf die nächste Reorganisation des Unternehmens warten.

Bleib nicht allein in deinem Team, sondern baue dein firmeninternes Netzwerk auf und tausche dich mit den anderen Teams aus! Nicht nur die Produktentwicklung wird davon profitieren. Es fühlt sich auch für dich viel besser an, wenn du deinen eigenen Beitrag im Kontext des integrierten Produkts erlebst. (rme)