Die Agile Softwareentwicklung ist eine moderne und gute Methode um IT Projekte umzusetzen.

In diesem Beitrag werden die Vorteile und die Nachteile dieser Entwicklungsmethodik aufgezeigt.

Einführung

Der lange Zeit beliebteste Programmier-Ansatz war (und ist zum Teil noch) die sogenannte Waterfall-Methode (Englisch für Wasserfall).

Hierbei ging man Schrittweise vor. Zum Start des Projektes wurden alle Anforderungen niedergeschrieben. Dann wurde das komplette Design erstellt (System-Design, Screen-Design, etc.). Danach wurde der komplette Code erstellt. Nach welchem dann das Testing des Systems und die anschliessende Wartung folgt.

Hierbei gibt es einige Herausforderungen in Waterfall, welche man versucht durch die Agile Softwareentwicklung zu lösen.

Einige davon sind:

1. Alle Anforderungen sind zum Start des Projektes nicht bekannt: Zum Teil wissen die Projektbeteiligten, unter welchen sich auch Nicht-IT Experten befinden, nicht welche Funktionalitäten das System haben muss.
2. Viele Anforderungen entstehen erst während des Projektes: Während des Projektes, dass heisst, nach der Entstehung der ersten Funktionalitäten wird dann klar, dass wichtige Punkte in der Planungsphase am Anfang übersehen wurden.
3. Fehlende Zeit für die Planungsphase: Um im Wasserfall-Modell Erfolg zu haben, braucht es eine ausgiebige Planungsphase. Nur so können die wichtigsten Dinge besprochen und geplant werden. Die Projektinvolvierten, wie bereits erwähnt sind darunter viele Nicht-IT Experten/ Manager/ Entscheidungsträger/ Budgetverantwortliche, etc. die eventuell nicht Lange auf den Start der Aufgabe warten wollen. Für diese, sogenannten Stakeholder, sind Funktionalitäten, zum Beispiel ein Formular auf der Software, auf welchem man Nachrichten versenden kann, wichtiger. Diese wollen “Resultate” sehen und nicht mit “uncoolen und langweiligen” Planungsphasen verbringen, welchen man niemanden in Rechnung stellen kann.
4. Grobe Fehler werden erst zum Ende des Projektes sichtbar: In vielen unzureichend geplanten Waterfall Projekten werden grobe Fehler erst zum Ende der Aufgabenstellung sichtbar, wenn bereits mehrere Monate in das Land gestrichen sind und der Abnahme-Chef auf der Kundenseite merkt, dass das Software-System gar nicht das kann, was man initial wollte.

Vorteile

Im Folgenden einige Vorteile, welche Agile mit sich bringt und mit welchen einige der bisher beschriebenen Nachteile (von Waterfall) behoben werden.

1) Programmierung kann sofort starten

Mit minimalen Anforderungen an das IT System kann das Projekt gestartet werden. Das liegt auch daran, dass der Agile Ansatz bereits davon ausgeht, dass nicht alle, oder sogar nur wenige, Anforderungen zum Beginn der Aufgabe vorhanden sind.

Erst im Zeitverlauf werden weitere Anforderungen von den Projektbeteiligten formuliert.

Würde der Kunde, in dieser Methode, zum IT Unternehmen mit Änderungswünschen, während der Entwicklungsphase kommen, dann würde das IT Unternehmen die neuen Wünsche mit Freude annehmen. Da man hiermit bereits gerechnet und und es sogar ein Bestandteil der Arbeitsweise ist.

Zwischenfazit zu diesem Punkt: Die Mitarbeiter und der Kunde sind befreit von einer “lästigen” Planungsphase und können jederzeit Änderungswünsche einbringen.

2) Resultate sind nach kurzer Zeit sichtbar und erscheinen in regelmässigen Abständen

Das Ziel bei Agile ist es unter anderem in relativ kurzen Abständen funktionierende Funktionalitäten zu lieferen.

Dies kann zum Beispiel in sogenannten Sprints geschehen (Teil des Agilen Frameworks Scrum). Hier werden Zeiteinheiten, zum Beispiel “eine Woche” oder “ein Monat”, vereinbart, nach denen Teile des Systems “fertig” sind und vom Kunden begutachtet werden können.

Zwischenfazit zu diesem Punkt: Der Kunde kann erste Resultate sehen und diese seinem eigenen Management mit gutem Gewissen weitergeben/ vorzeigen.

3) Resultate können vom Kunden und von internen Testern geprüft werden

Dadurch das immer wieder fertige Bestandteile des System zur Verfügung stehen, kann zum einen der Kunde, und zum anderen die internen Software-Tester, das Programm auf die Tauglichkeit prüfen.

Der Kunde kann relativ schnell in die laufende Entwicklung eingreifen, falls er/ sie sieht, dass es nicht ganz in die erwünschte Richtung geht.

Die Tester können durchgängig am System prüfen, ob alle Funktionalitäten richtig laufen. Auch Tester werden in der Lage sein, Fehlentwicklungen frühzeitig zu erkennen.

Zwischenfazit zu diesem Punkt: Grobe Fehlentwicklungen und dadurch entstehende unangenehme Mehrkosten (Zeit, Aufwand, Budget) für das Entwicklerteam und den Kunden können vermieden werden.

4) Änderungswünsche sind erwünscht, beziehungsweise möglich

Dieser Vorteil wurde bereits im ersten Punkt erwähnt. Zeigt jedoch einen Hauptgrund auf, warum man, in manchen Fällen, auf Agile setzen sollte.

Das IT System wird so geschrieben, dass auch neue Funktionalitäten, eingearbeitet werden können. Das Einzige was zu beachten ist, ist das neue Anforderungen erst nach Ablauf eines Sprints (d.h. einer einwöchigen oder einmonatigen Phase) begonnen werden.

Zwischenfazit zu diesem Punkt: Man muss den Kunden nicht von Änderungswünschen, während des Projektes, abhalten, welches man beim Waterfall Modell oft machen muss.

5) Alle Beteiligten sind im ständigen Kontakt

Kommunikation ist wichtig in IT Projekten. Agile fördert und verlangt das.

Beispielsweise werden tägliche Standup-Meetings für das Entwickler-Team vorgeschrieben. Hier wird täglich berichtet, welche Aufgaben gestern gemacht wurden, heute anstehen und vor welchen Herausforderungen man stand oder stehen wird.

Auch zwischen dem Entwickler-Team und dem Kunden gibt es ständigen Kontakt. Meistens jedoch zum Ende einer einwöchigen oder einmonatigen Programmier-Phase.

Zwischenfazit zu diesem Punkt: Durch ständige Kommunikation kann die Entwicklung in kurzen Schritten angepasst werden.

6) Die Aufgaben werden priorisiert

Das komplette IT Projekt wird in Teilaufgaben eingeteilt und nach deren Wichtigkeit priorisiert. Meistens sind das die schwierigsten Aufgaben, welche zudem den höchsten Mehrwert für den Kunden bringen.

Da diese Arbeiten zuerst angegangen und umgesetzt werden, hat der Kunde einen maximalen Nutzen von der Umsetzung.

Unwichtige Funktionalitäten können zum Ende der Aufgabestellung hin erledigt werden.

Zwischenfazit zu diesem Punkt: Besonders zum Start eines Projektes sind alle Augen auf die Umsetzung gerichtet und der Kunde und dessen Management wollen Resultate sehen. Der Mehrwert ist durch die Priorisierung von Anfang an sichtbar.

Nachteile dieser Methode

Es gibt jedoch auch einige Nachteile der Agilen Softwareentwicklungs-Methode. Diese werden im Folgenden aufgezeigt.

1) Nicht alle Entwickler sind zufrieden mit dieser Methode

Bei Entwicklern handelt es sich in den meisten Fällen, um Menschen, die nicht unbedingt die kommunikativsten sind. Viele Programmierer wollen ihre Ruhe haben, wenn es um das Erledigen und Umsetzen von Funktionalitäten geht.

Ständige Meetings und ständiges erklären der bisherigen Aufgaben kann “nervig” wirken. Besonders die kurzen, täglichen Meetings können anstrengend sein. Besonders wenn man nicht viel vorzuweisen hat (meistens braucht es ein paar Tage bis man etwas handfestes vorzeigen kann).

Besonders für Softwareentwickler welche lange Zeit mit der Waterfall Methode gearbeitet haben, kann Agile abschreckend wirken.

Zwischenfazit zu diesem Punkt: Agile kann zu hoher Unzufriedenheit bei den Entwicklern führen, wenn sich diese mit dieser Methode nicht gut auskennen, oder nicht damit “aufgewachsen” sind.

2) Erhöhter Testing Aufwand

In dieser Methode wird ständig gestestet. Daher braucht es einen oder mehrere zusätzliche Testing-Mitarbeiter welche die Aufgabenstellungen während der ganzen Projektphase prüfen.

Dies kann nicht zu verachtende Mehrkosten bedeuten.

Zwischenfazit zu diesem Punkt: Besonders Testing-Aufwendungen sind eher schwer bei Kunden zu verkaufen und darauf wird oftmals auch gerne verzichtet. Auch beim IT Unternehmen selbst fehlt oft der Wunsch noch mehr Personen für das Projekt abzustellen.

3) Projektkosten sind nicht gut einschätzbar

Wenn Anforderungen zum Beginn nicht einschätzbar sind, da Funktionalitäten und Projektanforderungen “On-The-Go” (während des Projektes) entstehen, dann kann ein externer Dienstleister keine genauen Kostenrahmen für die Entwicklung angeben.

Dies ist jedoch oftmals für Abteilungen eines Unternehmens, welches diese Dienstleistungen einkauft, ein Entscheidungskriterium (für oder gegen den Dienstleister; für oder gegen das Projekt; etc.).

Zwischenfazit zu diesem Punkt: Ein externer Kunde möchte in den meisten Fällen wissen, was für Investitionen während des Projektes auf diesen zukommen. Eine Entscheidungsfindung für oder gegen das IT Projekt wird daher erschwert.

4) “Zuviel” Kommunikation notwendig

Jede der Teilaufgaben muss auf “Done” (Englisch für “fertig”) gestellt werden, bevor man zur nächsten Aufgabe geht. Das bedeutet dass, unter anderem, die Endnutzer und Kunden ständig involviert und mit diesen kommuniziert werden muss.

Zeit ist jedoch, bei den meisten Kunden und besonders bei dessen Mitarbeitern, knapp. Daher kann es auch beim Kunden zu Unzufriedenheit führen. Beziehungsweise kann es zu Verzögerungen führen, da der Kunde “keine Zeit” hat, um sich mit den “internen Prozessen” des IT Unternehmens zu beschäftigen.

Zwischenfazit zu diesem Punkt: Die grosse Frage ist auch, ob sich der Kunde wirklich so sehr für Softwareentwicklung interessiert, so dass er auch die ganzen Prozess-Teile von Agile mitmacht. Dies ist in den meisten Projekten nicht der Fall.

Wann macht Agile Sinn?

Wie man sieht, Agile hat seine Vorteile und Nachteile. Wann macht diese Methodik jedoch Sinn. Hier ein paar Szenarien.

Agenturen

Agenturen arbeiten meistens mit externen Unternehmen zusammen, um für diese Web- und Softwareapplikationen zu schreiben.

Diese externen Unternehmen sind meistens durch deren Fachabteilungen vertreten, welche mit Budgets belegt sind.

Hier sind genaue Projektkostenabschätzungen oftmals notwendig, da der Entscheider bei der Fachabteilung, bei seinem Management mit genauen Zahlen argumentieren kann. Feste Preise kann man jedoch nur in der Waterfall Methode erzielen.

Gleichzeitig haben Unternehmenskunden jedoch keine Lust lange an Projekten zu planen “Das ist ja Aufgabe des IT Unternehmens” oder lange auf Resultate zu warten. Welches wiederum die Agile Methode bedingt.

Für eine Agentur ist daher eine gemischte Methode am sinnvollsten. Hierbei wird ein fixer Preis angegeben, in dem man das gesamte Projekt einschätzt. Es braucht gleichzeitig auch einen guten Vertriebsmann/ -frau, welcher aufzeigt, dass Änderungswünsche einen Mehraufwand erzeugen werden.

Intern, in der Agentur, wird dann mit Agile gearbeitet und zum Kunden hin wirkt das Projekt ein wenig wie Waterfall, da es zwar schnell Updates zu den neuesten Features gibt, der Kunde jedoch nicht ständig mit User Acceptance Testing (Endkunden-Testing und Abnahme der Funktionalitäten) und ähnlichen Agilen Praktiken beauftragt wird.

Softwareunternehmen

Softwareunternehmen erstellen IT Lösungen, welche in den meisten Fällen, in einer Art Lizenz-Modell, deren Kunden bereitgestellt werden.

Auch hier ist Waterfall die angebrachtere Methode. Oftmals besteht kein so grosser Zeitdruck, auch weil die Qualität der Funktionalitäten, die Stabilität des Systems, die Ausgereiftheit der Architektur und die Fehlerfreiheit im Vordergrund stehen und es weniger darum geht Managementstrukturen zufrieden zu stellen.

Interne Abteilungen

Abteilungen von Unternehmen arbeiten auch besser mit Waterfall (zum Beispiel interne Projekte die von den eigenen Entwicklern/ Mitarbeitern umgesetzt werden). Auch hier sind die Eigenschaften, welche im vorherigen Punkt genannt wurden, wie zum Beispiel Qualität der Funktionalitäten, etc. viel wichtiger als ein Einhalten eines Abgabetermins oder eines Budgets.

Es werden in den meisten Fällen Vollzeit-Mitarbeiter an dem Projekt arbeiten. Diese “Kosten”-Punkte/ Gehälter müssen dem Management nicht unbedingt beschrieben werden.

Ein Systemausfall ist bei kritischen Systemen, in vielen Fällen, viel schlimmer als eine ausufernde Projektzeit.

Externe Vergabe von Projekten über die Fachabteilung

Dieser Punkt geht zurück auf die Fachabteilungen welche Projekt vergeben. Hier ist meistens die Vergabe über Waterfall einfacher. Auch weil es für einen Laien, welcher in der Fachabteilung arbeitet, verständlich ist.

Besonders aus der Sicht der Fachabteilung, in Unternehmen, macht Agile wenig Sinn. Das beauftragte IT Unternehmen selbst kann dann intern diese Methode nutzen, um das Projekt umzusetzen.

Siehe auch den Punkt weiter oben “Agenturen”.

Externe Vergabe von Projekten über die IT Abteilung

Die IT Abteilung hat in vielen Fällen die Kompetenz die kundenseitigen Aufgaben in einem Agilen Projekt auszuführen. Hier kann dann Agile die richtige Wahl sein, auch weil Projektaufwendungen für einen IT Experten aus der IT Abteilung besser erkenntlich und einschätzbar sind. So können die Kosten auch ohne Waterfall im Rahmen gehalten werden.

Kernsysteme in Unternehmen

Wichtige Systeme, welche das Herz eines Unternehmens ausmachen, sollten immer im Waterfall Ansatz erstellt werden. Oder aus einem Mix aus Waterfall und Agile.

Eine allzuschnelle Entwicklung, wie es bei Agile vorgesehen ist, ist besser nicht angeraten. Auch weil solche Kernsystem über den Erfolg und Misserfolg von solchen Unternehmen entscheidend sind.

Innovative Projekte und junge Teams

Bei innovativen Projekten mit jungen Teams kann Agile die bessere Methode sein. Besonders Startups können von solchen Prozessen profitieren.

Meistens geht es jedoch einfach darum, dass sich die Methode sehr modern gibt und es alle gleichzeitig erlernen können. Es gibt in jungen Teams meistens nicht den Hang zu Waterfall. Auch weil es den meisten einfach nicht aus der Praxis bekannt ist .

Unsere Erfahrung

Softwareprojekte die langfristig Erfolg haben sollen, sollten mit Waterfall umgesetzt werden. Dabei sollten Elemente von Agile und andere Methoden (zum Beispiel Kanban, etc.) eingearbeitet werden.

Eine komplette Agile Entwicklung kann nur Sinn machen, wenn die Systeme nicht allzu kritisch sind. Dies ist oftmals der Fall bei Software für Fachabteilungen in Unternehmen. Es lässt sich beispielsweise verkraften, wenn die Personalsoftware für einen Tag ausfällt, etwas langsamer läuft oder optisch nicht so ansprechend ist.

Welche Erfahrung haben Sie gemacht? Wann macht welche Methode Sinn? Wie gehen Sie vor?

Interessante Links:

Mehr Informationen zur agilen Softwareentwicklung auf dem lise Blog

Best Practices zu dieser Art von Softwareentwicklung

Bilder: Flickr.com/ Williams/ Lips

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

In Fachartikeln und Büchern rund ums Projektmanagement sind den Ansätzen „Lean“ und „Agile“ umfangreiche Kapitel gewidmet. Beide Methoden werden oft synonym zueinander verwendet und tatsächlich weisen agile Methoden und Lean-Management durchaus grundlegende Parallelen auf. Es gibt aber auch wesentliche Unterschiede. In diesem Beitrag führen wir in die Grundlagen von Lean- und Agil-Management ein und zeigen die wichtigsten Unterschiede auf.

Lean – Konzentrieren auf das Wesentliche

Soll man das Lean-Management beschreiben, so kommt man um das Schlagwort „Waste Reduction“ nicht herum, und in der Tat stellt die Vermeidung von Ressourcenverschwendung ein wesentliches Prinzip des Lean-Managements dar. Im industriellen Umfeld sind hier z. B. Überproduktion und überhöhte Lagerbestände gemeint, die es zu vermeiden gilt; in der Softwareentwicklung das zeitraubende Task-Switching. Lean-Ansätze haben bereits in den 90er Jahren sehr an Bedeutung gewonnen.

Werkzeuge wie Just-in-Time, Kaizen und die erwähnte Vermeidung von Verschwendung haben den bis dahin in der Produktion etablierten Taylorismus immer mehr in Frage gestellt. Das vom japanischen Toyota-Konzern entwickelte Lean-Management wird in einigen Übersetzungen auch als „Schlankes Management“ bezeichnet, obwohl diese Übersetzung nicht ganz korrekt ist.

Lean Management beschreibt die Prämisse „Werte ohne Verschwendung schaffen“, wobei die Zielsetzung ist, sämtliche Wertschöpfungsaktivitäten im Produktionsprozess zu optimieren und unnötige Tätigkeiten zu vermeiden. Dabei soll das vorhandene System sowohl aus Sicht des Kunden als auch aus Sicht des Unternehmens überprüft werden: Dem Kunden soll sein Wunsch nach Verfügbarkeit, Qualität und Individualität bestmöglich erfüllt werden, gleichzeitig soll das Unternehmen profitabel arbeiten können und seine Wettbewerbsfähigkeit verbessern.

Hieraus ergeben sich Produktionsprozesse mit einer hohen Kundenorientierung, denn nur die Fokussierung auf die Erfüllung der Kundenwünsche sorgt für wirtschaftliches Arbeiten und eine hohe Effizienz. Detaillierte Prozessdefinitionen, festgelegte Verantwortlichkeiten, schnelle Reaktionen auf Fehler im Workflow sowie einfache Organisationsmethoden sorgen für stabile Arbeitsabläufe, aus denen letztendlich hochwertige Produkte entstehen.

Folgende zehn Gestaltungsansätze haben sich in den vergangenen Jahren für ein effektives Lean Management herauskristallisiert:

1. Kundenorientierung – alle Tätigkeiten werden auf den Kunden ausgerichtet
2. Geschäftsprozessoptimierung
3. Rückbesinnung auf eigene Stärken
4. Eigenverantwortung, Teamwork und Empowerment
5. Mitarbeiterführung als Service am Mitarbeiter
6. Gelebte Kundenorientierung als Firmenleitbild
7. Kulturwandel im Unternehmen
8. Offener Informationsaustausch
9. Dezentrale Strukturen
10. Fortlaufende Qualitätsverbesserung (Kontinuierlicher Verbesserungsprozess, KVP)

Aus diesen Punkten ergibt sich das ständige Streben nach Perfektion, die jedoch nie erreicht wird.

Grundlagen der agilen Methoden

Während sich das Lean-Management vorrangig in der industriellen Fertigung – namentlich in der Automobil-Industrie – durchgesetzt hat, so gewannen insbesondere in der IT-Systementwicklung agile Methoden große Bedeutung.

Diese entstanden Anfang der 90er Jahre durch die Problematik, komplexe Software-Entwicklungen mit den bis dahin verbreiteten traditionellen starren Entwicklungsprozessen wie dem Wasserfall- oder V-Modell umzusetzen. Das Ergebnis waren immer häufiger gescheiterte Projekte oder zumindest Arbeitsergebnisse, die an den festgelegten Zielen weit vorbeiführten.

So entwickelte sich eine Bewegung, die auf selbstorganisierende Teams und auf inkrementelle Vorgehensweisen setzt. Im Entwicklungsprozess werden immer wieder neue Ideen eingebracht, ursprüngliche Ideen ggf. wieder verworfen und Ziele neu gesteckt. Im Jahr 2001 haben 17 Erstunterzeichner das so genannte Agile Manifest unterzeichnet und dabei folgende Werte der Softwareentwicklung festgelegt:

• Interaktionen und Menschen stehen über Werkzeugen und Prozessen.
• Kooperation mit dem Kunden ist wichtiger als Vertragsverhandlungen.
• Reaktionen auf Veränderungen steht über dem strikten Befolgen eines Plans.
• Funktionierende Software zählt mehr als eine umfassende Dokumentation.

Mit diesem „Agile Manifest“ gelingt es bis heute, Software flexibel zu gestalten und zu entwickeln.

Eine sehr bekannte agile Methode ist Scrum. Hierbei werden die Organisation und der Ablauf eines Produktionsprozesses höher gewertet als technische Aspekte. Somit kann Scrum als agile Methode auch in anderen Branchen und Bereichen eingesetzt werden.

Bei Scrum wird ein Gesamtprojekt in einzelne Schritte, den so genannten Sprints unterteilt. Weitere zentrale Elemente sind Reflexion und gemeinsame Entscheidungsfindungen im Team, offenes Feedback sowie fortlaufende Anpassungen und Änderungen des Projektplans. Kurze planbare Intervalle – hier also die Sprints – sind bereits aus dem Lean-Management bekannt.

Sprints sind immer gleich lang und nicht wie in anderen Methoden auf eine notwendige Dauer ausgerichtet, um ein Ziel zu erreichen, sondern die nächsten zu erreichenden Ergebnisse werden so aufgeteilt, dass sie zuverlässig innerhalb eines Sprints erarbeitet werden können.

Gegenüberstellung: Lean vs. Agile

Lean-Management und agile Methoden bieten durch Schnittmengen eine Reihe von Gemeinsamkeiten, die sich – sinnvoll eingesetzt – durchaus sinnvoll ergänzen können. In beiden Philosophien spielen das Team und seine Mitglieder sowie die ständige Verbesserung von Arbeitsprozessen eine wichtige Rolle.

Es gibt Gemeinsamkeiten nicht nur bezüglich des Führungsprinzips (Kundenorientierung und eigenverantwortliche Teams), sondern auch die Gewichtung von Feedbacks, die Konzentration auf kurze Zyklen sowie die Reduktion von Komplexität. Folgende Gegenüberstellung soll dies verdeutlichen:

Orientierung

• Lean: Wertschöpfung für den Kunden
• Agil: Schnelle Befriedigung von Kundenwünschen

Standardisierung/Flexibilität

• Lean: Standardisierung und möglichst wenig Veränderungen zur Vereinfachung von Prozessen
• Agil: Flexible Herangehensweise zur schnellen Umsetzung von Änderungen

Verantwortlichkeiten

• Lean: Eigenverantwortliche Teams und einzelne Mitarbeiter
• Agil: Selbstorganisierte Teams

Komplexität

• Lean: Reduktion auf wichtige Wertschöpfungsprozesse
• Agil: Reduktion der Komplexität durch Leistungserbringung in kleinen Einheiten

Nachhaltigkeit

• Lean: Gleichmäßige Auslastung der Produktionsmittel
• Agil: Gleichmäßiges Arbeitstempo halten, ohne das Team zu überfordern

Verbesserung

• Lean: Ziel der ständigen Verbesserung (ein Optimum wird nie erreicht)
• Agil: Fortlaufender Fokus auf Exzellenz durch ein geeignetes Design

Die wesentlichen Unterschiede beider Methoden können Sie folgender Aufstellung entnehmen:

Lean

• Produktionsprozess im Fokus
• günstig auszuführen
• standardisiert
• automatisiert

Agil

• Produkt im Fokus
• günstig laufende Weiterentwicklung
• flexibel
• individuell

Fazit

Die Frage, ob nun das Lean-Verfahren oder agile Methoden für ein Unternehmen besser geeignet ist, lässt sich nur differenziert beantworten. Die Lean-Methode ist meist dann die bessere Wahl, wenn es darum geht, Kostenvorteile gegenüber den Mitbewerbern zu erzielen. Der Ansatz von „Vermeidung von Verschwendung“ hilft nicht zuletzt auch dabei, Kosten zu senken und dem Kunden dadurch einen günstigeren Preis anzubieten.

Soll hingegen ein Wettbewerbsvorteil dadurch erzielt werden, die Kundenwünsche und -bedürfnisse besser kennenzulernen und zu verstehen, um sie besser befriedigen zu können, setzt dies Prozesse voraus, mit denen Marktanalysen betrieben werden können. Mit agilen Methoden bieten sich viele Möglichkeiten, auf diese Erkenntnisse schnell zu reagieren.

Sie sehen: Keiner der beiden Ansätze ist jeweils besser oder schlechter. Essenziell wichtig ist die Erkenntnis, welche Ziele ein Unternehmen verfolgen muss, um erfolgreich am Markt bestehen zu können. Mit diesem Wissen ergibt sich der passende Weg beinahe von ganz allein.

Interessante Beiträge:
Was die beiden Ansätze unterscheidet
Eine kritische Auseinandersetzung mit dem Thema Lean und Agile

Bilder: Canva

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

Wenn Software entwickelt wird, dann nutzte man lange Zeit das sogenannte Wasserfall Modell.

Die Anforderungen wurden zum Start des Projektes komplett aufgenommen und dann wurde die komplette Anwendung umgesetzt.

Meistens hat man versucht, den Kunden so wenig wie möglich zu involvieren, da dieser meistens Änderungswünsche hat. Denn diese Veränderungen sind in den Wasserfall Umsetzungen kaum einbaubar. Das liegt an folgenden Punkten:

• 1) Der Preis: Meistens wurde ein “fester” Preis vereinbart und eine genaue Stundenzahl für die Umsetzung genannt. Änderungen innerhalb einer Umsetzungsphase würden den Aufwand jedoch überproportional steigen lassen.

Beispiel: Die Umsetzungszeit wurde für 6 Monate und 2 Wochen festgelegt. Die Stundenzahl sind 800 Stunden. Der Dienstleister plant nun alle Ressourcen (Manager, Projektleiter, Programmierer, Designer, Content Spezialisten, etc.) ein. Dabei ist jedoch auch zu beachten, dass die meisten dieser Personen in unterschiedlichen Aufgaben tätig sind und nicht nur in diesem einen Projekt.

Nach einiger Zeit merkt der Kunde jedoch: “Upps. Ich habe eine ganz wichtige Sache vergessen” oder “Erst nach den ersten Entwicklungsschritten habe ich gemerkt, dass es noch ein paar Sachen gibt die es zu berücksichtigen gilt”.

Der Dienstleister oder das Entwicklungsteam wird jedoch sagen: “Sorry, wir haben das bereits vereinbart was gemacht werden soll. Wir können die Änderungswünsche nur in der nächsten Version berücksichtigen” (Klar: Es wird sicherlich nicht genauso formuliert, sondern in einer abgeschwächten Form, aber das ist damit gemeint).

Der Abnehmer (entweder eine Kunde oder eine interne Abteilung) wird sehr unzufrieden sein. Denn, es könnte sein, dass gerade diese neuen Funktionalitäten über den Projekterfolg entscheiden.

• 2) Die Zeit: Auch der Zeitraum für die Entwicklung wird sich enorm verändern. Denn wenn, zum Beispiel, der Designer mit seiner Aufgabe fertig ist und an einem anderen Projekt arbeitet, kann er/ sie die Änderungswünsche nicht vornehmen, sondern das Team muss darauf warten, dass der Designer mit seinen derzeitigen Projekten fertig wird. Was wiederum bedeutet, dass höchstwahrscheinlich ein grosser Teil des Team mit “warten” beschäftigt sein wird.

Zum einen werden die bestehenden Teammitglieder aufgehalten und zum anderen verlängert sich der Zeitraum für die Entwicklung und natürlich auch der Preis, der exorbitant ansteigt.

Das Besondere an IT Projekten ist jedoch: Kaum jemand weiss von Anfang an, was die Anforderungen an die Software sind. In den meisten Fällen werden innerhalb der Aufgabe die Funktionalitäten klar. Und so kann es sein, dass sich die Anforderungen zum Teil zu 80 Prozent vom Start unterscheiden.

Mit den Jahren hat sich dieser Trend nur noch verstärkt. Heutzutage ist Software in den meisten Fällen relativ komplex und wird langfristig entwickelt.

Dadurch haben sich Experten aus der IT Branche Gedanken gemacht, wie man IT Projekte besser handhaben kann. “Agiles Projektmanagement” oder einfach “Agile” war der Lösungsansatz, welchen man nutzen sollte, um Softwareumsetzungen besser zu machen.

Das Manifest

Dieser Lösungsansatz wurde im “Agilen Manifest” im Jahr 2001 festgehalten.

Dabei gibt es zwölf Prinzipien welchem Agile folgt. Um es kürzer zu halten, sind die wichtigsten Punkte hier als Überschriften beschrieben:

• Die Annahme, dass sich Anforderungen während des Projektes ändern: Eine wichtige Erkenntnis ist, dass sich Anforderungen meistens ändern werden und man das dementsprechend berücksichtigen muss. Eine Versteifung auf initiale Anforderungen (z.B Wasserfall Modell) ist in vielen Fällen, wenig sinnvoll.
• Funktionierende Funktionalitäten werden stetig geliefert: Anstatt, wie beim traditionellen Projektmanagement Monate und Jahre, auf ein fertiges Produkt zu warten, werden in kurzen Abständen funktionierende Funktionalitäten geliefert. So kann auch der Kunde/ die interne Abteilung schnell gegenlenken und Resultate sehen.
• Entwickler und Kunde stehen im ständigen Austausch: Anders als bei der traditionellen Zusammenarbeit wird durch agiles Projektmanagement der ständige Austausch zwischen allen Parteien gefördert. Dass heisst, nicht nur zum Start des Projektes, sondern auch während des Projektes. Dort können dann auch Änderungswünsche besprochen werden.

Die Vorteile bei der Softwareentwicklung

Die Vorteile lassen sich relativ schnell erkennen.

Der Kunde oder Abnehmer wird viel glücklicher sein, weil er/ sie zum einen 1) ständig neue funktionierende Funktionalitäten geliefert bekommt (in Wochen oder Monatsabschnitten) und zum anderen 2) Änderungswünsche einbringen kann.

Zudem sieht solch ein Projektmanagement auch vor, dass sich die Entwicklerteams immer weiter verbessern (Punkt 12 im Agilen Manifest) und alles so einfach wie möglich zu halten.

Das Entwicklerteam wird auch glücklicher sein, da es keine Argumente mit dem Kunden beginnen muss, wie “Aber das war nicht Teil der Anforderungen” oder “das würde den Projektrahmen sprengen, lassen Sie uns das lieber in einer nächsten Phase machen”.

Herausforderungen

Agiles Projektmanagement bringt jedoch auch einige Herausforderungen mit sich.

Wie im Beitrag bereits beschrieben: Wenn sich die Anforderungen verändern, dann verändern sich auch die Zeiträume und die Kosten.

Das bedeutet also, dass man zum Beispiel die folgenden Punkte flexibel halten muss:

• Budget: Da sich die Anforderungen immer wieder ändern werden und diese vom Team auch begrüsst werden, ändert sich natürlich auch das Budget. Das Budget muss daher flexibel gehalten werden.
• Zeitrahmen: Auch der Zeitrahmen wird sich bei ständig ändernden Anforderungen immer weiter ausdehnen. Was initial mit 2 Monaten angegeben wurde, kann dadurch auch gut und gerne 4 Monate, 6 Monate oder länger dauern.

Das ist wiederum meistens schwer für den Kunden zu verstehen. Wer möchte schon gerne verstehen, dass der Preis und die Zeit flexibel bleiben müssen? Das wirkt gegenüber dem Kunden dann fast schon wie ein “Laissez-faire” Ansatz, in welchem man sich soviel Zeit wie nur möglich lassen kann und sich an der Kasse wie an einem Buffet bedienen kann.

Der Agile Ansatz kann also nur gewählt werden, wenn ein gewisses Vertrauen zwischen Anbieter und Kunde besteht und das Verständnis versteht, dass Softwareentwicklung oftmals nicht von Anfang an genau geplant werden kann.

Lösungsansatz

Um die Herausforderung zu lösen, versucht man eine Art “Mix” aus klassischem Ansatz (festes Budget, feste Anforderungen, fester Zeitplan) und Agile (flexible Anforderungen, enge Zusammenarbeit) zu nutzen.

So hat der Kunde zum einen eine grobe Richtlinie wie viel das Ganze kosten wird und weiss in etwa wann er/ sie eine fertige Lösung erhält.

Fazit

Agiles Projektmanagement kann noch viel weiter im Detail beschrieben werden. Dies sind jedoch die Hauptpunkte. Auf Spezialisierungen von Agile wie Scrum oder Kanban gehen wir hier nicht ein. Man sollte sich damit beschäftigen.

Sehr viele, unter anderem sehr erfolgreiche, Unternehmen unterschiedlichster Grösse nutzen heutzutage diesen Ansatz.

Die Grundsätze lassen sich jedoch in fast allen Projekten einsetzen, auch wenn diese nicht im IT Bereich sein sollten:

• Enge Zusammenarbeit zwischen allen Stakeholdern (Kunde, Entwickler, Projektleiter, etc.)
• Prozesse so einfach wie möglich halten
• In kurzen Abständen messbare, funktionierende Funktionalitäten liefern
• Offen sein für Veränderungen während Projekten
• Offenheit auf Seiten des Kunden das Budget und den Zeitrahmen anpassen zu lassen

Nutzen Sie Agile Methoden? Wie gehen Sie vor?
Microtool gibt eine Übersicht über diese Projektmanagement Methode
In diesem Glossar gibt es eine Definition zum Begriff agiles Projektmanagement

Bilder: Canva.com

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

Agile Softwareentwicklung ist für einige IT Projekte die richtige Wahl. Einige Unternehmen haben mit dieser Programmiermethodik grosse Wettbewerbsvorteile gegenüber ihren Konkurrenten im Markt erreichen können. In diesem Beitrag sind einige Tipps beschrieben, wie man mit agiler Softwareentwicklung erfolgreich wird.

1) Bereitschaft im Unternehmen prüfen

Schauen Sie sich Ihr Unternehmen genau an. Reden Sie mit ihren Mitarbeitern. Welche Hürden gibt es? Fragen Sie sich: Was ist Agile und wie steht es im Vergleich zu ihrem jetzigen/ früheren Ansatz da?

2) Alle ins Boot holen

Diese Entwicklungsmethodik funktioniert nur, wenn alle Beteiligten daran glauben und auch aktiv daran mitarbeiten. Das Management, die Entwickler, der Kunde, der Nutzer, mit allen diesen muss kommuniziert und dessen Nutzen klar gemacht werden.

Der Kunde sollte verstehen, welche Vorteile er hat, wenn er kleinere funktionierende Arbeitspakete erhält, welche er bereits testen kann.

Die Mitarbeiter müssen die Notwendigkeit verstehen, wie Agile zum Unternehmenserfolg beiträgt.

Interne Geschäftsabteilungen müssen verstehen, dass in dieser Methode eine enge Zusammenarbeit mit der IT Abteilung notwendig wird.

3) Langsam starten

Erfahrene Anwender von Agile können auch grosse Projekte erfolgreich umsetzen. Um solche grossen Projekte erfolgreich umzusetzen braucht es jedoch sehr viel Erfahrung. Daher sollte jedes Unternehmen, welches diesen Weg geht, klein starten und langsam immer grössere Projekte umsetzen. Dies ist wichtig um das notwendige Vertrauen zu gewinnen und Kompetenzen aufzubauen.

4) Kontinuierliches Lernen ist wichtig

Personen, welche diese Methodik anwenden, müssen sich auf eine kontinuierliche Verbesserung in den Bereichen Qualität und Kosten-Effizienz einstellen. Dass heisst, dass jede Entwicklung dokumentiert wird und sich im nachhinein angeschaut wird, was verbessert werden kann. Dieses ständige Lernen und Verbessern ist nicht nur Aufgabe der Senior Leute im Team, sondern muss von allen im Team praktiziert werden. So auch in den Bereichen Testing, Projekt Management und unter anderem auch im Budget Management.

5) Kleine, wechselnde Teams

Die übliche Basiseinheit eines Teams in dieser Methodik besteht aus kleinen Gruppen von 5 bis 9 Leuten. Die Mitglieder der Teams sollten lange genug, in der gleichen Gruppe gelassen werden, um produktiv zu werden. Jedoch auch nicht zu lange, da es Sinn macht, Mitglieder von Zeit zu Zeit in anderen Teams unterzubringen, um so Nährboden für neue Ideen zu geben. Gleichzeitig sollte man darauf acht geben, die Mitglieder nicht allzuschnell auszuwechseln, da dies verhindern könnte, dass sich hoch produktive Teams entwickeln. Lässt man die Leute zu lange in den gleichen Gruppen, dann fangen sich die Teams an auseinanderzuleben. Daher muss man ein gutes Gespür dafür bekommen, wie lange diese Gruppen zusammen arbeiten sollen.

6) Schlechte Ansätze vermeiden

Jede Entwicklung führt zur Entstehung von sogenannten Technischen Schulden (Englisch: Technical Debt) oder vereinfacht gesagt schlechten Ansätzen, in welchen einfache Lösungen, welche kurzfristig nutzvoll sind, gegenüber langfristig nutzvollen Lösungen bevorzugt wird.

In klassischen Projekten werden diese negative Ansätze oftmals ignoriert. In Agile werden diese Technischen Schulden jedoch dokumentiert, gemanaged und mit der Zeit eliminiert. Welches dann mit der Zeit zu besserem, peformanteren und einfach wartbaren Projekten führt.

7) Ist nicht für alle Projekte geeignet

Nicht alle Projekte sollten mit diesem Ansatz durchgeführt werden. Es wird immer IT Aufgaben geben, in welchen zum Beispiel mit Wasserfall oder andere IT Methodiken besser geeignet sind.

Agile ist einfach für einige Aufgaben besser gerüstet, während es für andere Aufgaben weniger geeignet ist.

8) Agile ist nicht ein einziger Ansatz

Die Entwicklungsmethodik ist eine Anzahl unterschiedlicher Ansätze für die Softwareentwicklung, welche einer gemeinsamen Philosophie unterliegen, aber sich im Detail ihrer Implementierung stark unterscheiden. Unterschiedliche Problemstellungen erfordern unterschiedliche Agile Ansätze.

Erfahrene Unternehmen können unterschiedliche Ansätze für unterschiedliche Problemstellungen nutzen, während Unternehmen welche gerade erst damit starten, mit einem einzigen Ansatz starten sollten und erst den nächsten Ansatz erlernen, wenn sie den ersten gemeistert haben.

9) Qualität hat hohe Priorität

In dieser Methodik werden zu vielen Zeitpunkten Tests durchgeführt, um die Qualität sicherzustellen. Automatisierte Tests und weitere Tests stellen sicher, dass sich im Verlauf des Projektes keine Fehler einschleichen.

Hierbei sollten alle involviert werden, vom Junior Entwickler bis hin zum erfahrensten Software-Architekten. Das Testen muss Teil der Arbeits-Routine werden.

10) Komplexen Code reduzieren

Komplizierter Code ist in den meisten Fällen langsamer, schwer zu nutzen und später auch nicht einfach ausbesserbar. Das Team kann von späteren, komplexen Re-Programmierungsaufgaben verschont werden, in dem man einfache Coding Ansätze wählt, welche schnell neu geschrieben werden können und einfach wartbar sind.

11) Gegner überzeugen

Es wird immer Gegner der Agilen Methodik geben. Besonders bei der Einführung. Daher sollte man Gegner schnell ausfindig machen und diesen die Vorteile davon nahelegen. Das Vertrauen dieser Mitarbeiter muss gewonnen werden. Denn nur so kann eine zukünftige Zusammenarbeit klappen.

12) Rosinen picken vermeiden

Agile Methodiken sind sehr systematisch. Jedes Element trägt zum Erfolg der Methodik bei. Ein weit verbreiteter Fehler in Unternehmen ist es, einige Teilbereiche anzuwenden und andere unpassende Teilbereiche zu vermeiden.

Beispielsweise nutzen manche Unternehmen das Konzept des “Sprints”, vernachlässigen gleichzeitig aber das Konzept der “Technischen Schulden”. Diese Unternehmen werden zwar schneller nutzbare Software produzieren, werden später aber mit schlechterem Code zu kämpfen haben.

Fazit

Mit Agile können Unternehmen schneller, verlässlicher und wartbarere IT Projekte umsetzen. Gleichzeitig werden gute Ansätze wie ständige Qualitätskontrollen, Dokumentation von Performance-Steigerungen, starke Programmieransätze und viele Weitere gefördert.

Anderen Methodiken wie Wasserfall werden immer noch ihre Berechtigung, in manchen Projekten, haben. Agile wird jedoch in vielen Projekten der richtige Ansatz sein.

Welche Erfahrungen haben Sie gemacht?

Interessante Beiträge:
Beiträge auf Deutsche Startups
Agile erfodert Disziplin
Erfolgsfaktoren für diese Art von Projekten

Flickr.com/ Bilder: Improve It/ Ragai/ Kovah/ Doliner

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.