In der Feature Factory werden Anforderungen am Fließband umgesetzt. Es zählt, wieviele Feature am Ende geliefert werden – nicht, ob sie tatsächlich auch wertvoll sind. Feature Factorys sind weniger gut geeignet, wenn es im innovative Produktentwicklung geht. Und sie sind auch dann mit Vorsicht zu genießen, wenn es um die Menge der gelieferten Features geht. Es ist unwahrscheinlich, dass wir in einer Feature Factory hyperproductive Teams vorfinden.
Die Grundidee der Feature Factory…
Die Grundidee der Feature Factory basiert auf das Annahme, dass es eine strikte Trennung zwischen Definition der Anforderungen und Umsetzung geben sollte. Für die Anforderungen ist dann beispielsweise der Product Owner verantwortlich, für die Umsetzung das Team. Das Ziel ist ein möglichst hoher Durchsatz (umgesetzte Features pro Zeiteinheit). Um das zu erreichen, werden die Anforderungen möglichst genau definiert, so dass es möglichst keine Rückfragen oder Missverständnisse durch die Umsetzer gibt. Am Ende nimmt der Product Owner die umgesetzten Features ab.
…klingt besser als sie ist
Dieses Vorgehen klingt zunächst plausibel, vor allem wenn man aus einer klassisch geprägten Welt kommt. Ein Fokus auf hohen Durchsatz scheint nicht so verkehrt zu sein – schließlich hatte Agilität durch schnellere Lieferung versprochen.
Tatsächlich hat die Feature Factory ein paar unangenehme Nebenwirkungen, die oft den erhofften Effekt zerstören:
- Die Entwickler verfallen in eine Bestellmentalität: „Wir haben geliefert, was bestellt wurde. Dass das unbrauchbar ist, ist nicht unser Problem. Das hättet ihr klarer aufschreiben müssen.“
- Anforderungen wasserdicht zu formulieren, funktioniert nur für sehr einfache Anwendungsfälle (z.B. Berechnung der Zahl pi). In den meisten Praxisfällen ist es schlicht nicht möglich, Anforderungen vollständig, korrekt und widersprungsfrei zu formulieren. Überspitzt lässt sich feststellen, dass ein kreatives Team immer eine Möglichkeit findet, die Anforderung formell zu erfüllen und dabei eine völlig nutzlose Lösung zu liefern.
- Hochperformante Teams (und da sprechen wir noch nicht mal von Hyperproductivity) entstehen nur, wenn das Team versteht, welches Problem es für wen löst. Die Arbeit in der Fabrik verhindert dieses Verständnis und damit die notwendige Motivation ziemlich effektiv. Wir wünschen uns durch die Feature Factory einen möglichst hohen Durchsatz und kriegen oftmals das Gegenteil.
- Wenn wir ein innovatives Produkt entwickeln wollen, liegt der Schlüssel darin, verschiedene Perspektiven und Ideen zu integrieren, auch die der Techniker. Eine strikte Trennung zwischen Anforderungsdefinierern und Umsetzern ist dabei hinderlich.
Wie geht es besser?
Die Entwickler brauchen Nähe zum zu lösenden Kundenproblem. Idealerweise haben sie direkten Kundenkontakt. Dann kann das Team die User Storys oft auch alleine schreiben und der Product Owner kann sich auf seine Kernaufgabe konzentrieren: Herausfinden, was am Wichtigsten ist (Priorisierung).
Teams, die jahrelang in der Feature Factory sozialisiert wurden, sind da vielleicht skeptisch. „Die Entwickler wollen das gar nicht.“ höre ich häufig von Product Ownern. Das mag sein. Aber Arbeit ist halt auch kein Wunschkonzert. Es geht ja nicht darum, dass man es sich in seiner Komfortzone gemütlich macht.
Es geht darum, geile Produkte zu entwickeln. Und wenn Produktverantwortliche überzeugt sind, dass das besser geht, wenn das Team an der Gestaltung partizipiert, dann finde ich das total zumutbar. Wir können und sollten dann natürlich darüber miteinander sprechen, welche Unterstützung die Beteiligten brauchen: die Erlaubnis Fehler zu machen, ggfs. Schulung und Coaching.
Tiefer einsteigen
Unsere Produktmanagement- und Product Owner-Ausbildungen helfen, Alternativen zur Feature Factory zu verstehen und anzuwenden: https://www.it-agile.de/schulungen/produktentwicklung/
Über den Autoren
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.