Vermeiden Sie Diese 4 Agile-Fallen: Tipps für Anfänger

Erfahren Sie die 4 häufigsten Anfängerfehler im Agile-Bereich, die Sie vermeiden sollten. Basierend auf über 10 Jahren Erfahrung.

Agile ist der effizienteste Weg, Innovationen zu entwickeln

Im Vergleich zu anderen Ansätzen, einschließlich seiner direkten Gegenüberstellung, Waterfall, ermöglicht Agile die Minimierung der Zeit, die mit Formalitäten und der Erstellung vollständiger Projektdokumentationen (vor dem tatsächlichen Beginn des Projekts, was an sich ein sehr zeitaufwändiger und kostspieliger Prozess ist) verbracht wird; und maximiert die Ressourcen, die für die eigentliche Arbeit aufgewendet werden.

Es wird eine einfache Roadmap erstellt, wobei den Kernfunktionen der Anwendung Aufmerksamkeit geschenkt wird. Da Sie eine klare Vision und das Rückgrat des Produkts entwickeln, können kleinere Aufgaben flexibel angegangen und mit einer anderen (wechselnden) Priorität versehen werden.

Die Vorteile von Agile wurden weitgehend gelobt und dokumentiert, daher kennen Sie sie wahrscheinlich bereits. Es erhöht die Kundenzufriedenheit, die Bindung der Nutzer, ermöglicht es Ihnen, greifbaren Wert mit Ihrem Produkt zu schaffen, und reduziert das Risiko des Scheiterns dank schnellerer Iterationen und Reaktionen auf die Veränderungen in der Umgebung Ihrer Branche.

Schnellere Iterationen bedeuten Vorbereitung auf unerwartete Veränderungen, die auftreten können.

So definieren Sie im Grunde genommen, was zu tun ist, während Sie vorankommen, anstatt monatelang im Voraus zu planen und zu versuchen, sich auf Dinge vorzubereiten, auf die Sie sich wirklich nicht vorbereiten können (Krisen, oben erwähnte Marktveränderungen, direkte Wettbewerber, die ihr Wertangebot aktualisieren, oder praktisch alles andere, was zu Beginn des Projekts unmöglich vorhersehbar ist).

Aber… Agile ist kein Allheilmittel für all Ihre Produktentwicklungsprobleme

Wenn Sie es so wahrnehmen, könnten Sie gerade in die erste Falle und die gängigen Missverständnisse gefallen sein, die mit dem Hype verbunden sind.

Agile hat seine Werte und Prinzipien, die, wenn sie nicht befolgt werden, das Produkt zu einem Fiasko machen oder zumindest den Entwicklungsprozess erheblich behindern können.

Bei EL Passion arbeiten wir seit über 10 Jahren agil, und hier sind meine zwei Cent zu was Sie vorbereiten sollten, um die Fehler von Agile-Neulingen zu vermeiden, die für Neueinsteiger wirklich leicht zu machen sind, aber auch sehr leicht zu beseitigen, wenn man tatsächlich weiß, worauf man sich einlässt.

Falle 1: Wenn der Product Owner keine Zeit hat, der Product Owner zu sein

Ein Product Owner (PO) ist der Hauptentscheidungsfinder im Prozess, verantwortlich dafür, die Produktvision an das Entwicklungsteam zu kommunizieren, den Wert der zu entwickelnden Funktionen zu maximieren und die Backlog-Elemente so zu priorisieren, dass ein Gleichgewicht zwischen den Vorteilen für das Unternehmen und den Endbenutzern besteht.

Ein bisschen wie ein Kapitän eines Schiffes, führt er/sie die Crew, damit sie auf dem richtigen Kurs bleibt. Es ist ziemlich offensichtlich, dass, wenn der Kapitän keine Zeit hat, das Schiff zu kommandieren, die Dinge schrecklich schiefgehen können.

Ja, selbstorganisierte Teams können einigermaßen unabhängig arbeiten, aber die Prioritäten müssen festgelegt werden und jemand muss das letzte Wort haben und entscheiden, was bleibt und was geht.

Die Grundlage eines erfolgreichen digitalen Produkts ist ein Team, das die Vision versteht.

Das Fehlen der Präsenz des PO im Projekt birgt ein kostspieliges Risiko. Das Team hat keine Verbindung zur Produktvision oder zur Perspektive des Endbenutzers und könnte Zeit damit verbringen, Funktionen zu entwickeln, die für den Kunden weniger wichtig sind oder sie anders zu gestalten, als der Kunde sie sich vorgestellt hat.

Beide Szenarien sind kurz gesagt nicht nur eine Zeitverschwendung für alle, sondern auch eine sehr schmerzhafte Verschwendung des Budgets.

Die Lösung ist, wie immer, in der Theorie einfach und in der Praxis viel schwieriger umzusetzen (insbesondere für Menschen, die nicht daran gewöhnt sind, in Agile-Umgebungen zu arbeiten). Der PO muss sicherstellen, dass er/sie in der Lage ist, etwa 1–2 Stunden pro Tag für das Projekt zu widmen (es kann in der ersten Woche nach Projektbeginn etwas mehr sein).

Falle 2: Nicht verstehen, wofür Sie in einem Time & Materials-Vertrag bezahlen

Es gibt ein sehr verbreitetes Missverständnis, dass man beim Arbeiten mit einem Softwareentwicklungsunternehmen für die Funktionen bezahlt, die geliefert werden. Aber das ist im Agile-Umfeld und dem damit häufig verbundenen Time & Materials-Vertrag nicht der Fall.

Der Kern des Time & Materials-Vertrags ist, dass Sie für die Zeit des engagierten Teams bezahlen, genau wie wenn Sie Mitarbeiter intern einstellen. Die Funktionen, die sie erstellen, sind natürlich ein greifbares Ergebnis ihrer Arbeit, und Sie können sie in Echtzeit sehen, während die Arbeit voranschreitet. Aber dennoch werden Sie für die Stunden abgerechnet, nicht für das Endergebnis.

Dieses Missverständnis führt manchmal zu ernsthaften Missverständnissen und kann in extremen Fällen das Projekt gefährden.

Lösung: Seien Sie sich bewusst, wofür Sie wirklich bezahlen, und dass in jedem Fall, in dem Sie mehr Zeit des Teams benötigen, dies abrechenbare Zeit sein wird, selbst wenn es bedeutet, an den bereits abgeschlossenen Funktionen zu arbeiten. Sie können auch einen kleinen Puffer Ihres Budgets für die abgeschlossenen Aufgaben für kleine Korrekturen und Verbesserungen reservieren. Wenn Sie Erwartungen an irgendwelche Arten von Garantien haben, sprechen Sie so schnell wie möglich mit Ihrem Partner, idealerweise bevor die Zusammenarbeit beginnt, da dies eine völlig andere Einrichtung erfordern könnte.

Ein Time and Materials-Vertrag ist tatsächlich der effizienteste Weg, um den Fortschritt reibungslos zu messen.

Falle 3: Verzögerung der Veröffentlichung der Anwendung

Kontinuierliche Lieferung steht im Mittelpunkt des agilen Ansatzes. Sie möchten Ihre App so schnell wie möglich auf den Markt bringen, selbst mit einer begrenzten Anzahl von Funktionen, selbst in einer unvollkommenen Form, damit Sie eine gute Grundlage zum Aufbau haben, aber die App bereits draußen ist.

Angenommen, Ihre Produktidee ist umfangreich, und die Entwicklung des vollständigen Umfangs würde etwa 10 Monate in Anspruch nehmen. Das Agile wäre, die Arbeit in kleinere Teile zu unterteilen, die Funktionen zu priorisieren und die App eher früher als später zu veröffentlichen.

Warum? Mit Ihrer App bereits auf dem Markt erhalten Sie Zugang zu echtem Nutzerfeedback, ohne dass Benutzertests erforderlich sind, und können die weitere Entwicklung basierend auf diesem Feedback steuern. Auf der geschäftlichen Seite können Sie früher mit dem Aufbau Ihres Wettbewerbsvorteils beginnen und natürlich auch früher mit der Kapitalisierung Ihrer Investition. Eine Sache, die Sie sich merken sollten:

Softwareentwicklung ist kein abgeschlossener Prozess. Vielmehr ist es eine kontinuierliche Verbesserung dessen, was bereits getan wurde.

Das direkte Risiko, die „MVP-Denkweise“ zu vergessen, besteht darin, die ursprüngliche Veröffentlichung der App zu verlängern und das Budget zu verbrennen, um alles bis zur Perfektion zu polieren. Die Realität der Arbeit mit digitalen Produkten hat mich viele Male gelehrt und daran erinnert, dass man nicht auf kaltem, hartem Boden lernen kann, zu schwimmen. Man muss einfach springen.

Lösung? Verkomplizieren Sie den bereits komplizierten Prozess nicht.

Wählen Sie eine einfache Lösung und bauen Sie darauf auf. Behalten Sie die Denkweise und Disziplin bei, die Anwendung so schnell wie möglich zu veröffentlichen, auch wenn das einige Kompromisse bedeutet. Ihr Softwareentwicklungspartner ist da, um Sie über die beste Technologie zu beraten, mit allen Vor- und Nachteilen der weiteren Entwicklung und deren Erweiterung gemäß Ihrem Geschäftsplan.

Wie Pamela Zave es ausdrückt: „Der Zweck der Softwaretechnik besteht darin, Komplexität zu kontrollieren, nicht sie zu schaffen.“

Falle 4: Sich auf die ursprüngliche Schätzung verlassen, während sich der Umfang erheblich ändert 🤔

Die ursprüngliche Schätzung wird erstellt, um Ihnen eine grobe Vorstellung davon zu geben, wie viel Zeit und Geld benötigt wird, um das Projekt abzuschließen.

Sie basiert auf dem Verständnis des Umfangs der Arbeiten, das vor dem Projektstart besteht. Bei EL Passion geschieht dies oft nach einem Product Design Workshop. Aber dieser Umfang der Arbeiten kann sich während der tatsächlichen Entwicklung ändern.
Neue Funktionen könnten angefordert werden, der ursprünglich besprochene Umfang wird spezifiziert oder geändert, einige Funktionen werden gestrichen oder neu priorisiert. All diese Dinge beeinflussen die Zeit und das Budget.

Sie müssen sich bewusst sein, dass eine Änderung des Umfangs zwei Dinge bedeuten kann. Entweder ändert sich der Endpreis und das Enddatum des Projekts, oder Sie müssen einige der Elemente der ursprünglichen Schätzung streichen, bevor das Budget aufgebraucht ist.

Der Schlüssel hier ist das Bewusstsein und die Erkenntnis, dass Änderungen im Projekt ganz natürlich die gesamte Entwicklungszeit und den Preis beeinflussen.

Und die Lösung: Während das Projekt voranschreitet und sich ändert, sollten Sie sich immer weniger auf die ursprüngliche Schätzung verlassen — es ist viel besser, Ihre Denkweise auf die laufenden Prognosen basierend auf der Teamgeschwindigkeit und der verbleibenden geplanten Arbeit umzustellen. Wann immer Sie an eine Änderung denken — sprechen Sie mit Ihrem Entwicklungsteam darüber, wie Sie die benötigte Änderung angehen können, damit Sie auf derselben Seite sind, was die Auswirkungen betrifft, die sie mit sich bringt.

Die Falle ist nicht Agile selbst, sondern der Missbrauch von Agile

Agile hat die Art und Weise revolutioniert, wie wir Software produzieren. Es wurde von den Größten der Branche gelobt und seine Ergebnisse dokumentiert. Es funktioniert, und es kann auch Wunder für Ihr Produkt wirken. Aber nur, wenn es von Herzen und bewusst angewendet wird, mit Respekt für seine Werte und Prinzipien.

Die Fallen, die ich erwähnt habe, sind häufig bei den sogenannten Agile-Neulingen, die vom Hype getrieben werden, aber oft nicht gut genug informiert sind.

Aber jetzt, da Sie sie kennen, was hält Sie noch auf?

Schau dir auch an

1. Häufige Fehler, die du beim Entwickeln deiner App vermeiden solltest, um die Dos und Don'ts beim Entwickeln deiner App zu sehen
2. Wann du eine Agentur für deine Softwareentwicklung beauftragen solltest einige Fragen, die du dir stellen solltest, wenn du dir nicht sicher bist, ob IT-Outsourcing der richtige Weg für dich ist