Aber agil sein und planen – passt das eigentlich zusammen? Und wie kann man beide Pole clever verbinden? Bei Ambient haben wir lange über diese Fragen nachgedacht, ausprobiert und nachgebessert. Heute haben wir ein Planungskonzept, das für uns bestens funktioniert. Welches das ist, erfahren Sie hier!
Agilität vs. Planung
Vorab möchten wir uns den Begriff der „Agilität“ im Software-Kontext einmal genauer anschauen. Agil zu arbeiten, heißt:
- Individuen und Interaktionen stehen immer vor Werkzeugen und Prozessen.
- Funktionalität kommt vor Dokumentation.
- Kommunikation und Kooperation mit Auftraggeber*innen hat Vorrang vor vertraglichen Verhandlungen.
- Reagieren auf veränderte Bedingungen ist besser als das Befolgen eines strikten Plans.
Diese vier Grundprinzipien stammen aus dem Agilen Manifest, das sich der Definition der agilen Arbeitsweise widmet. Dieses Manifest bietet einen guten Leitfaden für Software-Entwickler*innen, die effizient und ergebnisorientiert an ihren Produkten arbeiten wollen. Was es nicht ist: ein verbindlicher Plan, an den sich alle halten müssen.
Etwas konkreter wird Agilität in den 12 Grundsätzen, auf denen diese Prinzipien aufbauen:
- Stell deine Kund*innen durch eine frühe und kontinuierliche Lieferung effektiver Software zufrieden.
- Heiß Änderungen im Entwicklungsprozess willkommen – vor allem, wenn sie deinen Auftraggeber*innen Wettbewerbsvorteile einbringen.
- Stell regelmäßig neue Software bereit – am besten innerhalb von Wochen oder Monaten.
- Arbeite jeden Tag in einem Team mit Fachexpert*innen und Entwickler*innen zusammen.
- Gestalte deine Arbeitsumgebung so, dass alle Entwickler*innen und Projektbeteiligte motiviert sind, Unterstützung bekommen und Vertrauen erfahren.
- Sprich persönlich mit Teammitgliedern und Auftraggeber*innen, um einen konstanten Informationsfluss zu gewährleisten.
- Überprüf deinen Erfolg immer vor allem anhand daran, ob du eine funktionierende Software entwickelt hast.
- Versuche, ein konstantes Entwicklungstempo beizubehalten.
- Betrachte Agilität mit dem Fokus auf technische Qualität und nutzerorientiertes Design.
- Halte Arbeitsprozesse so einfach wie möglich.
- Verwalte dein Team mit den anderen Mitgliedern selbst.
- Evaluiere dein Verhalten und deinen Workflow stets und passe ihn an, wo erforderlich.
Bereits hier wird deutlich: Agilität meint nicht ein ständiges Wechseln des Kurses ohne Plan. Viel sinnvoller ist es, das Planen eines Softwareprojekts als kontinuierlichen Bestandteil der Entwicklung zu betrachten.
Warum Softwareentwicklung Planung braucht – und was passiert, wenn ein Plan zu strikt ist
Natürlich ist es gerade bei großen Softwareprojekten schwierig, Budget und Aufwand von Anfang an einzuschätzen. Oft ist es so, dass Auftraggeber*innen erst im Entwicklungsprozess bemerken, was sie (oder ihre Kund*innen) eigentlich brauchen. Features kommen hinzu, andere werden überflüssig. Das ist normal – und auch gut so.
Andernfalls würden nämlich Softwareprodukte entstehen, die zwar einen vorher gemachten Plan perfekt erfüllen, aber für den Markt nur eingeschränkt brauchbar sind. Bei der Projektplanung nach der klassischen Wasserfallmethode ist das der Fall: Hier wird zunächst ein konkreter Plan festgelegt, der auf Biegen und Brechen eingehalten werden muss. (Auch hier gibt es selbstverständlich Planabweichungen. Diese werden dann aber als Stress und „falsch“ empfunden. Es gilt dann, so schnell wie möglich wieder auf Kurs zu kommen – auch wenn der Kurs gar nicht der Richtige ist.)
Agilität bewertet Planung anders: Geplant wird zu Anfang und nach jedem Sprint, also jeder Iteration, neu und völlig anders – wenn es denn dem Projekt zukommt. Dieser Ansatz ist authentischer, gewinnbringender und zielorientierter als klassisches Projektmanagement. Warum? Ganz einfach: Wer agil plant, schaut nicht auf „künstliche“ Ziele, die vor allem der ersten Befriedigung der Auftraggeber*innen im Sinn haben. Agil zu planen, heißt vielmehr, immer das „eigentliche“ Ziel vor Augen zu haben: die perfekte Software, die genau das bietet, was der*die Nutzer*in braucht.
Das ist ein entscheidender Unterschied – der sich auch in der Qualität zeigt.
Ein Beispiel:
Firma X entwickelt eine Software, die Tieren hilft, abzunehmen (genau, alles ist möglich). Sie definiert von Anfang an ein Logbuch mit zahlreichen Features, die diese Software haben soll. Außerdem definiert sie den Aufwand, den sie für die Entwicklung braucht und damit das Budget, das der*die Auftraggeber*in investieren muss. Die Firma fängt an zu arbeiten und liefert wie versprochen ihre Software. Das Dilemma: Der*die Auftraggeber*in merkt erst bei der Abnahme: Halt! Eigentlich ist es viel sinnvoller, sich am Anfang auf Hunde zu spezialisieren. Für Firma X eine kleine Katastrophe: Denn sie haben bereits jedes Feature auf den Gesamtkosmos Tiere ausgelegt. Heißt: Sie müssen komplett neu starten, statt einzelne Elemente anzupassen. Für den*die Auftraggeber*in bedeutet das plötzlich weitaus mehr Kosten als zuvor besprochen. Und dies kann er*sie nicht nachvollziehen, weil die gewünschte Änderung aus seiner Sicht nur minimal ist. Es kommt zu Unzufriedenheit auf beiden Seiten – und das mindert Qualität.
Oder aber: Firma X hat von vornherein gut geplant, merkt aber plötzlich, dass sie den Plan nicht einhalten kann. Vielleicht gibt es Probleme mit externen Dienstleister*innen, die Technik streikt oder einige Projektmitarbeiter*innen werden an anderer Stelle gebraucht. All das ist völlig normal – führt aber zu unverhältnismäßig hohem Stress, wenn an einem strikten Plan festgehalten werden muss. Was folgt, ist schluderiges Arbeiten, das Vertuschen von Fehlern und ein unehrliches Verhältnis zu den Auftraggeber*innen. Das Ziel ist nicht mehr, eine perfekte Software zu erstellen. Jetzt gilt es, den*die Auftraggeber*in irgendwie zufriedenzustellen – auch auf Kosten der Produktqualität.
Das Gegenbeispiel:
Firma Y, die agil plant, handhabt Veränderungen anders: Als der*die Auftraggeber*in plötzlich einen Kurswechsel vorschlägt, werden die veränderten Bedingungen angenommen und schnell reagiert. Das ist vor allem darum möglich, weil hier iterativ geplant wird. Nach jedem Sprint werden Ergebnisse ausgewertet und besprochen – nicht nur im Projektteam, sondern auch mit dem*der Auftraggeber*in. Der große Vorteil liegt darin, dass diese*r sich konstant mit seinem Projekt auseinandersetzt und ihm*ihr so viel früher auffällt, dass das Produkt anders eigentlich besser funktionieren würde. Die Änderung kann also schon früh vorgenommen werden – für Auftraggeber*in und Entwickler*innen weitaus entspannter. Das Wichtigste dabei ist: die Qualität der Software steigt mit jeder Iteration.
Auch Firma Y merkt vielleicht, dass sie den vorgegebenen Plan nicht einhalten kann. Vielleicht fällt den Projektbeteiligten in Sprint 2 auf, dass ein Feature nicht sinnvoll ist oder etwas falsch geplant wurde, weil Bedingungen dafür nicht eindeutig waren. Statt diese „Fehler“ zu „vertuschen“, um einen vereinbarten Liefertermin einzuhalten, spricht Firma Y die Erkenntnisse bei dem*der Auftraggeber*in an – und kann rechtzeitig für einen Kurswechsel sorgen. Das mag heißen, dass die Projektentwicklung etwas länger dauert. Es heißt aber auch, dass die Qualität des Produkts immer auf dem bestmöglichen Level ist.
Müssen Sie als Auftraggeber*in deshalb jede Lieferverzögerung in der Softwareentwicklung einfach hinnehmen? Nein – wichtig ist nur der offene Austausch darüber, warum etwas ggf. länger dauert und wie das dem Produkt dient. Auftraggeber*innen brauchen selbstverständlich einen Plan, mit dem sie arbeiten und Budget einschätzen können. Diesen bekommen sie aber auch auf agilem Wege.
Individuelle Beratung zur Aufwandsschätzung einer Software vereinbaren
Agile Planung und Budgetierung
Damit wir unseren Auftraggeber*innen von Anfang an, einen transparenten Eindruck von den Kosten unserer Entwicklung geben können, haben sich bei uns zwei Tools bewährt. Diese wenden wir in jeder Planung an: User Story Maps und Magic Estimation.
User Story Maps
User Story Maps stehen am Anfang jedes Software-Projekts bei Ambient. Hier werden zunächst alle Tasks, die ein Features benötigt, aufgezählt. Dabei schauen wir uns die User Journey ganz genau an, um für jeden Step in der Softwarenutzung notwendige Funktionen zu definieren. Im Beispiel mit der Tier-Diät könnten das sein:
- App downloaden
- Informieren
- Einloggen
- Kalorien zählen
- Abnehmerfolg messen
- Ernährungstipps einholen
- Rezepte per E-Mail bekommen
- Über neue Tools und Empfehlungen informiert bleiben
Das sind nur einige Beispiele für mögliche Funktionen. Diese definieren wir vorab und schreiben sie auf Zettel, die wir an ein Board hängen. Aus den einzelnen User Tasks entstehen User Stories (Features, die zur Erfüllung der User Tasks gebraucht werden) – das ergibt unsere User Story Map. Diese sollte sofort strukturiert und priorisiert werden, denn nicht jedes Features ist für den*die Nutzer*in gleich wichtig.
Wichtig: Am Anfang hilft uns die User Story Map bei der Aufwandseinschätzung/Planung von Projekten. Wir gehen aber schon jetzt davon aus, dass sich im Laufe der Entwicklung einiges an der User Story Map tun wird. Zum Beispiel werden einige Features überflüssig, andere kommen hinzu. Die User Story Map gibt uns also zu Anfang eine grobe Richtung, an der wir uns während des gesamten Entwicklungsprozess orientieren – aber die wir eben auch verändern können.
Magic Estimation
Die Magic Estimation ist dazu da, zu Anfang eines Projekts schnell und niedrigschwellig dessen Aufwand einzuschätzen. Einige empfehlen deshalb, dass sie komplett ohne Worte abläuft, um ausufernde Diskussionen zu vermeiden. (Wir halten’s agil und haben den Prozess für uns so angepasst, wie er sich als effektiv erwiesen hat.) Und so läuft eine Magic Estimation bei uns:
- Jede*r Projektmitarbeiter*in schätzt für jede User Story den Entwicklungsaufwand. Wir arbeiten dabei mit Kleidergrößen: „S“ steht für wenig Aufwand, „XL“ für viel Aufwand. Seine*Ihre Einschätzung schreibt jede*r auf einen Zettel und hängt ihn zu der entsprechenden User Story an die User Story Map.
- Erste Diskussionsrunde: Wir diskutieren gemeinsam die Einschätzungen und jede*r Beteiligte kann seine Zettel nach Wunsch neu ordnen.
- Zweite Diskussionsrunde: Wir diskutieren noch einmal die neuen Ergebnisse und kommen nun zu einem Konsens.
Die Magic Estimation kann den exakten Aufwand eines Projekts in der Realität nicht bestimmen. Aber: Sie gibt uns einen groben Rahmen, mit dem wir und Auftraggeber*innen arbeiten können.
5 wichtigste Tipps zur agilen Projektplanung
Geplant wird bei Agile also nicht nur am Anfang, sondern laufend. Dabei ist auch die Art der Planung nicht starr, sondern eben agil. Wir haben allerdings 5 Tipps, die für uns unbedingt in der agilen Projektplanung Beachtung finden sollten:
- Starten Sie mit einer Produktvision
Was jedes Projekt zuallererst braucht, ist eine Produktvision. Im besten Fall kann der*die Auftraggeber*in diese schon genau formulieren. Falls nicht, gilt es diese gemeinsam zu entwickeln. Denn nur mit einer ausformulierten Produktvision, wissen alle Projektbeteiligten, was sie vorhaben, warum sie dies umsetzen wollen und was sie damit anstreben. Eine Produktvision enthält also: die Idee, die Absicht dahinter und die Motivation dazu.
Eine Produktvision für unser Beispiel könnte sein:
Wir wollen eine Tier-Diät-Software entwickeln, um Menschen zu helfen, ihre Tiere gesünder und glücklicher zu machen, und uns als Pioniere dafür zu etablieren. - Halten Sie Ihre Sprints kurz und übersichtlich
Gerade bei größeren Projekten neigt man doch dazu, einzelne Iterationen länger auszudehnen und Sprint-Reviews weiter auseinanderzulegen. Das ist aber oft nicht sinnvoll. Halten Sie einzelne Sprints so kurz, wie es sinnvoll ist, um auf Veränderungen schnell reagieren zu können und Erfahrungswerte im Laufe der Entwicklung perfekt einzubinden. - Meetings sind wichtig
Ob Sprint Retrospektive, Sprint Planning oder Daily Scrum – etablieren Sie eine Meeting-Kultur unter Ihren Entwickler*innen. Regelmäßige Meetings helfen allen Projektbeteiligten, up-to-date zu bleiben und sorgen für Austausch, Verständnis und Vertrauen. Und diese drei Elemente bilden die Basis für erfolgreiche agile Zusammenarbeit. - Planen Sie in vielen Teilschritten
Ein Grundelement von agilem Projektmanagement ist nicht nur das Arbeiten in kurzen Sprint, sondern auch das Planen in kleinen Einheiten. Je kleinteiliger Sie dabei vorgehen, umso einfacher sind Anpassungen am Plan vorzunehmen und umso verständnisvoller reagieren Entwickler*innen wie auch Auftraggeber*innen darauf. - Behalten Sie stets das Ziel vor Augen: das hochwertige Produkt
Lassen Sie sich bei der Planung nicht von Änderungen, Abweichungen und aufwändigeren Verbesserungen irritieren, sondern nehmen Sie diese als nächsten Schritt zu einem noch besseren Ergebnis an. Folgen Sie nicht einem Plan, sondern verfolgen Sie Ihr Ziel: das bestmögliche Produkt für Nutzer*innen.
" Damit wir unseren Auftraggeber*innen von Anfang an, einen transparenten Eindruck von den Kosten unserer Entwicklung geben können, haben sich bei uns zwei Tools bewährt. Diese wenden wir in jeder Planung an: User Story Maps und Magic Estimation."
Agil planen mit Ambient – so funktioniert’s
Unsere agile Planung hat sich bei uns fest etabliert – und wir freuen uns dadurch über noch größere Erfolge für unsere Auftraggeber*innen mit Software, die auf höchstem Niveau rangiert.
Haben Sie Fragen zur agilen Projektentwicklung oder suchen Sie einen kompetenten Partner für die Umsetzung Ihrer Softwarevision? Dann vereinbaren Sie jetzt einfach Ihr unverbindliches Beratungsgespräch – wir informieren Sie persönlich, transparent und auf Augenhöhe zu den Möglichkeiten für Ihr perfektes Softwareprodukt.
