W-JAX Countdown mit Jens Coldewey

Kapitalvernichtung im großen Maßstab: Wenn Produkte wie Projekte behandelt werden

Jens Coldewey

Nehmen Sie sich in Ihrer Produktentwicklung auch viel Zeit für Projektmanagement? Oder finden Sie, dass Ihr Produkt im Gegenteil mehr Projektmanagement vetragen könnte? Nun, gleich welche der oberen Fragen Sie mit „Ja“ beantworten – Sie sollten weiter lesen. Denn Agile-Spezialist Jens Coldewey vertritt die Meinung, dass Produkte und Projekte grundsätzlich nicht über den gleichen Kamm geschert werden sollten. Im W-JAX-Countdown verrät er uns, was schief laufen kann, wenn Produkte wie Projekte behandelt werden.

 

JAXenter: In deinem W-JAX Talk machst du die Unterscheidung zwischen Projekten und Produkten. Was macht ein Projekt aus, und welche Unterschiede gibt es zu einem Produkt?

Jens Coldewey: Da würde ich ja gleich die Kernaussage meines Vortrags verraten! Im Vertrauen: Ein Projekt ist per Definition eine temporäre Organisation, um ein Ziel zu erreichen – in der Regel den Live-Gang bestimmter Features. James Carse bezeichnet so etwas als ein „endliches Spiel“. Das Ziel eines endlichen Spiels ist es, zu gewinnen. Dem stellt er „unendliche Spiele“ gegenüber, deren Regeln sich während des Spiels ändern. Das Ziel eines Spielers in einem unendlichen Spiel ist es, im Spiel zu bleiben. Das entspricht Produkten.

Ich stelle nun die These auf, dass es deutlich hilfreicher ist, Software-Systeme als Produkte zu sehen, also als unendliche Spiele. Eine der Erkenntnisse von Carse ist, dass man unendliche Spiele nach grundsätzlich anderen Strategien spielt, als endliche, auch wenn man innerhalb eines unendlichen Spiels durchaus mal ein endliches spielen kann.

Beispiel Sport: Ein Fußballspiel ist ein klassisches endliches Spiel. Der Aufbau einer Mannschaft wie FC Bayern oder Borussia Dortmund ist ein unendliches Spiel. Eine Mannschaft nur durch eine Abfolge von Spielen aufbauen zu wollen, funktioniert im Freizeitbereich noch ganz gut, für eine Profimannschaft machen die Spiele selbst nur einen Bruchteil ihrer Betätigung aus (und ich meine hier nicht mal die ganzen Werbeshootings).

Übertragen auf Software-Entwicklung: Ein Software-System erfordert deutlich mehr als eine Abfolge von Projekten und „ein bisschen Wartungsoverhead“. Leider ist es derzeit aber sehr modern, das Management so schmalbrüstig aufzusetzen.

JAXenter: Gibt es da nicht eine gewisse Unschärfe, also beispielsweise ein Open-Source-Projekt, das auch in einer kommerziellen Variante vermarktet werden soll? So etwa wie bei IntelliJ IDEA? Oder die freie Eclipse-Plattform und darauf aufsetzende, kommerzielle Plug-ins?

Jens Coldewey: Ich kenne offen gestanden keine erfolgreiche Open-Source-Software, die wirklich als Projekt entstanden ist. Ein Muster, das ich allerdings häufig gesehen habe, waren ambitionierte Entwickler, die eine wirklich coole erste Version einer OS-Software an den Start gebracht haben – und die dann eingeschlafen ist. Und die Eclipse-Foundation liefert genau Management-Anteile mit Produktcharakter. Ein Produkt ist eben nicht durch einen Vertriebsweg definiert, sondern dadurch, dass es Ziel des Systems ist, im Markt zu bleiben.

Ob die Anwender mit Geld zahlen, oder mit Anerkennung, ist dabei sekundär.

JAXenter: Welche Probleme treten auf, wenn die Unterscheidung zwischen Produkt und Projekt nicht berücksichtigt wird?

Jens Coldewey: Wer immer nur das nächste Spiel gewinnen will bzw. das nächste Projekt erfolgreich landen, versäumt es, sich um die Dinge zu kümmern, die man langfristig braucht, um im Spiel bzw. Markt zu bleiben. Das kann zu fachlichen Problemen führen, zum Beispiel weil ich immer nur die Features einbaue, nach denen die meisten Kunden rufen, aber jede Innovationskraft vermissen lasse. Das kann zu technischen Problemen führen, weil ich technische Schulden anhäufe, ohne mir dessen bewusst zu sein, geschweige denn über deren Tilgung nachzudenken. Und das kann zu organisatoririschen Problemen führen, weil ich das Personal immer nur pro Projekt disponiere, ihnen also keine Chance gebe, wertvolles fachliches und technisches Wissen aufzubauen.

Im Extrem ist dann jemand in 10 Projekten gleichzeitig – also in keinem wirklich -, oder man verteilt die Entwicklung freigiebig über den gesamten Erdball. In diesen Fällen kann ich keinerlei organisatorische Erfahrung aufbauen, die aber das eigentliche Kapital eines Software-Systems darstellt. Hier wird Kapitalvernichtung im großen Maßstab betrieben, während bei einem neuen Integrationserver für 5000 € rumgezickt wird, weil man ja „sparen muss“.

JAXenter: Du sprichst ja von vermeintlichen Problemen agiler Verfahren, die sich beim genauen Hinsehen als Versuche entpuppen, Projektmanagement auf Produktentwicklung anzuwenden.  Kannst du ein Beispiel nennen?

Jens Coldewey: Sehr beliebt: „Wir können kein Scrum einsetzen, weil wir für jeden Kunden einen eigenen Projektleiter haben und deshalb keinen einzelnen Product Owner benennen können.“ Ich gehöre bestimmt nicht zu denen, die Scrum als universell einsetzbares Allheilmittel ansehen, aber hier macht Scrum einen wunderbaren Job: Es zeigt, dass es offensichtlich in der gesamten Organisation niemanden gibt, der fachlich für das System verantwortlich ist und Konflikte entscheiden dürfte.

Oft versucht die Entwicklungsleitung noch zu retten, was zu retten ist, aber ohne Auftrag, und als Dank kassiert sie in der Regel die Prügel, dass „die Entwicklung mal wieder zu langsam ist“. Hier wird reines Projektmanagement gefahren, ohne Rücksicht auf gestern und morgen, und die Produkte sind in der Regel auch in einem entsprechend desolatem Zustand. Wenn ich stattdessen ein Produkt manage, das verschiedene Nutzer hat, deren Interessen untereinander und mit meiner langfristigen Strategie ausbalanciert werden müssen, habe ich ohnehin jemanden, der das managen muss, dem also das Produkt gehört. Diese Person zum „Product Owner“ zu machen, ist dann nicht mehr so schwer.

JAXenter: Wo steht im Spannungsfeld zwischen Projekt und Produkt die DevOps-Bewegung?

Jens Coldewey: Eine gute Frage! Ich denke, wenn ich ein Software-System als Produkt verstehe und den Aufbau von Entwicklungs- und Betriebs-Know-How als Kapitalaufbau verstehe, kommt die Dev-Op-Idee sehr natürlich und fügt sich nahtlos ein. Wenn ich in Entwicklungsprojekten denke und irgendwo dahinten, außerhalb meines Verantwortungsbereichs, kommen die Admins mit nervigen Vorgaben, wird das deutlich schwieriger.

JAXenter: Was rätst du Produktentwicklern, die ständig mit Projektmanagement konfrontiert werden.

Jens Coldewey: Probleme muss man dort lösen, wo sie entstehen. Hier handelt es sich um einen klaren – wenn auch derzeit sehr modischen – Managementfehler, den auch das Management erkennen und beheben muss. Die Entwickler können da nur versuchen, Transparenz zu schaffen. Dafür sollten sie aber auch die Sprache des Managements sprechen. Ein „In Scrum geht das aber anders“ wird in der Regel mit einem schulterzuckenden „Na dann machen wir halt kein Scrum“ beantwortet. Wenn ich aber mit Entscheidungsdefiziten, Kapitalaufbau und Marktstrategien argumentiere, habe ich deutlich bessere Aussichten, verstanden zu werden.

JAXenter: Vielen Dank für dieses Interview!

Jens Coldewey war Münchner Geschäftsführer der it-agile GmbH. Er praktiziert agile Verfahren seit 1998 und hat unter anderem Erfahrungen mit Crystal, Scrum, Extreme Programming und Kanban. Sein Hauptinteresse gilt heute innovativen und selbstorganisierten Unternehmensstrukturen. Er war Vorstandsmitglied der Agile Alliance Non-Profit-Organisation und hat als Sprecher und im Programmkomitee an zahlreichen internationalen Konferenzen mitgewirkt, unter anderen Agile, XP, XP Days und OOPSLA. Jens Coldewey ist Senior-Consultant der Agile Product and Project Management Practice des Cutter Consortiums, Boston, USA und arbeitet in der „Agile Enterprise Adoption Workgroup“ der Agile Alliance mit. Bis zum Jahresende befindet er sich in einem dreimonatigen Sabbatical.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.