Umgang mit fehlgeschlagenen Sprints und Deadlines

In vielen Scrum-Büchern und -Artikeln heißt es, dass ein fehlgeschlagener Sprint (wenn das Team einige Funktionen aus dem Sprint Backlog nicht fertigstellt) nicht so schlimm ist, dass er von Zeit zu Zeit auftritt und tatsächlich nützlich sein kann, wenn das Team aus seinen Fehlern lernt und verbessert etwas in den folgenden Sprints. Und das Team sollte nicht dafür bestraft werden, dass es die Arbeit, für die es sich engagiert, nicht beendet hat.

Dies sieht aus Entwicklersicht großartig aus. Nehmen wir jedoch an, wir haben ein Softwareunternehmen namens " Scrum-Addicts LLC ", das etwas für ernsthafte Kunden entwickelt (" Money-Bags Corporation "):

1. Manager von Scrum-Addicts schlagen vor, eine Software für Money-Bags zu entwickeln
2. Sie einigen sich auf eine Liste mit Funktionen, und Money-Bags bittet um die Angabe eines Versanddatums
3. Manager von Scrum-Addicts konsultieren ihr Scrum-Team, und das Team sagt, dass es 3 Wochen dauern wird, bis alle Funktionen abgeschlossen sind
4. Der Manager von Scrum-Addicts fügt sicherheitshalber eine Woche hinzu, verspricht, die Software innerhalb eines Monats zu versenden, und unterzeichnet einen Vertrag mit Money-Bags
5. Nach 4 Sprints (Versandtermin) kann das Scrum-Team nur 80% der Funktionen bereitstellen (aufgrund von Unerfahrenheit mit dem neuen System, der Notwendigkeit, kritische Fehler in früheren Funktionen in der Produktionsumgebung zu beheben usw.).
6. Wie Scrum vorschlägt, kann das Produkt derzeit möglicherweise ausgeliefert werden, aber Money-Bags benötigt 100% der im Vertrag genannten Funktionen. Sie brechen also den Vertrag und zahlen nichts.
7. Scrum-Addicts steht kurz vor dem Bankrott, weil sie kein Geld von Money-Bags bekommen haben und die Investoren von den Ergebnissen enttäuscht waren und nicht mehr bereit sind, dem Unternehmen zu helfen.

Offensichtlich möchte kein Software-Unternehmen in den Schuhen von Scrum-Addicts sein. Was ich bei Agile und Scrum nicht verstehe, ist, wie die Teams mit der Planung und den Fristen umgehen sollten, um die oben beschriebene Situation zu vermeiden. Zusammenfassend habe ich also zwei Fragen:

Wer ist schuld?

1. Manager, weil es ihre Aufgabe ist, die richtige Planung durchzuführen
2. Das Team, weil sie sich dazu verpflichtet haben, mehr Arbeit zu leisten, als sie könnten
3. Jemand anderes

Was ist zu tun?

1. Die Manager sollten die Frist zweimal (oder dreimal) später als die Schätzung des ursprünglichen Teams verschieben.
2. Die Teammitglieder sollten ermutigt werden, alle von ihnen geleisteten Arbeiten zu verrichten, egal auf welche Weise (durch Verhängung von Strafen für fehlgeschlagene Sprints).
3. Das Team sollte Scrum fallen lassen, da es nicht zur Fristrichtlinie des Unternehmens passt
4. Wir sollten alle die Softwareentwicklung einstellen und uns einem Kloster anschließen
5. ???

Ich sehe in Ihrem Beispiel einige grundlegende Managementprobleme:

• Wenn ein Manager von Scrum-Addicts einen Vertrag mit einer "harten Frist" unterzeichnet, aber nur eine Sicherheitsmarge von 33% in einer Situation hinzufügt, in der "ein neues System involviert ist", ist das ziemlich rücksichtslos.

• Die Verfügbarkeit der Lieferung von mindestens x% der Funktionen nach einem Monat hätte verwendet werden können, um einen Vertrag auszuhandeln, bei dem der Kunde das Geld zumindest teilweise zahlt, wenn er zum Stichtag nur 80% der Funktionen erhält. Ein Alles-oder-Nichts-Vertrag ist etwas, von dem weder der Softwareanbieter noch der Kunde profitieren werden - dies bedeutet nicht nur 0 Geld für den Anbieter, sondern auch 0 Funktionen für den Kunden. Und mit einer Alles-oder-Nichts-Entwicklungsmethode wie "Waterfall" können Sie nur solche Verträge schreiben, ein agiler Ansatz bietet zusätzliche Möglichkeiten.

• Wenn man sich die Ergebnisse der ersten ein oder zwei Sprints ansieht, sollte dem Manager klar sein, dass das Team die Frist nicht einhalten kann. Daher hätte er frühere Maßnahmen ergreifen und die verbleibenden Aufgaben und Funktionen neu priorisieren oder versuchen müssen, früher mit dem Kunden erneut zu verhandeln. Beispielsweise hätte der Manager versuchen können, den Umfang einiger verbleibender Funktionen zu verkleinern, sodass das Team alle im Vertrag genannten Funktionen, jedoch jeweils in einem reduzierten Umfang, geliefert hätte.

Wenn sich herausstellt, dass eine Aufgabe länger dauert, als Sie gedacht haben, wird Sie keine Entwicklungsmethode davon abhalten. Ein agiler Ansatz wie Scrum bietet dem Management jedoch mehr Möglichkeiten, um zu kontrollieren, was in dieser Situation geschieht. Wenn sie diese Möglichkeiten nicht nutzen, ist dies eindeutig ihre Schuld, nicht die des Teams, nicht die von "Scrum" und nicht die des Kunden, weil "er Agilität nicht akzeptiert".

Eine der Wertaussagen des " Manifests für agile Softwareentwicklung " lautet:

Zusammenarbeit der Kunden bei Vertragsverhandlungen

Die Tatsache, dass Scrum-Addicts LLC einen Vertrag ausgehandelt hat, anstatt eine Zusammenarbeit mit einem Kunden herzustellen, lässt mich ihre Beweglichkeit in Frage stellen.

Eines ist klar: Beweglichkeit muss von JEDEM akzeptiert werden. Beweglichkeit ist nicht nur für Entwickler. Manager und Kunden müssen auch die Werte von Agile Manifesto akzeptieren. Wenn Kunden Agilität nicht akzeptieren und dennoch strenge Verträge und minimale Zusammenarbeit benötigen, dann nutzen Sie entweder Agilität nicht oder finden Sie bessere Kunden.

Es ist die Schuld des Kunden, dass er mit einer termingerechten Entwicklung in seiner Vertragsblase gefangen ist.

Wer ist schuld?

Manager, Rechtsabteilung, Buchhalter - treffen Sie Ihre Wahl ...

Ich weiß, dass das Beispiel ein wenig erfunden ist, aber die Tatsache, dass die Firma weggehen könnte, ohne einen Cent zu zahlen, wenn sie nicht zu 100% zufrieden wäre, hätte sofort Alarm schlagen müssen, ebenso wie das Mischen von Wasserfall und agilem Denken.

Kunden möchten ihren Kuchen haben und ihn essen - sie akzeptieren gerne Wasserfall, Mini-Wasserfall, Agile, La-La-Land, solange sie Produkt X für $ Y bis Datum Z erhalten.

Für eine agile Entwicklung ist es unbedingt erforderlich, dass sich das Entwicklungsteam und der Kunde aus methodischer Sicht auf derselben Seite befinden. Das Denken, dass Unterschiede in der Kultur nur beim Waschen zum Vorschein kommen, ist Wunschdenken.

IT-Projekte befassen sich mit Unbekannten ; Einige dieser Unbekannten sind sogar unbekannte Unbekannte . Was bedeutet das?

Nehmen Sie zum Beispiel eine Spielzeugbrücke für Ihre Modelleisenbahn. Ihnen sind alle Parameter bekannt:

• Sie wissen, wie groß das Tal ist

• Sie kennen das Material der Berge, ihre Höhe, Stabilität usw.

• Sie wissen, wie viel Material Sie benötigen

• Sie wissen aus früheren "Projekten", wie lange es gedauert hat, ähnliche Dinge zu bauen

Es sind viele Variablen involviert, die Ihre Berechnung des Investierens von Freizeit und Geld beeinflussen. Man könnte aber ohne nachzudenken sagen, ob es nächstes Wochenende fertig ist.

Nehmen Sie das Beispiel einen Schritt weiter:

• Nehmen wir an, Sie bauen die Brücke nicht für Ihre eigene Modelleisenbahn, sondern für einen völlig unbekannten Menschen: Ihre Aufgabe ist es, eine Eisenbahnbrücke zwischen zwei Bergen zu bauen

• Angenommen, Sie haben so gut wie keine Informationen vorab über die Modelllandschaft

• Die Information über die Landschaft ist, dass es zwei Berge gibt, die nicht zu groß erscheinen

• Die Konsistenz des Berges liegt zwischen Fels und Gelee

• Die Gesamtkosten betragen maximal 10 USD

• Der Arbeitsplatz ist komplett dunkel und es gibt keine Chance für Licht: Sie haben nur eine Schachtel mit 8 Streichhölzern

• Die Frist beträgt 3 Stunden

Das wäre die Analogie zu einem IT-Projekt. Sie haben Erfahrung im Brückenbau und es ist einfach, in bekanntem Gelände zu laufen. Was es schwer macht, ist die Dunkelheit . Es gibt viele Dinge, die Sie kaum vorhersagen können: Die Maße der Berge sind erst nach einiger Zeit im Dunkeln bekannt. So ist die Konsistenz der Berge. Daraus können Sie abschätzen, wie lange es dauern wird und wie viel es kosten wird. Hier sind die Unbekannten Dinge, die Sie zu Beginn des Projekts nicht kennen, wie das konkrete Terrain usw. Aber es gibt Dinge, die Sie selbst mit den erfahrensten und konservativsten Schätzungen nicht vorhersehen können. Dies sind die unbekannten Unbekannten, die ein bisschen Chaos ertragen.

Das sollte jedes IT-Unternehmen wissen. Sie müssen mit dem Projektrisiko umgehen.

1) Es gibt verschiedene Möglichkeiten, das (finanzielle) Risiko zu minimieren: Das Geschäft könnte beinhalten, dass der Kunde für jedes Arbeitsinkrement zahlt. Nach Auslieferung von Inkrement 1 muss also ein Teilbetrag gezahlt werden. Solange Scrum-Addicts LLC liefert, besteht nur ein minimales finanzielles Risiko. Je mehr feinkörnige Sprint Ziele geplant, das Gesamtrisiko eines jeden Sprints des unter. Das heißt, wenn Money-Bags Corporation 80% des Auftrags erhalten hat, sollten sie mindestens 80% des Auftragswerts bezahlen. Wenn sie sich weigern, nach einem fehlgeschlagenen Sprint zu zahlen, ist das Risiko nicht so hoch wie die Weigerung, 100% zu zahlen.

2) Scrum-Addicts LLC hat ein Problem mit ihren Entwicklern

Manager von Scrum-Addicts konsultieren ihr Scrum-Team und das Team sagt, dass es 3 Wochen dauern wird, bis alle Funktionen abgeschlossen sind. Der Manager von Scrum-Addicts fügt aus Sicherheitsgründen 1 Woche hinzu und verspricht, die Software in 1 Monat zu versenden und einen Vertrag zu unterzeichnen mit Geldsäcken

Dies deutet darauf hin, dass a) die Entwickler keine Erfahrung mit Scrum haben oder b) Scrum falsch machen. Je länger Teams mit Scrum arbeiten, desto besser sind ihre Schätzungen. Wenn das Team Schätzungen vornimmt und der Manager einen "Puffer" als "Sicherheit" hinzufügt, scheint der Manager es besser zu wissen als das Team, was ein schlechtes Zeichen ist . Wenn Sie ein erfahrenes Team haben, ist kein "Managerbuffer" erforderlich, das hat das Team bereits in die Schätzung einbezogen. Die Idee ist, je mehr Sprints das Team zusammengearbeitet hat, desto mehr kennt das Team seine Stärken und Schwächen und verfügt über einige Kennzahlen, um realistische Schätzungen vorzunehmen. Natürlich gibt es - wie schon erwähnt - die unbekannten Unbekanntendie dazu neigen, Schätzungen schwierig zu machen; oder zumindest ungenau. Aber auf lange Sicht sollten die Schätzungen immer besser werden.

Wer ist schuld?

1) Management

Wie oben gesagt: Es gibt eindeutig ein Versagen im Risikomanagement. Wenn das Unternehmen kurz vor dem Bankrott steht, hat es das verdient. Wenn Sie in einem solchen Unternehmen arbeiten: gehen Sie!

2) Das Team

Auch wenn das Management völlig dumm ist, sollte sich das Team gegen ein solches Projekt ausgesprochen haben. Ein guter Manager sollte die Risiken kennen. Ein guter Entwickler sollte jedoch auf Risiken hinweisen. Und vor allem: Das Team sollte frühzeitig melden, wenn etwas ausfällt.

Was ist zu tun?

Jetzt: Geldsäcke vor Gericht bringen

Für die Zukunft: Schließen Sie solche Verträge nicht ab

Scrum ist nicht für Managementfehler verantwortlich. Scrum wurde basierend auf den Erfahrungen vieler fehlgeschlagener IT-Projekte entwickelt. Es kann weder ein Versagen verhindern, noch kann es die Inkompetenz von Teams oder des Managements heilen. Die Grundidee ist:

• Kommunikationswege strukturieren (wer spricht mit wem wann über was)

• um Entwickler zu ermutigen, Fehler früh zu melden

• Probleme in Aufgaben und Unteraufgaben aufteilen

• Zeit und Kapazitäten strukturieren (wer arbeitet wann an was)

• um die Aufgaben auf die Zeitfenster zu verteilen

• das Unvorhersehbare ein bisschen vorhersehbarer machen (Poker planen)

oder insgesamt: um das Risiko zu minimieren.

Scrum ist ein Werkzeug wie ein Hammer. Ob es sich um ein gutes Werkzeug handelt, hängt von Ihren Kenntnissen im Umgang damit ab. Aber manchmal passt ein Schraubendreher besser. Es liegt an dir.

Zunächst einmal: "Wer ist schuld?" ist die falsche Frage. Schuldzuweisungen machen allen Spaß und werden wahrscheinlich dazu führen, dass sich alle, mit Ausnahme der beschuldigten Person (en), erleichtert fühlen , und kann tatsächlich kontraproduktiv sein und die Moral der Mitarbeiter beeinträchtigen.

Eine bessere Sichtweise ist "Was hat die Verzögerung verursacht?". War es mangelnde Erfahrung in der Technologie? Kritische Fehler, die beim Testen / QS nicht entdeckt wurden? Fehlende Tests / QS? Zu optimistisch in der Einschätzung? Berücksichtigen Sie nicht die nicht so optimistischen Einschätzungen des Teams? Jemand wurde von einem Bus angefahren? Unabhängig von der Ursache lautet die nächste Frage: "Wie stellen wir sicher, dass dies nicht noch einmal passiert?". In einigen (hoffentlich seltenen) Fällen lautet die Antwort möglicherweise "Loswerden", aber wenn Sie von "Ich muss den Verantwortlichen bestrafen" ausgehen, ist es unwahrscheinlich, dass Sie die Mehrheit der Fälle sehen wo es nicht die richtige lösung ist.

Innerhalb des Projekts sind Sie bereits versenkt. Die Frist ist abgelaufen, Sie haben den Kunden gewarnt, sobald sich herausgestellt hat, dass sie verrutschen wird (weil Sie das getan haben, oder? Wenn nicht, dann ist das ein Teil des Problems), und jetzt muss sie gehandhabt werden, wie auch immer es formuliert wurde im Vertrag (es ist tatsächlich im Vertrag ausgeschrieben, oder?). In der Regel sollten Sie mit dem Kunden verhandeln, wie Sie das liefern, was fehlt. Viele Menschen sehen einen Vertrag gerne als etwas, das nicht geändert werden kann. Sie müssen jedoch entweder a) den Vertrag fallen lassen und nicht das haben, was Sie gekauft haben, b) das Unternehmen wegen Vertragsverletzung verklagen und viel Geld vor Gericht ausgeben, und c) zu verhandeln, wie ihr Produkt mit dem geringstmöglichen Aufwand zu bekommen ist, wählen die meisten Unternehmen c.

Bevor Sie einem Kunden einen Preis / eine Frist nennen, sollten Sie die Risiken analysieren, die mit einer verspäteten Frist oder einer Kostenüberschreitung verbunden sind müssen planen), und verwenden Sie diese Informationen, um zu entscheiden, was Sie versprechen werden. Wenn es sich um einen Fall handelt, in dem es zu 100% oder gar nichts geht, geben Sie offensichtlich höhere Preise und längere Fristen an, da das Risiko höher ist.

Sie werden feststellen, dass ich in dieser ganzen Antwort nicht über Agile gesprochen habe. Das liegt daran, dass (ich werde die Beteiligung des Kunden an Scrum für eine Sekunde vergessen, auch wenn dies sehr, sehr wichtig ist), es an dieser Stelle nicht wirklich wichtig ist. Sie werden mit diesem Problem in Agile, Waterfall oder einem anderen von Ihnen verwendeten Entwicklungsprozess konfrontiert. Ja, Agile soll Ihnen dabei helfen, Risiken besser zu managen, indem Sie feststellen, ob sie früher zu tatsächlichen Problemen wurden, und den Kunden in den Prozess selbst einbeziehen, damit er immer informiert ist, aber es ist kein Allheilmittel.

Erstens ist dies ein Problem bei jeder Entwicklungsmethode. Zumindest mit einem iterativen Entwicklungssystem haben Sie dem Kunden am Ende der Frist etwas zu zeigen, was ausreichen kann, um eine Erweiterung zu erhalten, um das Produkt fertigzustellen (auch wenn der Kunde nicht mehr zahlt!).

Es gibt Fälle, in denen eine Frist eine Frist ist. Stellen Sie sich jedoch vor, Sie schreiben ein Spiel und es muss unbedingt rechtzeitig vor den Weihnachtsferien veröffentlicht werden. Wenn man das falsch macht, hat manches Unternehmen bankrott gemacht!

Für agile Methoden, die eine bestimmte Anzahl von Features bis zu einem bestimmten Datum fertigstellen müssen, ist Scrum wahrscheinlich nicht die beste Methode (da ich immer festgestellt habe, dass Scrum die Entwicklung verlangsamt und nicht genügend Agilität zulässt, um den Prozess zu ändern, wenn erforderlich.

Unabhängig von der Methodik müssen Sie einen Rückstand an erforderlichen Funktionen einrichten, um den Fortschritt sichtbar zu machen. Fortschritte auf Sprintbasis sind nicht gut genug. Sie werden nicht wissen, ob Sie das endgültige Ziel erreichen. Eine Methode im Kanban-Stil wäre also besser: Setzen Sie alle Funktionen auf der linken Seite und bearbeiten Sie sie im System, um den Fortschritt bis zur Fertigstellung anzuzeigen.

Das fokussiert die Leute auf das, was noch zu tun ist, und lässt andere als das Entwicklerteam erkennen, was noch übrig ist und ob Sie das Ziel wahrscheinlich erreichen (und somit die Kundenerwartungen frühzeitig verwalten) , oder vereinbaren Sie diese Überstundenboni, bevor sie gebraucht werden).

Scrum ist ein System, das für immer töpfert und ständig etwas definiert und verfeinert. Es ist einfach nicht für diese Art von Entwicklung geeignet. Andere können dieses System verwalten und trotzdem das iterative Entwicklungskonzept beibehalten. Kanban ist eines davon, Crystal ein anderes. Es ist jedoch wichtig zu verstehen, dass Sie nicht agil sind, wenn Sie Scrum religiös folgen. Jedes echte Agile-System sollte in der Lage sein, sich diesen besonderen Problemen anzupassen. Deshalb wurde es in erster Linie als agil bezeichnet. Es geht darum, das zu erledigen, was getan werden muss, und wenn ein fester Termin dazu gehört, sollten Sie dies tun Berücksichtigen Sie dies bei Ihrer Arbeitsweise.

Das Entwicklungsparadigma stimmt nicht mit dem Vertragsparadigma überein. Im Idealfall würde sich die Art und Weise, wie Verträge geschrieben werden, ändern, aber es ist unwahrscheinlich, dass dies tatsächlich geschieht. Aber selbst wenn Sie Scrum fallen lassen würden, hätten Sie immer noch Überraschungen und Termine verpasst (nur würden Sie wahrscheinlich viel später sein, weil Sie all das Design im Voraus gemacht haben und es war alles falsch !!).

Mit oder ohne Änderung der Vertragsgestaltung versenden Sie, was Sie arbeiten . Erfüllen Sie dann den Vertrag, indem Sie einen Zyklus Entwicklungszeit in Anspruch nehmen, um die Funktionen zu beenden, die Sie nicht erledigt haben.

Ist es gut, dass Sie nicht alles eingehalten haben, was Sie an dem Tag versprochen haben, an dem Sie es versprochen haben? Nein, aber Ihr Kunde wird viel glücklicher sein, wenn Sie etwas liefern können, das pünktlich funktioniert, und dann den Rest schnell nachliefern, als wenn Sie einfach zu spät dran sind und überhaupt nichts zu geben haben.

In vielen Scrum-Büchern und -Artikeln heißt es, dass ein fehlgeschlagener Sprint (wenn das Team einige Funktionen aus dem Sprint Backlog nicht fertigstellt) nicht so schlimm ist, dass er von Zeit zu Zeit auftritt und tatsächlich nützlich sein kann, wenn das Team aus seinen Fehlern lernt und verbessert etwas in den folgenden Sprints. Und das Team sollte nicht dafür bestraft werden, dass es die Arbeit, für die es sich engagiert, nicht beendet hat.

Sie "bestrafen" diese Art von Verhalten, indem Sie die Menge an Arbeit begrenzen, die diejenigen, die nicht fertig sind, für den nächsten Sprint übernehmen können. Die Chancen, an coolen Sachen zu arbeiten, schwinden. Die Belohnung für gute Arbeit ist mehr Arbeit.

Dies sieht aus Entwicklersicht großartig aus. Nehmen wir jedoch an, wir haben eine Softwarefirma "Scrum-Addicts LLC", die etwas für ernsthafte Kunden entwickelt ("Money-Bags Corporation"):

Manager von Scrum-Addicts schlagen vor, eine Software für Money-Bags zu erstellen. Sie einigen sich auf eine Liste von Funktionen, und Money-Bags bittet um Angabe eines Versanddatums. Manager von Scrum-Addicts wenden sich an ihr Scrum-Team. Das Team gibt an, dass es 3 Wochen dauern wird -lange Sprints, um alle Funktionen zu vervollständigen Scrum-Addicts-Manager verlängert sicherheitshalber um eine Woche, verspricht, die Software in einem Monat zu versenden und unterzeichnet einen Vertrag mit Money-Bags. Nach 4 Sprints (Versandfrist) kann das Scrum-Team nur 80% liefern. von Funktionen (aufgrund von Unerfahrenheit mit dem neuen System, der Notwendigkeit, kritische Fehler in früheren Funktionen in der Produktionsumgebung zu beheben, usw.) Wie Scrum vorschlägt, ist das Produkt zu diesem Zeitpunkt möglicherweise versandfertig, aber Money-Bags benötigt 100%. von Funktionen, wie im Vertrag erwähnt. Also brechen sie den Vertrag und zahlen nichts.

Scrum-Addicts steht kurz vor dem Bankrott, weil sie kein Geld von Money-Bags bekommen haben und die Investoren von den Ergebnissen enttäuscht waren und nicht mehr bereit sind, dem Unternehmen zu helfen.

Wenn ich am Montag mit 100 Dollar wette, dass es am Donnerstag regnet und es erst am Freitag regnet, dann ist es richtig, mein Geld zu nehmen. Wenn Sie keine Chance auf Glücksspiele haben möchten, sondern eine Wettervorhersage, benötigen wir einen Vertrag, mit dem ich Ihnen am Dienstag eine aktualisierte Vorhersage geben kann.

Offensichtlich möchte kein Software-Unternehmen in den Schuhen von Scrum-Addicts sein. Was ich bei Agile und Scrum nicht verstehe, ist, wie die Teams mit der Planung und den Fristen umgehen sollten, um die oben beschriebene Situation zu vermeiden.

Überlegen Sie, warum MB ihren Ball mitnehmen und nach Hause gehen möchte. MB verlangte von Anfang an nicht, dass die Arbeit in einem Monat erledigt sein würde. SA versprach 100% der kritischen Funktionen innerhalb eines Monats und lieferte diese nicht aus. SA setzen die Frist nicht MB. SA hat die Frist sogar willkürlich um eine Woche verlängert. Warum ist dies eine Frist?

Gelegentlich geben Unternehmen im Wettbewerb um Arbeitssoftware der Versuchung nach, zu protzen und den Mond zu versprechen. Profis prüfen sorgfältig, ob überhaupt ein Mond benötigt wird. Welches ist der kritischere Bedarf an MoneyBags? 100% der Funktionen oder ein funktionierendes Produkt in einem Monat? Wissen sie überhaupt, was wirklich kritisch ist? Gibt es eine bevorstehende Veranstaltung, die einen harten Termin festlegt?

Wenn ich Scrum-Addicts wäre, der diesen Vertrag aushandelt, würde ich gerne mehr über die geschäftlichen Anforderungen von Money-Bags erfahren und den Vertrag so strukturieren, dass so viel Flexibilität gewährt wird, wie Money-Bags möchte. Ich würde ihnen beibringen, wie der agile Prozess funktioniert, damit sie wissen, was sie von uns erwarten können.

Auf diese Weise wird nicht erwartet, dass in einem Monat plötzlich alles einwandfrei funktioniert, sondern es wird erwartet, dass die erste Lieferung in 1 bis 2 Wochen evaluiert wird.

Zusammenfassend habe ich also zwei Fragen:

Wer ist schuld? Manager, weil es ihre Aufgabe ist die richtige Planung zu tun
Das Team, weil sie zu tun mehr Arbeit begangen , als sie könnte
jemand anderes

Jeder hätte diese Travestie stoppen können, bevor wir noch einen Monat Zeit hatten.

Ich könnte sogar Money-Bags Corp beschuldigen, ein Team eingestellt zu haben, das offensichtlich einen Wasserfallprozess als agil darstellt. Der Vertrag selbst macht deutlich, dass dies nicht agil ist. Die Planung in einem Monat macht es nicht wendig.

Wenn Sie darauf bestehen, dass es agil ist, ist es mit nur einem Sprint, der einen Monat dauert, agil. Das würde ich nicht empfehlen, denn das ist wieder das Gleiche wie Wasserfall.

Was ist zu tun?

Wie wäre es mit agil? Jeden Sprint etwas liefern? Feedback vor dem Abgabetermin erhalten? Wochenlange Sprints? Wie wäre es, wenn Sie den drakonischen Vertrag in dem Moment neu aushandeln, in dem Sie vermuten, dass die Frist in Gefahr ist, anstatt sich zu verstecken und zu beten? Zumindest können Sie aufhören, Zeit für ein zum Scheitern verurteiltes Projekt zu verschwenden und einen vernünftigeren Kunden finden.

Die Manager sollten die Frist zweimal (oder dreimal) später als die Schätzung des ursprünglichen Teams verschieben.

Fristmultiplikatoren sind ungefähr so ​​nützlich wie das Einstellen Ihrer Uhr um 15 Minuten, damit Sie nie zu spät kommen. Sie können sich nur so lange täuschen, bis Sie merken, was Sie vorhaben.

Frühe Schätzungen sind falsch. Versuchen Sie zu erfassen, wie falsch. 5 Wochen, ein paar Wochen geben oder nehmen ist ein einfacher Ausdruck, mit dem Sie ausdrücken können, wie unsicher das Fertigstellungsdatum tatsächlich ist. Anstatt genau zu raten, raten Sie, wie wild Ihre Vermutung ist. Machen Sie echte Arbeit und holen Sie sich echte Daten. Dann können Sie Schätzungen mit einem engeren Bereich vornehmen. Ein bis zwei Wochen sind genug Zeit dafür.

Die Teammitglieder sollten ermutigt werden, alle von ihnen geleisteten Arbeiten zu verrichten, egal auf welche Weise (durch Verhängung von Strafen für fehlgeschlagene Sprints).

Teammitglieder sollten ermutigt werden. Fehlgeschlagen, festgeschrieben oder anderweitig. Anstatt künstliche Konsequenzen wie Strafen oder sogar Boni (Zuckerbrot und Peitsche) zu konstruieren, haben Studien gezeigt, dass Menschen, die kreative Arbeit wie das Programmieren leisten, am besten reagieren, wenn sie drei Dinge voraussetzen: Autonomie, Meisterschaft und Zweck.

Daniel Pink hat ein TED-Gespräch darüber. Es geht um Motivation, die nicht agil ist, aber ich habe leicht gesehen, wie man diese Punkte auf agil abbildet:

Autonomie - Ich möchte mein eigenes Leben bestimmen - Lassen Sie mich die Arbeit aus dem Rückstand heraussuchen.
Beherrschung - Ich möchte etwas verbessern, was wichtig ist - Kundenfeedback.
Zweck - Ich möchte Teil von etwas Größerem sein als ich selbst - Ein kollaboratives Team.

Das Team sollte Scrum fallen lassen, da es nicht zur Fristrichtlinie des Unternehmens passt. Scrum kann eine Frist genauer als ein Wasserfall einhalten. Angesichts eines Termins kann scrum es einhalten. Abhängig von der Zeit, der Funktion und dem Können wird es möglicherweise nur mit einem von 47 Features erfüllt, aber es kann es erfüllen.

Ein agiles Projekt kann so extrem gestaltet werden, dass es jede Nacht, wenn das Team nach Hause geht, versandbereit ist. Dies erscheint unsinnig, es sei denn, Sie möchten den Kunden bitten, den Versand zu testen und Feedback zu geben. Je früher dies geschieht, desto eher können Sie Anpassungen vornehmen. Dies trifft jede mögliche Frist. Nur nicht jede Funktion. Aber es lenkt Sie zu den Funktionen, die wichtig sind.

Wir sollten alle die Softwareentwicklung einstellen und uns einem Kloster anschließen

Richtig, wie wenn ich in einem Raum weg vom wirklichen Leben eingesperrt werde, werde ich WENIGER Code schreiben.

Ich habe diese Antwort auf die Größe reduziert. Wenn Sie neugierig sind, lesen Sie den Bearbeitungsverlauf.

Jeder muss agil sein. Wie auch immer Sie sich entscheiden, sehen Sie aus, wer macht was, wie, wann, wo und warum von allen Parteien. Agile Kunden, Management und Entwickler.

Sie können ein Versanddatum nicht zu weit in die Zukunft verschieben. Sie geben eine Schätzung.

Jemand musste die Erwartungen des Kunden erfüllen. Der Grund, warum Sie sich nicht zu viele Sorgen darüber machen, dass ein paar Sprints ins Hintertreffen geraten, ist, dass Sie sich anpassen, um zu verhindern, dass das gesamte Projekt ins Hintertreffen gerät. Wenn Sie nach ein oder zwei Sprints zu dem Schluss kommen, dass Sie das "Versanddatum" nicht einhalten werden, teilen Sie dies dem Kunden mit.

Was willst du jetzt machen? Beseitigen Sie Funktionen, die Sie nicht benötigen, und verschieben Sie das Datum. Wenn Sie rechtzeitig liefern könnten, würden Sie. Zögern Sie nicht, schlechte Nachrichten zu bringen.

Wer weiß, bei einigen Projekten können Sie früher versenden.

Sie können nicht agil sein, wenn der Kunde nicht will.

Tor

Ich glaube, die folgenden zwei "Metriken" sollten die Grundlage für jede Geschäftsentscheidung sein:

• ist die Arbeit rentabel (für den Kunden)
• Arbeiten wir so effizient wie möglich?

Diese sind ziemlich universell. Natürlich wird es sehr schnell komplizierter. Bei profitabler Arbeit geht es zum Beispiel darum, dass das Produkt das Richtige tut, der Benutzer das Produkt verwenden kann, das Produkt richtig vermarktet wird usw. - für viele dieser " Scrum-Addicts" LLC "trägt keine Verantwortung.

Problem

Der Vertrag konzentriert sich nicht auf die oben genannten Ziele. Es gibt eine "Alles oder Nichts" -Klausel - alles erledigen und bezahlt werden oder nichts erledigen und nicht bezahlt werden. Dies hängt jedoch nicht direkt mit der Wertschöpfung zusammen. Ein weiterer Nachteil, der sich daraus ergibt: Jetzt müssen wir Zeit und Geld investieren, um sicherzustellen, dass der Vertrag eingehalten wird. Warum um alles in der Welt wollen wir dieses Geld ausgeben? Wie hilft es, sicherzustellen, dass ein Vertrag erfüllt wird, wenn sich die Anforderungen in der Zwischenzeit geändert haben und wir festgestellt haben, dass die bestellte Software keinen Wert schafft? Es geht einfach mehr Geld den Bach runter! Jetzt gibt es natürlich einen Grund für dieses Verhalten:

• Kulturell sind wir daran gewöhnt, solche Dinge zu kaufen. Wir erwarten, dass Sie wie bei einem Auto nach Software suchen: Wählen Sie eine Konfiguration aus, geben Sie einen Preis und eine Frist an und seien Sie sehr unglücklich, wenn diese beiden Bedingungen nicht erfüllt werden.
• wir wollen risiko und verantwortung abschieben
• Wir wollen Stabilität, sie hilft bei der Planung und lässt uns besser fühlen (und auch unseren Kunden, was ein wichtiger Aspekt ist!)

Letztendlich müssen wir einen Kompromiss finden, der es uns ermöglicht, unsere Ziele so gut wie möglich zu erreichen.

So sollte es funktionieren

• haben einen Vertrag für Dienstleistungen und Arbeiten anstelle eines Produkts
  • muss relativ kurzfristig kündbar sein
• arbeiten eng zusammen, um eine optimale Effizienz zu gewährleisten
• Binden Sie alle notwendigen Parteien ein, sowohl von " Scrum-Addits LLC " als auch von " Money-Bags Corporation " - ein "Single Point of Contact" -Tunnel, bei dem alle Informationen nicht funktionieren

Nun, ich sagte im Grunde nur "agil sein". Hier ist der Grund:

• process & contract sind optimiert, um so viel Geld wie möglich für das Ziel auszugeben
• Sie müssen dem Auftragnehmer vertrauen, um seine Arbeit zu erledigen, und nicht viel Geld investieren, um zu überprüfen, ob er der Aufgabe gewachsen ist.
• Die Möglichkeit, Ihren Auftragnehmer zu verklagen, wenn Ihre Erwartungen / Ihr Vertrag nicht erfüllt werden, hilft normalerweise nicht, da dies mehr kostet als nur das Fallenlassen. Einige der Hauptprobleme hierbei sind die Markteinführungszeiten. Sie werden höchstwahrscheinlich viel mehr Geld / Geschäft verlieren, wenn Sie vor Gericht gehen, als Sie bekommen.
  • am ende des tages musst du nur ein paar risiken selbst tragen.