In Episode 5 war zu lesen, warum es im Kontext von IoT nicht ausreicht, den Markt einfach nur mit irgendwelchen smarten Neuerungen zu überfluten. Stattdessen sollten wir uns darauf konzentrieren, Innovationen zu erschaffen, die einen gesellschaftlichen Mehrwert stiften. Dieser Anspruch verlangt von etablierten Unternehmen eine Horizonterweiterung, weil die dafür benötigten Geschäftsmodelle umgekrempelt werden müssen und vielmehr darauf abzielen, in partnerschaftlichen Ecosystemen zu denken.

Ein konkretes Ereignis veranlasst mich, heute etwas zum Vorgehen in IoT-Projekten zu schreiben. Kürzlich diskutierte ich mit Dirk Slama über die ignite Enterprise IoT-Methodik, die er und ein paar andere kluge Köpfe gerade entwickeln. Auch wenn wir uns beide mögen, hindert uns das selten, inhaltliche Meinungsverschiedenheiten hitzig zu diskutieren.

In unserer Diskussion habe ich mich als Verfechter agilen Gedankengutes über das Vorgehen echauffiert, welches in der ignite Enterprise IoT-Methodik beschrieben ist. Glücklicherweise hat Dirk eine sehr angenehme Art, mit inhaltlicher Kritik umzugehen. Er meinte (sinngemäß): „Dann schreib doch das, was du gerade gesagt hast, in einem Brandbrief auf. Ich nehme deine Sichtweise gerne direkt in die Methodik mit auf, so dass alle etwas davon haben.“

Und so schrieb ich folgende Brandbrief (in der englischen Fassung auch hier).

„Liebe Autoren der ignite IoT-Methodik!

Bevor ich etwas schimpfe, möchte ich euch beglückwünschen zur ersten IoT-Methodik auf dem Markt. Durch die zunehmende Bedeutung von IoT im Markt werden immer mehr Projekte dieser Art durchgeführt. Das schreit geradezu nach einer entsprechenden Methodik, die solche Projekte handhabbar macht. Das Buch wie auch die Webseite finde ich ausgesprochen gelungen!

Aber ich habe auch einen Kritikpunkt, der mir sehr am Herzen liegt. Ihr schreibt völlig zu Recht, dass wir es bei IoT-Projekten mit einem „multi-disziplinären Projektmanagement“ zu tun haben, und die Methodik habe daher den Anspruch, „verschiedene Skills und Disziplinen zu integrieren“. Jeder erfahrene Projektmanager wird mir zustimmen, dass dies allein schon als Projektrisiko eingestuft werden muss. Hinzu kommt, dass IoT-Projekte typischerweise mit (für den Durchführenden) unbekannten Technologien konfrontiert sind und daher hohe zusätzliche Risiken beherbergen. Aktuell sind IoT-Projekte demnach als hochriskant zu bewerten.

Hohe Projektrisiken sind per se nicht schlimm, im Gegenteil: Jeder Verantwortliche ist gut beraten, die Finger von Projekten zu lassen, die risikolos und damit chancenlos sind. Dennoch zielen eure Aussagen zum Vorgehen – namentlich „Plan-Build-Run“ – erkennbar vor allem auf Wasserfall ab. Fairerweise räume ich ein, dass ein paar wenige Sätze in der Methodikbeschreibung ausdrücken wollen, dass man IoT-Projekte auch agil machen könnte.

Die Plan-Build-Run-Metapher ist zwar schön einfach darstellbar, und sie ist grundsätzlich nicht falsch. Ich finde diese Vereinfachung aber brandgefährlich. Sie legt Entscheidern (mal wieder) in den Mund, man könne ein risikobehaftetes Projekt upfront durchplanen und müsse dann nur noch machen. Wenn schon eine Methodik das so empfiehlt, verwundert es mich nicht, dass Projekte immer noch so aufgesetzt werden.

Die Zusammenfassung zu Plan-Build-Run beschreibt, dass ein IoT-Projekt im Grunde wie jedes andere Projekt sei und daher aufgebaut sei aus einer initialen Planungsphase sowie einer Phase während der das initiale Release gebaut würde. Danach würde dann ausgerollt und gepflegt.

Nein, bitte nicht! Eine Phase ist sprachlich zu verstehen als ein Zeitraum. Eine Planungsphase muss vom Leser demnach verstanden werden als ein Zeitraum, in dem nur geplant wird (und nicht gebaut). Eine Buildphase wird dann verstanden als ein Zeitraum, in dem nur noch gebaut wird (und nicht mehr geplant). Ich hoffe, ihr meint das nicht so. Plan-Build-Run sind keine Phasen, sondern Disziplinen, denn in der Praxis wird geplant bis zum Ende. Und gebaut wird hoffentlich von Anfang an.

Auch agiles Vorgehen kennt Phasen. Die Phasen (also Zeiträume) eines agilen Projektes unterscheiden sich aber nicht so sehr anhand der Tätigkeiten, die darin ausgeführt werden. Stattdessen differenzieren sie sich anhand anderer Merkmale (Schwerpunkte der Ziele und Priorisierung, Art der Artefakte, Teamstruktur und Mikro-Vorgehen). Deswegen heißen die Phasen in einem agilen Vorgehen auch anders.

Und dann bin ich noch auf eine Aussage gestoßen, die mich fast verärgert: „Festpreisprojekte werden wahrscheinlich traditionell mit Wasserfall realisiert“. So eine Gleichung Festpreis = Wasserfall gießt leider Öl ins Feuer derjenigen, die immer behaupten, Festpreis und agil ginge nicht zusammen. Das ist in meinen Augen ausgemachter Nonsens, aber offenbar immer noch in den Köpfen.

Design-to-Budget ist ein völlig legitimer Anspruch. Festpreis ist jedoch keine Frage eines ausführlichen Upfront-Designs, sondern eine Frage der konsequenten Priorisierung im Projektverlauf. Genau hierfür sind agile Verfahren gemacht. Ich behaupte das glatte Gegenteil: Festpreisprojekte haben mit agilem Vorgehen eine größere Erfolgswahrscheinlichkeit als klassische Projekte!

Es mag sein, dass es immer noch viele (vor allem große) Unternehmen gibt, die nach Wasserfall vorgehen. Eine Methodik sollte aber den Anspruch haben, die Welt zu verbessern. Warum also nicht das, was schon lange Mainstream ist, hier auch zum Standard erheben? Meine wohlgemeinte Kritik ist, dass die IoT-Methodik keine Position zum Vorgehen bezieht, sondern es so darstellt, als könne man ein beliebiges Vorgehen für IoT-Projekte wählen – sollte man aber nicht, finde ich.

Agiles Vorgehen zielt vor allem darauf ab, Risiken beherrschbar zu machen und entfaltet genau dort seine Stärke – im Unbekannten und wenn mit einer hohen Änderungsdynamik zu rechnen ist (z.B. durch neue Erkenntnisse bei der Anwendung neuer Technologien). Und wo, wenn nicht bei hoch-risikobehafteten IoT-Projekten, wäre agiles Vorgehen angebrachter?

Mein Votum: macht euch stark dafür, IoT-Projekte immer agil durchzuführen. Meinetwegen könnt ihr für die Nostalgiker im Nebensatz erwähnen, dass es auch klassisch geht, ihr dies aber nicht empfehlt.

Liebe Grüße

Christian Weiss“