Agilität in der App-Entwicklung: Diese 5 Missverständnisse sollten Sie kennen

“Wir sollten unsere Projekte ab sofort agiler gestalten!” — schon mal gehört? Ob es um die Entwicklung von Software geht, um die Herstellung von Prototypen oder um die Gründung eines Startups — man kann den Eindruck bekommen, dass man heutzutage nichts mehr starten kann, ohne auf “agile Prozesse” aufzubauen.

Klingt ja alles total modern und irgendwie auch ziemlich flott und frisch, aber lassen Sie uns doch einmal einen kurzen Blick darauf werfen, was “agile Entwicklung” tatsächlich bedeutet. Denn es gibt fünf große Missverständnisse, die mir immer wieder begegnen.

Das Grundprinzip agiler Softwareentwicklung

Es existiert das “Manifest für Agile Softwareentwicklung”, das seit 2001 sozusagen den Grundpfeiler der Sache bildet. Und ohne das hier in eine Geschichtsstunde ausarten zu lassen, hilft es schon, sich dieses Manifest einmal genauer anzusehen, um einigen der fünf großen Missverständnisse auf die Schliche zu kommen. In dem Manifest steht nämlich:

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite* höher ein.

*Hier fett markiert.

Die Missverständnisse agiler Softwareentwicklung im Alltag

Ich gebe zu, dass ich dieses Manifest auch nicht auswendig kenne und wohl von den wenigsten Leuten auf der Welt erwartet wird, dass sie das ernsthaft tun. Bei der Hysterie, die aber manchmal um “richtig” und “falsch” in der agilen Entwicklung herrscht, tut es glaube ich ganz gut, wenn man es zumindest schon mal gelesen hat, um ein paar Dinge einzuordnen. Denn was da in einem fast schon weltverbesserlich-romantischen Ton geschrieben steht, wird schnell mal zum Diskussionsthema, wenn für die Entwicklung von Software größere Budgets reserviert werden und alle ein Interesse daran haben, dass für dieses Budget auch irgendwann (aka “so schnell wie möglich”) ein entsprechendes (aka “perfektes”) Ergebnis entsteht.

Fangen wir also an und zerlegen die Missverständnisse mal in ihre Einzelteile:

Missverständnis Nummer 1: “Agilität bedeutet Kontrollverlust”

“WAS??! Ein Budget von dreihunderttausend Euro und der Entwickler erklärt mir, dass ihm Verträge nicht so wichtig sind und er außerdem keinen Plan befolgen will??”

Klar, wer nennenswerte Budgets investiert, will sich möglichst sicher darüber sein, dass er dafür auch das vereinbarte Ergebnis bekommt. Und auch, wenn ich jetzt keine philosophische Abhandlung darüber verfassen will, was überhaupt wirklich sicher ist auf der Welt, kann man doch folgendes sagen:

Je weiter eine Sache in der Zukunft liegt und je komplexer die Einflüsse auf das Ergebnis sind, desto unsicherer ist es, dass es so eintritt, wie man es am ersten Tag erwartet.

Das mag eine ziemliche Kröte sein, die es zu schlucken gilt. Vor allem bei großen Investitionen, aber ich nehme an, jeder von Ihnen wird mir diesbezüglich zustimmen.

“Agile Entwicklung” bedeutet nun aber nicht, dass jeder mit den Schultern zuckt und sagt “Na, so isses halt. Gib mir die 300 Riesen und was am Ende rauskommt, das schauen wir dann mal”. Ganz im Gegenteil (obwohl es aus Entwicklersicht ganz sicher recht angenehm wäre, das so zu tun). In der agilen Entwicklung versucht man sich dieser Herausforderung so zu nähern, dass man die gesamte Projektlaufzeit in kleine, einfach kontrollierbare Etappen einteilt. Das heißt: Es besteht zwar eine Idee eines Endergebnisses, aber dieses definiert sich nicht über konkrete Features oder Designs, sondern eher darüber, was mit der Software erreicht werden soll. Am Ende einer jeden Mini-Etappe wird dann geschaut, ob man diesem gewünschten Ergebnis tatsächlich näher gekommen ist, wo es Probleme gab, wie diese gelöst werden können und was man sich für die nächste Etappe vornimmt.

Tatsächlich gibt es also eher einen Kontrollgewinn durch agile Entwicklung als einen Kontrollverlust, denn jeder Projektbeteiligte hat in sehr kurzen Zeitabschnitten immer wieder die Möglichkeit, in das Projekt einzugreifen um es im Sinne des Ergebnisses zu verbessern — nicht, um einen Plan oder einen Vertrag zu erfüllen, der längst outdated ist.

Missverständnis Nummer 2: Mit agiler Entwicklung ist das Ergebnis schneller fertig

“Ein halbes Jahr Entwicklungsarbeit?! Ich brauche das Ergebnis aber schon in drei Monaten, seid doch mal ein bisschen agiler, Leute!”

Das ist einer der Klassiker. Und ich ahne auch, woher die (falsche) Erwartung kommt, dass durch agile Entwicklung die Software schneller fertig ist. Zunächst mal klingt “agil” an sich schon irgendwie so wieselartig-flott, dass man den Eindruck gewinnen könnte, dass da nur jemand ein paar Module zusammensteckt und fertig ist die Laube. “Meine Oma ist leider nicht mehr so agil wie vor 5 Jahren noch”, sagt man ja auch, wenn die alte Dame sich nur noch im Schneckentempo fortbewegen kann. Da dauert der Weg zur Post und zurück nun auch doppelt so lange wie in ihren besten Jahren. So ähnlich wie diese Oma stellt man sich glaube ich oft agile vs. nicht-agile Softwareentwicklung vor.

Was jedoch tatsächlich stimmt (und vermutlich ebenfalls auf das Missverständnis einzahlt) ist die Tatsache, dass agile Softwareentwicklung vorsieht, in kurzen Zyklen funktionsfähige Zwischenversionen zu liefern. Das dient jedoch vor allem dazu, um wie oben beschrieben jedem Projektbeteiligten die Möglichkeit zu bieten, den aktuellen Fortschritt zu überprüfen und gegebenenfalls einzulenken. Das “fertige” Ergebnis wird dadurch nicht zwangsläufig schneller fertig.

Missverständnis Nummer 3: Agile Entwicklung bedeutet keine Planung

Planung in der klassischen Bedeutung, dass man von A bis Z tatsächlich alles festlegt, bevor man überhaupt loslegt, ist kein agiles Vorgehen. Das bedeutet allerdings nicht, dass gar nicht geplant wird. Die Art und Weise der Planung ist lediglich unterschiedlich: In der agilen Entwicklung wird kontinuierlich und von Schritt zu Schritt geplant.

Zu Beginn einigt man sich lediglich auf ein Ziel, das eine Software erfüllen soll (Beispiel: “Unsere neue Maklersoftware soll so effizient funktionieren, dass dadurch x% mehr Verkäufe erzielt werden, während y% Ressourcen im Backoffice gespart werden”).

Danach geht es darum, dass einzelne Schritte auf dieses Ziel zu getan werden und eine echte Planung immer nur den nächsten Schritt berücksichtigt. Das hat den Vorteil, dass man kontinuierlich die während des Projekts gewonnenen Erfahrungen in die künftigen Schritte einfließen lassen und so stets seinen Kurs im Sinne eines optimalen Ergebnisses korrigieren kann. 
Ein großer, umfassender Initialplan könnte das niemals leisten.

Missverständnis Nummer 4: Agil = Scrum

“Agil, das ist doch dieses Scrum, oder?”

Jein.

Der knifflige Punkt bei agiler Entwicklung ist (wie so oft im Leben) die Übertragung der theoretischen Idee ins echte Leben. Sobald Menschen aus Fleisch und Blut gemeinsam an einem Projekt arbeiten, gibt es die Herausforderung, unterschiedliche Ansprüche an das Projekt, unterschiedliche Charaktere, unterschiedliche Weisungsbefugnisse, etc. im Sinne eines objektiv betrachtet möglichst optimalen Ergebnisses unter einen Hut zu bekommen. 
Dafür sind im Laufe der Zeit Prozesse, also gewissermaßen Spielregeln entstanden, an die sich jeder Projektbeteiligte hält (beziehungsweise: halten sollte), und die regeln, dass möglichst effizient entwickelt werden kann und dass das Wesen agiler Entwicklung, das Projekt jederzeit im Sinne des bestmöglichen Ergebnisses zu beeinflussen, beibehalten wird. Im Scrum kümmert sich der sogenannte Scrum Master darum, dass diese Regeln und Prozesse eingehalten werden.

Scrum ist nun einer von vielen möglichen Prozessen, die mittlerweile existieren, und obwohl es wahrscheinlich der bekannteste Prozess ist, darf man nicht davon ausgehen, dass dies auch der beste ist. Wir bei rabbit mobile arbeiten zum Beispiel sehr viel häufiger mit dem “Kanban” Prozess, weil der zwar Scrum recht ähnlich ist, aber auch für kleinere Teams funktioniert und nicht ganz so strikten Regeln folgt. Aber welcher Prozess wofür am besten passt, hängt individuell von Projekt, Teamzusammensetzung und Arbeitskultur ab.

Missverständnis Nr. 5: “Agil” heißt: “Jeder macht, was er will”

Wenn Sie bis hierher brav mitgelesen haben, dürften Sie vermutlich schon selbst ahnen, dass das nicht richtig ist.

Agile Entwicklung sieht zwar vor, dass jeder ein maximales Maß an Freiheit und Selbstbestimmung bei der Erledigung seiner Arbeit hat (vor allem, weil man davon ausgeht, dass der Fachmann für eine bestimmte Sache diese vermutlich am besten erledigt und keinen Chef braucht, der ihm sagt, ob der Button rot oder grün gemacht werden soll).

Aber: Alle im Team sollen gerade so viel Führung erfahren wie nötig. Was auf jeden Fall immer vorhanden sein muss, ist eine klare Vision, worauf hin gearbeitet wird, die Klarheit über die nächsten, zu erreichenden Ziele, welche Einschränkungen es möglicherweise gibt und darüber, unter welchen Regeln zusammen gearbeitet wird. Darüber hinaus ist ein großes, gegenseitiges Vertrauen notwendig, aber natürlich auch eine größere Verantwortung jedes Einzelnen in Bezug auf seine Entscheidungen und Arbeitsergebnisse.

Stellen Sie sich ein Fußballspiel vor. Das Ziel vor jedem Spiel ist: Möglichst viele Tore zu schießen und möglichst wenige zu kassieren. Es gibt Regeln und Beschränkungen, an die sich jeder zu halten hat und die die Spieler “führen”. Außerdem weiß jeder Spieler, dass er selbst, aber auch die jeweils anderen zu den besten auf ihren Positionen gehören und höchstwahrscheinlich am besten wissen, was mit dem Ball zu tun ist, wenn sie ihn bekommen. Das ist das Vertrauen in das Team.

Agile Entwicklung heißt also auch, nach hervorragenden, selbstständig arbeitenden Leuten zu suchen, die bereit sind, eine Vision zu teilen und verantwortlich mitzutragen.

Fazit

Ich hoffe, ich konnte für ein wenig Klarheit sorgen, falls Sie auch an der einen oder anderen Stelle unsicher waren, was es nun mit “agiler Entwicklung” auf sich hat.

Agile Entwicklung ist nun sicher keine Allzweckwaffe für alles, was Sie nun künftig anpacken wollen. Und ja, es ist ganz bestimmt auch ein ziemliches Buzzword, das einem auf die Nerven gehen kann.

Aber agile Entwicklung kann zweifelsohne dabei helfen (und dafür ist sie gedacht), Software zu einem optimalen Ergebnis im Sinne des Kunden bzw. Nutzers zu führen und dieses trotzdem aus- und umbaufähig zu halten, um auch zukünftigen Herausforderungen gewachsen zu sein.


Tim Wiengarten ist geschäftsführender Gesellschafter der rabbit mobile GmbH, einer Agentur für die Entwicklung digitaler Businessanwendungen mit Mobile-First-Ansatz. rabbit mobile unterstützt seine Kunden von konzeptionell-strategischen Vorüberlegungen bis hin zur Realisierung und Pflege laufender Anwendungen, sowie deren Integration in eine bestehende Systemlandschaft.

Sie erreichen Tim Wiengarten hier auf Xing, hier auf LinkedIn oder:
via E-Mail:
t.wiengarten@rabbit-mobile.de
via Telefon: +49 69 256288–240