#noprojects – The end of all software projects

Heute geht es um ein Thema, das uns bei Kunden aktuell sehr beschäftigt. Die agile Entwicklung entfernt sich immer mehr vom traditionellen Projektvorgehen. Ein weiterer Trend, der in diese Richtung geht ist ein Entwicklungsmodell namens #noprojects.

Softwareprojekte scheitern häufig. Die Gründe dafür sind vielfältig. Die Begründer der #noprojects Theorie um Allen Kelly sehen den Hauptgrund in dem Umstand, dass das Vorgehensmodell eines klassischen Projektes ungeeignet ist, um funktionierende Software zu entwickeln. 

Stattdessen schlägt er eine gezielte Art des kontinuierlichen Produktmanagements vor, bei der nicht auf ein Projekt, sondern auf ein Produkt fokussiert wird.

Seine Argumentation ist interessant: Unternehmen entwickeln in einer digitalen Welt Software. Wenn das Geschäft wächst, muss auch die Software wachsen. In der digitalen Welt sind sowohl Software als auch das Business kontinuierlichen Änderungen unterworfen. Dies spiegelt die klassische Projektdefinition allerdings nicht wider, da Projekte, per Definition, endlich sind.
Es braucht also ein neues Entwicklungsvorgehen.

#noprojects vs projects

Die Idee von #noprojects geht in die selbe Richtung wie die der agilen Frameworks. Sie gehen weg vom Softwareprojekt hin zum Value Stream. 

Die angeführten Gründe, weshalb das Modell eines Projekts schlichtweg nicht zur Softwareentwicklung passt, sind folgende:

• Projekte haben Enddaten – erfolgreiche Software endet nicht, sie ist nicht vorübergehend. Fertige Software ist tote Software, Software, die nicht verwendet wird und sich nicht ändert.
• Erfolgreiche Software wird kontinuierlich weiterentwickelt und verbessert, das Team ist nicht vorübergehend, es besteht weiterhin (obwohl sich die Zusammensetzung und Größe ändern kann).
• Ressourcen ändern sich. Menschen entscheiden sich die Organisation zu verlassen oder die Organisation entscheidet sich dazu Menschen zu entfernen bzw. hinzufügen. 
• Das Projektmodell verlangt, dass wir definieren können, was zu tun ist, bevor wir beginnen. Außerdem soll sich der definierte Inhalt nicht mehr ändern. Die Softwareentwicklung hingegen, deckt ständig neue Inhalte während des Verlaufs auf.
• Das Projektdenken impliziert, dass das Problem vor der Lösung unabhängig definiert werden kann: In der Softwareentwicklung kann die Erstellung einer (Teillösung) zu einer Neudefinition des angesprochenen Problems führen.

Diese Punkte könnten ausreichen, um Sie davon zu überzeugen, dass das Projektmodell nicht für die Softwareentwicklung geeignet ist. #noprojects geht hier noch weiter. Es besagt, dass Projekte die Softwareentwicklung aktiv schädigt und Geschäftswert zerstört.

• Die Projekterfolgskriterien sind „Pünktlichkeit, Budget, Umfang“ und nicht der geschäftliche Wert. Diese Kriterien werden zu einer Ablenkung und einem Hindernis. Die Arbeit sollte wertorientiert sein und nach dem Wert / der Fähigkeit / dem Nutzen / beurteilt werden, anstatt nach willkürlichen Kriterien, die eines Tages in der Vergangenheit gut erschienen.
• Warum ein performantes Team auflösen, nur weil ein Projekt beendet wurde? Warum ein Projekt starten, indem Sie ein neues Team zusammenstellen, das noch nie zuvor gespielt hat?
• Das Team zu zerstören zerstört Wissen. Wissen hat Wert! Wissen existiert in Köpfen, nicht in Dokumenten.
• Projektdenken führt zu Kurzfristigkeit – insbesondere in Bezug auf Qualität, Produktivität und Teams. Projektdenken baut Fertighäuser, auch wenn für die Ewigkeit gebaut werden sollte.
• Man sollte die Mitarbeiter einbeziehen. Sie „besitzen“ die Arbeit und kennen sie am besten, es ist ihr täglich Brot. Der Value Stream sollte versuchen, sich im Rahmen seiner täglichen Arbeit zu verbessern.
• Projektdenken macht line tasks zu Schimpfwörtern. Line tasks sind aber keine schmutzige Arbeit, Line tasks sind der Ort, an dem Wert erzeugt wird: Wenn es sich lohnt etwas zu tun, sollte man mehr davon tun. Wenn es sich nicht lohnt, sollten diese Tätigkeiten geschlossen werden. Verwenden Sie das Portfoliomanagement.
• Projekte fassen viel Arbeit zusammen und versuchen, alles als eine große Einheit zu verwalten. Dies ist ineffizient (Software weist Skaleneffekte auf, siehe Bild unten), unterbricht den Fluss und verzögert die Lieferung, was die Wertrealisierung verzögert.
• Kontinuierliche Verbesserung ist kontinuierlich! Projekte stoppen die Kontinuität, Projekte unterbrechen den Fluss und verringern die Effektivität. Kontinuierliche Verbesserungen sollten Teil der täglichen Arbeit sein und bei Bedarf von Technologien unterstützt werden.
• Projektdenken erstellt Planungsprojekte a la „Projekt B nach Abschluss von Projekt A, doch was passiert wenn A zu spät kommt….?“. Definiere besser Value Streams und führe ihnen Arbeit zu.
• Projekte beschränken Änderungen auf Projekte und frieren Änderungen an anderer Stelle ein.
• Projekte behindern sich gegenseitig erzeugen Steuerungsaufwand.
• Anlaufkosten: Bürokratie, Verwaltung usw. beim Starten eines Projekts bedeuten, dass das Projektmodell teuer ist und nur langsam Maßnahmen ergreift. Die Kosten, die die Einrichtung von Projekten erzeugen, beeinträchtigen den Wert und die Zeit, die zum „Starten“ eines Projekts benötigt wird. Sie beeinträchtigen auch die Reaktionsfähigkeit. Bei geringem Arbeitsaufwand können die Kosten für die Erstellung eines Projekts unverhältnismäßig hoch sein, was die Attraktivität der Arbeit beeinträchtigen kann. In ähnlicher Weise bildet die Zeit, die benötigt wird, um ein Projekt zu planen, ein Team zusammenzustellen, alles zu starten, durchzuführen und zu liefern, ein Hindernis für die Wertschöpfung.
• Projekte adressieren einen statischen Bedarf.
• Schätzungen können nützlich sein – aber nicht genau.

Viele „Projekte“ die wir sehen, entsprechen nicht der oben genannten Definitionen. Das macht es aber nicht besser. Im Gegenteil, wir beobachten aktionistische Handlungen bei intransparenten Rahmenbedingungen. Die aufgeführten Probleme werden dann häufig in die Arbeit transportiert, die sonst frei von Ihnen wäre.

Die Skalierung von agilen Projekten ist ebenfalls ein Problem. 

Wenn Sie stattdessen stehende Teams akzeptieren, die sich der Verbesserung des normalen Geschäftsbetriebs widmen, verschwinden viele der Skalierungsprobleme einfach.

Projekte sind in dieser Welt lediglich Buchungsnummern, auf die die Arbeitszeit zurückgerechnet werden kann. Projekte sind dann für Buchhalter. Dort gehören sie dann hin.

Fokus auf Outcome

Die Verteilung von Mehrwert in einem Projekt ist weder gleichförmig noch Linear verteilt. Der Unterschied zwischen den Features ist gravierend und eine Umsetzung aller nicht sinnvoll. Allerdings ist das Aufsetzen eines Projektes und der Steuerung für nur 10 Prozent der Requirements eine ebenfalls aufwändige Variante. Einen kontinuierlichen Value Stream zu haben, der immer läuft und lieferfähig ist, ist das, was #noprojects vorschlägt.

Frag nicht, “Wann ist es fertig?”. Frag lieber “Wann fangen wir an, Wert zu liefern?”.

Fazit:

Das Projekte nicht der ideale Weg sind, um Software zu entwickeln, hat zu der Erstellung des Agilen Manifests und zu den agilen Entwicklungsmethoden geführt. Diese stellen eine geeignetere Vorgehensweise dar. Allerdings bilden sie noch nicht die Organisation dieser Entwicklungen im Unternehmen ab. Das Einbetten dieser Entwicklungen in Organisationen übernehmen die skalierenden Frameworks. SAFe, LeSS und besonders #noprojects entledigen sich den Projekten und stellen Bereiche in Value Streams auf, denen Arbeit zugeführt und Wert entnommen wird. Die Projekte werden so zu Abrechnungsnummern. Dieses Vorgehen ist für die Entwicklung von Software zur Zeit die passendste. 

Wir von Agile4You finden diese Aufstellung nach Wertströmen sehr interessant und würden uns gerne darüber mit euch austauschen. 

Hast du bereits Erfahrung mit #noprojects, agilen Frameworks und der Aufstellung nach Wertströmen? Wie hat sich diese Arbeitsweise auf deine Produktivität ausgewirkt?

#valuestream #less #safe #linetask #noprojects

Weitere Literatur zu diesem Thema findet ihr bald in unserem Shop.

Der Diskussion rund um #noprojects folgt man am besten dort, wo sie entstand, auf Twitter: https://twitter.com/hashtag/NoProjects