Keep it simple. Die Vorteile feedbackgetriebener Entwicklung

Wie entwickle ich wirklich produktive, Mehrwert bringende Software? Linus Benedict Torvald hat seine Antwort auf diese Frage vor 24 Jahren im Usenet-Posting in der Gruppe comp.os.minix (Usenet-Archiv auf google-Groups) gepostet und damit den Geburtsstein von Linux gelegt:

“… and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them ­čÖé Linus.”

Obwohl sein Projekt noch mitten in der Entwicklung steckte, bat er Gleichgesinnte, gew├╝nschte Features zu posten. Die aktive Mitarbeit und der st├Ąndige Dialog mit den Nutzern machte sein Betriebssystem zur Erfolgsgeschichte und mittlerweile ist Linux aus der Welt der Programmierung nicht mehr wegzudenken.

Auch beim Linux-Konkurrent Windows wurde dieser Ansatz, wenn auch sp├Ąt, aufgegriffen. Satya Nadella, CEO von Microsoft, pr├Ąsentierte im Januar 2015 seine neue Vision von Windows: ÔÇ×We want to move from people needing Windows to choosing Windows to loving WindowsÔÇŁ. Mit Version 10 seines Betriebssystems ist Microsoft dieser Vision ein gro├čes St├╝ck n├Ąher gekommen. Das Redmonder Unternehmen begann fr├╝h, Versionen zum Testen f├╝r die ├ľffentlichkeit freizugeben und deren Telemetriedaten wie auch Feedback aktiv in die Entwicklung von Window 10 einzubeziehen.

Entwicklung streng nach Lastenheft

Nun kann man sich fragen, ob das jemals anders war. Stellen wir uns daf├╝r folgendes Szenario vor:

Ein weltweit t├Ątiges Unternehmen plant im Rahmen eines Gro├čprojekts eine Webapplikation zur Abbildung seiner┬áProjektplanungen. Ziel ist die Erh├Âhung der Transparenz, Kommunikation und Effizienz des Unternehmens. W├Ąhrend der Planung des Gro├čprojekts herrscht gro├če Euphorie┬á├╝ber die┬áneuen M├Âglichkeiten, die die Software bieten wird.Die Projektleitung stellt innerhalb eines halben Jahres mit einem neu daf├╝r aufgebauten Team ein Lastenheft zusammen. Die darin beschriebenen Anforderungen sind detailliert spezifiziert. Nach der Ausschreibung des Projekts und einem Auswahlprozess wird die Softwareentwicklung an einen vielversprechenden Dienstleister vergeben. Die Meilensteine werden wie vereinbart erreicht, die Zwischenrechnungen verschickt und bezahlt. Das Projekt wird in time nach anderthalb Jahren Entwicklungszeit dem Auftraggeber zur Abnahme ├╝bergeben. Es gibt nur wenige Fehler, das Projekt geht online und die Schlussrechnung wird verschickt. Eine Story mit Happy-end?

Nein. Die Nutzungsrate der Software bleibt im einstelligen Bereich und die erhofften Effekte treten nicht ein. Das Projekt ist damit gescheitert. Folgende Probleme bei der Anwendung sind unter anderem denkbar:

  • Die Checkliste, die bei der Planung von Projekten durch zugehen ist, ist stark standardisiert und entspricht nur bei einem Drittel der Standorte der Realit├Ąt.
  • Die Webapplikation wird nicht akzeptiert. Es ging vorher doch auch ohne.
  • Das Unternehmen ├Ąnderte vor einem Jahr die Organisationsstruktur. Nun sind die weltweit t├Ątigen Projektplaner und -planerinnen aufgefordert, eine andere Reihenfolge bei der Planung zu ber├╝cksichtigen als vorher.

Bei diesem Entwicklungsprojekt, welches sich streng an einem vorher definierten Lastenheft orientierte, wurden zwei grundlegende ├ťberlegungen nicht beachtet:

  1. Die Nutzer der Webapplikation, d.h. die Projektplaner, waren an der Spezifikation der Anforderungen nicht beteiligt.
  2. Die Strukturen des Unternehmens sowie die Anforderungen der Nutzer an die Webapplikation ├Ąndern sich h├Ąufig. Diese hohe ├änderungsrate wurde bei der Planung und Durchf├╝hrung des Projekts nicht bedacht. Die Statistik zeigt, dass sich ca. 60 % aller Anforderungen w├Ąhrend der Softwareentwicklung ├Ąndern. Selbst f├╝r den Fall, dass konventionelle durchgef├╝hrte Projekte in time und in budget liegen, sind zum Projektende die Nutzer mit dem Ergebnis h├Ąufig nicht gl├╝cklich.

Feedbackgetriebene Entwicklung: Kommunikation erm├Âglicht den Erfolg

Hier ein m├Âgliches Gegenszenario, welches diesen beiden Punkten Beachtung schenkt:

Das beschriebene Gro├čprojekt startet mit einem Kickoff, an dem mindestens ein potentieller Nutzer aus jeder relevanten Zielgruppe der Projektplanungssoftware sowie Berater f├╝r das Requirements Engineering teilnehmen. Gemeinsam wird das Projektziel und das Vorgehen eines schrittweisen Rollouts mit mehreren Releases definiert. Die groben Anforderungen werden gesammelt, priorisiert und den Releases zugeordnet. Alle Verantwortlichen einigen sich auf ein Testvorgehen und die aktive Abgabe von Feeback. Anschlie├čend spezifizieren so genannte Feature-Teams das erste Release sehr genau. Innerhalb von drei Monaten stehen die Spezifikationen und ein Dienstleister wird mit der Umsetzung des Projekts beauftragt. Im Laufe der Entwicklung erh├Ąlt die Projektleitung regelm├Ą├čig Pr├Ąsentationen ├╝ber den Stand des Projekts und kann ├änderungen sofort einbringen. Nach weiteren drei Monaten steht die erste Version der Webapplikation. Alle Projektleiterinnen und -leiter, die sich zum Testen bereit erkl├Ąrt haben, beginnen die Software aktiv in der angedachten Rolle einzusetzen. Das Feedback wird zentral gesammelt und ausgewertet. Anhand der Analysen, planen alle Beteiligten bei dem n├Ąchsten gro├čen Projekttreffen gemeinsam die Anforderungen f├╝r das n├Ąchste Release. So k├Ânnen in der Zwischenzeit entstandene strukturelle ├änderungen des Unternehmens in die Entwicklung einflie├čen. Ihre Erfahrungen geben die Tester innerhalb der Nutzergruppe weiter. Mit diesem Informationsaustausch ├╝ber den Fortschritt und die Vorteile sorgen sie f├╝r eine stetig wachsende Akzeptanz f├╝r die neue Software. Nach zwei weiteren Releases k├Ânnen die Tester mit Hilfe von vorab erstellten, einheitlichen Unterlagen die Schulungen zur Anwendung der Projektplanungssoftware durchf├╝hren. Sie kennen die Probleme der Nutzer, wie auch den Entwicklungsverlauf und k├Ânnen so fachkundig in die Bedienung der Software einf├╝hren. Eventuelle┬áBarrieren f├╝r einen erfolgreichen Einsatz der Applikation gibt es wenige. Die neue Software kann schnellr ihre St├Ąrken ausspielen und an allen Standorten benutzt werden. So wird aus dem Projekt eine Erfolgsstory.

Der Schl├╝ssel zum┬áErfolg des Projekts in diesem Gegenszenario basiert auf der Einbindung m├Âglichst aller Stakeholder in die Planung und das Testing der Software von Beginn an. Es werden von Anfang an mehrere Releases eingeplant sowie die Feinspezifikationen erst kurz vor der tats├Ąchlichen Entwicklung der Anforderung vorgenommen. Ein fr├╝hzeitiges Rollout und mehrere Feedbackschleifen f├╝hren schlie├člich dazu, dass dieses Feedback f├╝r die Weiterentwicklung der Software genutzt werden kann. Die Webapplikation besteht aus wertvollen Elementen und bringt einen echten Mehrwert – sowohl f├╝r den einzelnen User als auch f├╝r das gesamte Unternehmen.

Urheber Beitragsbild: convisum / 123RF Lizenzfreie Bilder

Berit Kitzing

About Berit Kitzing

Berit Kitzing ist Projektleiterin bei der secu-ring GmbH. Der agile Weg hat es ihr besonders angetan. Sie ist stolz darauf, dass die agile Denk- und Arbeitsweise mittlerweile Unternehmensweit praktiziert wird. In ihrer Projektarbeit konzentriert Berit sich auf den Bereich Requirements Engineering und Projektevaluationen und ├╝bernimmt damit den Part des Product Owners. Wenn sie nicht am Schreibtisch sitzt, bewegt sie sich am liebsten drau├čen und genie├čt die Seen und W├Ąlder Brandenburgs.

3 responses on “Keep it simple. Die Vorteile feedbackgetriebener Entwicklung

  1. Berit KitzingBerit Kitzing Post author

    Hallo Olaf,

    ich habe ein bisschen recherchiert und konnte keine Beispielprojekte finden, die mit der Wasserfallmethode in Time und in Budget abgeschlossen wurden. Mein Hauptfokus in diesem Artikel lag allerdings auch st├Ąrker auf dem Erfolgsfaktor Mehrwert bringend. D.h. selbst Projekte, die finanziell und zeitlich betrachtet erfolgreich waren, k├Ânnen als gescheitert bezeichnet werden aufgrund fehlendem Mehrwert. Was n├╝tzt die Erf├╝llung eines Planes, wenn dieser Plan den realen, sich h├Ąufig ├Ąndernden Anforderungen nicht entspricht?

  2. Olaf Stichtenoth

    Vielen Dank f├╝r den guten Artikel. Eine Frage stellt sich mir allerdings. Im ersten Szenario wird die Entwicklung einer Web Applikation nach dem Wasserfallmodell beschrieben. Die Annahme ist dann, dass das Projekt in Time und in Budget durchgef├╝hrt wird. Wie wahrscheinlich ist denn diese Annahme. Gibt es Beispiele f├╝r Softwareentwicklung mittels Lasten- und Pflichtenheft, die ├╝ber den Zeitraum von mehr als einem Jahr in Time und Budget verliefen?

  3. Sascha M├Âbius

    Insbesondere Windwos 8 hat gezeigt, wie schlecht ein Produkt angenommen werden kann, wenn Feedback und umfangreiche Telemetriedaten str├Ąflich ignoriert werden. Selbst wenn das Produkt funktioniert, sto├čen grundlegende Neuerungen ohne Vorbereitung oder Einf├╝hrung durch nutzernahe Multiplikatoren meist auf Ablehnung.
    Auch wenn das zweite Verfahren umfangreicher und komplizierter klingt, spart es am Ende wirklich Nerven, Zeit und Geld bei der Einf├╝hrung, von den M├Âglichkeiten interner Verbesserungsvorschl├Ąge ganz abgesehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht ver├Âffentlicht. Erforderliche Felder sind mit * markiert.