Brich aus der Feature Factory aus!

Leider hören wir immer wieder sehr kritische Stimmen bezüglich Agilität und Scrum. Software-Entwickler oder Manager hinterfragen, warum agile Software-Entwicklung besser ist als die vorherige Arbeitsweise, die sie jahrelang ans Ziel gebracht hat und das sehr oft zurecht. Denn viel zu häufig werden agile Methoden, wie OKR oder Scrum falsch umgesetzt oder werden in Organisationen und Umgebungen betrieben, die eine agile Arbeitsweise verhindern. Das Resultat sind dann oft Überforderung, Meetingoverhead und Feature-Factories.
Doch was sind Feature-Factories und wie können wir aus ihnen ausbrechen? Ist Scrum die effizienteste Methode, um im Team zu arbeiten? Sollen wir wirklich alle auf Scrum und Agilität setzen?

Was ist die Feature-Factory?

Feature-Factory ist ein Begriff, der beschreibt, wie ein Team arbeitet. In einer Feature-Factory hat das Team wenig Einfluss auf das was Implementiert wird. Das Team wird von der Organisation nur zur Umsetzung von Tickets eingesetzt, jedoch nicht für die eigentliche Exploration der Produktvision. Was dazu führt, dass viel Wissen verloren geht, bzw. im Team gar nicht vorhanden ist. Marty Cagan hat einmal gesagt: „Wer seine Software-Entwickler nur zum Schreiben von Software einsetzt, nutzt nicht deren ganzes Potenzial aus.“ Und genau das macht die Feature-Factory. Doch das ist nicht der einzige Nachteil einer Feature-Factory. Durch das fehlende Wissen über das Produkt und die fehlende Teilhabe an der Discovery von neuen Produktfunktionen werden Produkte in der Feature-Factory auch sichtlich schlechter. Weil Feature-Factories oft ein „agiler“ Bestandteil einer sonst Plangetriebenen Organisation sind, steigt auch das Marktrisiko, denn es besteht die Gefahr, dass nicht explorativ entwickelt wird und somit nicht der Product-Market-Fit erreicht wird.
Die für mich größte negative Eigenschaft an der Feature-Factory ist jedoch, dass das Team nur pseudo-Scrum/pseudo Agilität macht und somit die eigentlichen Vorteile der agilen Arbeitsweise nicht kennenlernt. Die Developer werden schnell von der pseudo agilen Arbeitsweise enttäuscht und verdammen Scrum.

Das Waterscrum-Anti-Pattern

Das Waterscrum-Anti-Pattern ist ein sehr häufig anzutreffendes agiles Anti-Pattern. Es beschreibt, wie eine agile Methode bspw. Scrum in einer plangetriebenen Organisation eingesetzt wird. Dabei entsteht sehr oft eine Feature-Factory. In diesem Fall ist Scrum oft nicht der effizienteste und beste Ansatz die Arbeit umzusetzen.

Wie kann dieses Anti-Pattern verhindert werden und wie kann aus der Feature-Factory ausgebrochen werden?

Um aus der Feature-Factory auszubrechen, gibt es mehrere Ansätze, die auch kombiniert werden können.
Oft ist das Waterscrum Anti-Pattern ein Schritt in der agilen Transformation eines Unternehmens. Denn wenn die agile Transformation noch nicht abgeschlossen ist oder gerade erst in der Entwicklung gestartet wurde, kann genau dieses Antipattern bestehen. Dann ist es wichtig die agile Transformation voranzutreiben. Den Product-Owner in seiner Position zu bestärken und ihn vor allem in alle Prozessschritte vor und nach der Entwicklung mit einzubeziehen.
Um den fehlenden Fokus auf die Discovery und die fehlende explorative Vorgehensweise des Teams zu adressieren, sollten Scrum-Master und Product-Owner über die Einführung eines Dual-Tracks nachdenken.

Wenn kein voller Dual-Track eingeführt werden kann, muss zumindest die Discovery von neuen Features regelmäßig mit dem Team gemacht werden. Das Team sollte aktiv in die Discovery von neuen Features mitgenommen werden. Dazu sollte das Refinement der Tickets nicht nur ein reines abcheken der DoR und Akzeptanzkriterien sein, nein, viel mehr sollte das Team selbst die Features erkunden und gemeinsam mit dem Product Owner die Akzeptanzkriterien ausarbeiten = „Discovery“.

Um auch die anderen internen und externen Stakeholder in der agilen Entwicklung zu berücksichtigen, eignen sich agile Methoden wie OKR. OKR baut Barrieren und Schnittstellen zwischen Abteilungen ab. Teams setzten sich, bei richtig eingesetzten OKR, Ziele entlang des Value Streams und nicht pro Abteilung. Dadurch rücken die Teams enger zusammen und arbeiten gemeinsam am Value-Stream. Das wiederum schafft die Feature-Factory und das Waterscrum Antipattern ab.
Mehr dazu hier.

Doch nicht nur das richtige setzen von Zielen ist wichtig, um aus der Feature-Factory auszubrechen. Mindesten genauso wichtig ist, dass das Produkt eine gute Produktvision hat und diese Produktvision vom Product-Owner ans Team gut weitergegeben wird. Das Team und der Product-Owner müssen gemeinsam wissen warum das Produkt wichtig ist und dieses Warum gemeinsam gestalten. Nur wenn jedes Teammitglied die Vision kennt, kann auch von dieser Vision eine Produktentwicklungsstrategie abgeleitet werden. Aufgrund dieser Strategie können dann gute Sprint-Ziele erstellt werden, outcome-orientiert gearbeitet werden und so die Feature-Factory verlassen werden.

Fazit

Um die Feature-Factory zu verlassen können und sollen mehrere Methoden und Schritte in Betracht gezogen werden. Wichtig ist es das Team zu befähigen selbstständig an der Produktentwicklung mitzuarbeiten. Software-Engineers sollten viel mehr machen als nur programmieren, sie sollten vollkommen in die Produktstrategie und die Discovery mit einbezogen werden.