Agilität, Planung und feste Termine im Handumdrehen

Es gibt viele weit verbreitete Mythen über agile Projekte. Zwei dieser Mythen besagen, dass agile Projekte keine Planung erfordern und dass man bei einem Projekt mit festem Termin nicht agil arbeiten kann. Auf der anderen Seite haben Unternehmen Kunden, die sie zufriedenstellen wollen, und müssen ihre Geschäfte führen. Und manchmal haben sie das Gefühl, dass sie planen müssen, und manchmal stehen sie vor einem festen Termin. Können wir diese Gefühle einfach vernachlässigen oder müssen wir solche Projekte aus unserer agilen Welt ausschließen? Gültige Anfragen für feste Termine oder mittelfristige Planung In meiner täglichen Praxis begegnen mir Fragen wie:

Wie viel kann bis zu einem bestimmten Datum erledigt werden? Damit wir die Schulung unserer Vertriebsmitarbeiter rechtzeitig vorbereiten können.

Wann kann diese Reihe von Funktionen für unser Produkt ausgeliefert werden? Damit unsere Kunden ihre Systeme rechtzeitig darauf vorbereiten können.

Wie viele Teams müssen an diesem Projekt arbeiten? Damit wir rechtzeitig zu dem von der Regulierungsbehörde gesetzten Termin fertig werden. Wenn wir zu langsam loslegen, wissen wir, dass es oft sehr schwer ist, den Rückstand aufzuholen und Maßnahmen wie die Verdoppelung der Kapazität zu verlangen, bevor Sie es merken.

Wann kann ich die Projektressourcen für ein anderes/nächstes Projekt planen? Damit ich weiß, ob ich zusätzliche Ressourcen einstellen muss oder nicht.

Meiner bescheidenen Meinung nach sind das berechtigte Fragen. Wenn Sie also um Aussagen zur mittelfristigen Planung bitten, können Sie diese Fragen im Hinterkopf haben und müssen nicht immer den Fortschritt kontrollieren und mikromanövrieren. Wie geht Agile mit diesem Thema um? Planung? Projekt mit festem Termin? Agil? Ja, das können wir. Bevor wir beginnen: Der Umfang ist variabel Gehen wir also davon aus, dass wir uns noch nicht in einer perfekten Welt befinden. Wir haben keinen kontinuierlichen Fluss von Änderungen, die in der Reihenfolge ihrer Priorität durchgeführt werden. Fertige Arbeitsergebnisse werden nicht direkt am Ende jeder Iteration freigegeben. Wir sprechen hier von einer projektähnlichen Umgebung, in der das Projekt eine bestimmte Menge von Anforderungen in, sagen wir, 8 Monaten liefern soll. Und die Organisation lernt gerade Agile. Bevor ich in die agile Planung und Schätzung eintauche, möchte ich den agilen Ansatz betonen: Das Lieferdatum ist fest, der Umfang ist variabel, und daher ist der Umfang Ihr primärer Lenker. Das klingt einfach, ist aber in der Praxis schwer umzusetzen. Die meisten Manager haben das Gefühl, dass ihre Projekte nur mit einer Reihe von "Must-have"-Anforderungen beginnen, die im Umfang verbleiben. Sie geben kein Geld für Spaßfunktionen aus! Ich weise immer darauf hin, dass bei früheren Projekten, wenn es hart auf hart kam, immer wieder Funktionen und Merkmale gefunden wurden, die in der ersten Version nicht enthalten waren. Lassen Sie uns diese jetzt, im Voraus, identifizieren und diese Anforderungen an das Ende unserer Planung verschieben. Lassen Sie uns zunächst eine funktionierende, minimale Version erstellen und dann damit beginnen, Funktionen hinzuzufügen, um sie für die Produktion akzeptabel zu machen. Also nicht 100 Funktionen, die zu 80% fertig sind, sondern 80 Funktionen, die zu 100% fertig sind. Auf diese Weise haben wir die Wahl, wann wir das Produkt in die Produktion geben oder ob wir noch etwas warten wollen. Details sind nicht gleichbedeutend mit Qualität Kommen wir zurück zur Planung und Schätzung. Um die magische Planung zu erstellen, muss man wissen:- Was muss getan werden? (Product Backlog)- Wie viel Arbeit wird es kosten, diese Arbeit zu erledigen? (Schätzungen) - Wie viel Arbeit können wir in einer Woche erledigen? (Geschwindigkeit) Früher haben wir eine möglichst detaillierte Projektion des Ergebnisses erstellt. Dies wird gemeinhin als Auswirkungsanalyse bezeichnet, die sowohl die geschäftlichen Anforderungen als auch eine technische Analyse umfasst. Aber Präzision ist teuer und die Wahrscheinlichkeit, dass sie falsch ist, steigt. Wir führen nun schon seit Jahrzehnten detaillierte Auswirkungsanalysen durch und es hat sich gezeigt, dass sie weder eine Garantie für den Erfolg noch für die Vorhersagbarkeit sind. Seien Sie ehrlich: Wie sieht die Erfolgsbilanz Ihres Unternehmens in Bezug auf Schätzung und Planung aus? Die Erfahrung lehrt, dass die Qualität einer leichtgewichtigen 'agilen' Schätzung und Planung mindestens so gut ist wie die der detailbasierten. Ein weitgehend vollständiges Backlog mit Hilfe von Story Maps Anstatt also Wochen und Monate in eine Vorbereitungsphase zu investieren, die zu einer detaillierten Planung führt, versuchen Sie, in Stunden oder Tagen zu denken. Stellen Sie das Product Backlog in einem eintägigen Workshop auf. Nehmen Sie sich einen weiteren Tag Zeit, um aufkommende Fragen zu beantworten. Alles, was Sie brauchen, ist ein Moderator und die richtigen Leute im Raum. Und zwar alle. Story Mapping ist eine hervorragende Methode für die effektive Erstellung des Backlogs. Sie ist leicht zu erlernen und anzuwenden und hat einen integrierten End-to-End-Prozessansatz. Aus Sicht einer ersten Einschätzung ist die Ermittlung der Breite der Anforderungen für die Genauigkeit weitaus wichtiger als die Tiefe der Funktionen. Genaue Schätzungen ohne Details Sobald Sie Ihr erstes Backlog erstellt haben, ist es Zeit für eine Schätzung. Für die erste Schätzung können Sie aus verschiedenen agilen Schätztechniken wählen. Sie können Ihr Backlog Punkt für Punkt durchgehen und jedem eine Planning-Poker-Nummer oder T-Shirt-Größe zuweisen. Bei einem größeren Auftragsbestand ist es effizienter, zunächst ähnlich große Elemente zu gruppieren und dann eine Größe pro Gruppe zuzuweisen. Das Wichtigste ist, dass Sie bei der Schätzung die richtigen Leute im Raum haben. Und zwar alle. Drucken Sie außerdem jeden Backlog-Posten aus und stellen Sie ihn an der Wand oder auf dem Tisch auf. Eine physische Darstellung des Backlogs ist weitaus effektiver als eine projizierte oder ausgedruckte Excel-Tabelle. Sie hilft wirklich dabei, Beziehungen und Ähnlichkeiten zwischen den einzelnen Punkten zu erkennen. Unabhängig davon, ob Sie ein Projekt auf agile Weise durchführen oder nicht, empfehle ich Ihnen dringend, mindestens zwei verschiedene Schätzungsmethoden anzuwenden. So würde ich neben einer auf der T-Shirt-Größe basierenden Schätzung eine zweite Schätzungsmethode verwenden, z.B. eine Experten- oder Analogieschätzung. Auf diese Weise wird die Schätzung einen Tag oder weniger dauern. Die Geschwindigkeit der Zeit Der schwierigste Schritt ist die Vorhersage der Dauer für die Fertigstellung der Arbeit. Dies hängt davon ab, wie viel Arbeit in einer Woche erledigt werden kann, also von der Geschwindigkeit. Wenn Sie noch keine historischen Daten haben, ist es bei weitem am besten, wenn Sie die Geschwindigkeit des Teams kennen. Lassen Sie sie ein paar Stories aus dem Backlog umsetzen und erfahren Sie, wie viel sie erledigen können. Wenn das nicht möglich ist, lassen Sie das Team Beispielstories unterschiedlicher Größe nehmen und sie im Detail analysieren. Anhand der Schätzungen dieser Stories können Sie die Größe Ihres gesamten Backlogs berechnen. Nutzen Sie auf jeden Fall die agile Transparenz, um Ihre angenommene Geschwindigkeit ständig zu überwachen. Berechnen Sie außerdem, wie bei der Planung der alten Schule, verschiedene Szenarien, wobei Sie von einer Reihe von Geschwindigkeiten ausgehen. Fazit: Eine genaue Planung in wenigen Tagen In diesem Artikel erfahren Sie, wie Sie eine leichtgewichtige, aber genaue Planung erstellen können. Mithilfe eines Story-Mapping-Workshops, eines Schätzungs-Workshops und einiger kluger Extrapolationen, die nur ein paar Tage Zeit kosten. Es gibt keinen Grund, von Projekten mit festen Terminen oder mittelfristigen Planungsanfragen Abstand zu nehmen. Planung ist nicht schlecht. Nutzen Sie sie, um Ihre Richtung festzulegen, aber seien Sie darauf vorbereitet, Ihren Kurs anzupassen.