Umgang mit fehlgeschlagenen Sprints und Deadlines

80

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. ???
Andre Borges
quelle
31
Ihr Punkt 3 unter "Zu erledigen" geht davon aus, dass sich nichts daran geändert hätte, dass in einem Monat nur 80% der Funktionen verfügbar waren. Das ist lächerlich.
Doc Brown
7
@ DocBrown, ich kann nicht zustimmen, dass es lächerlich ist. Der Verzicht auf einige Scrum-Aktivitäten wie Retrospektiv- und Demonstrationstreffen könnte die Entwicklung beschleunigen. Und im Falle eines grundsoliden Vertrags könnte dies dazu beitragen, das endgültige Ziel zu erreichen: eine feste Anzahl von Funktionen am Ende der Frist bereitzustellen.
Andre Borges
26
@AndreBorges Ihr Vorschlag, Rückblicke und Demonstrationen fallen zu lassen, entspricht dem Vorschlag, Bremsen aus einem Auto zu entfernen. Sicher, Bremsen bremsen nur. Aber genau das ermöglicht es Ihnen, sehr schnell zu fahren.
Euphoric
13
das gleiche Problem bleibt unter jedem System - beachten Sie, dass Sie ziemlich viel Gedränge mit einem äquivalenten Wasserfall noch ein und das Unternehmen Büste ersetzen geht
jk.
6
Vielleicht hätten diese Scrum-Addicts-Manager bei diesen lästigen "Rückblick" -Treffen die Chance gehabt, in der ersten oder zweiten Woche auf die Bremse zu treten, anstatt das Projekt auf die Klippe zu lenken und auf das Gaspedal zu treten .
Dorus

Antworten:

134

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".

Doc Brown
quelle
47
+1 für "Ein Alles-oder-Nichts-Vertrag ist etwas, von dem weder der Softwareanbieter noch der Kunde profitieren werden" . Es ist der Schlüssel zum agilen Contracting.
Guillaume31
5
Und es ist sicherlich der Fall , dass 80% nicht gut für einige Arten von Projekt ist (schließlich ist es möglich , wenn auch unwahrscheinlich, dass agile auch limitierend Bereitstellung für diese Projekte zu machen). Zum Beispiel ist es sinnlos, 80% der Funktionen für Ihren Satelliten beim Start zu haben, weshalb Sie sich nicht mit der Kontingenz bei diesen Projekten herumschlagen. Wenn Sie nicht liefern, wird die Mission Ihres Kunden fehlschlagen (oder sich verspäten), und Sie können nichts im Vertrag tun, um dies zu ändern.
Steve Jessop
6
@SteveJessop: Ich bin mir ziemlich sicher, auch wenn Sie eine so komplexe Software für einen Satelliten erstellen, gibt es unterschiedliche Prioritäten für verschiedene Funktionen, und es wird viele Funktionen geben, bei denen der Umfang bis zu einem gewissen Grad variieren kann. Die Frist kann natürlich für eine solche Situation festgelegt werden, denn wenn Sie die Rakete erst im Dezember nächsten Jahres ins All bringen, erhalten Sie möglicherweise keine zweite Chance.
Doc Brown
6
Aber für dieses spezielle Beispiel hätte natürlich niemand neue Horizonte erschlossen, wenn es ihnen nicht gelungen wäre, den Hardwaretreiber der Kamera fertigzustellen. Aber selbst für Projekte in diesem Maßstab würde ich wetten, dass man nicht mit jedem Merkmal, das man sich vorgestellt hat, ins All geht.
Zaibis
6
Möglicherweise ist auch die Zahlung pro Meilenstein oder Funktion möglich.
Bram
68

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.

Euphorisch
quelle
9
@RubberDuck Es muss noch eine Software-Projektmanagement-Methodik geben, mit der Features im Vorfeld festgelegt werden können, der Termin festgelegt werden kann und die nicht besonders teuer war. Umfang, Zeit, Geld; Wähle zwei aus.
Euphorisch
8
@RubberDuck: Das Projekt ist schon nicht agil, weil die Anforderungen in Stein gemeißelt sind. Und die Schätzung ist nur drei Wochen. Der Wasserfall hat nichts magisch Schlechtes, was ihn immer zu spät macht. Er kann nur nicht mit vagen Anforderungen und Veränderungen umgehen. Ja, ich würde in diesem Fall "Wasserfall" verwenden, oder genauer gesagt "Lassen Sie uns entscheiden, was getan werden muss und es tun".
RemcoGerlich
3
@RemcoGerlich ironischerweise "Lassen Sie uns entscheiden, was getan werden muss und es tun" ist bemerkenswert agil selbst :-)
gbjbaanb
2
@RemcoGerlich ah, ich denke du verstehst meinen Punkt falsch: In diesem agilen Modus geht es nicht wirklich um die Dev-Methoden, sondern um die Fähigkeit, mit der Arbeit fortzufahren, mit welchen Mitteln auch immer du willst. Es geht doch um Fortschritt, nicht um Prozeduren. (z. B. ein Team, das nur Scrum ausführt, ist nicht agil, ein Team, das nur den Wasserfallstil
ausführt,
2
Ich stimme Doc Brown hier zu. Sie können absolut ein "Zeitlimit" haben, ohne genau zu sagen "wofür". Es ist durchaus vernünftig zu sagen: "Unsere Frist ist <irgendein Datum>. An diesem Datum versenden wir, was wir getan haben." Der Umfang dessen, was ausgeliefert wird, muss nicht in Stein gemeißelt werden, sobald die Frist festgelegt ist. Bei der agilen Entwicklung dreht sich alles um die Verwaltung des Umfangs und die Kommunikation des Fortschritts in Zeitrahmenschritten.
Eric King
15

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.

Robbie Dee
quelle
12

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.

Thomas Junk
quelle
1
Es gibt einen anderen Aspekt von Scrum, der von entscheidender Bedeutung ist, um zu verstehen, warum dieses Projekt gescheitert ist: Scrum umfasst das Scheitern . Es wird erwartet, dass die ersten Sprints eines neuen Teams oder Projekts scheitern werden. Durch den Scrum-Prozess von Retrospektiven wird sich das Team verbessern und langfristig genaue Schätzungen abgeben, jedoch nur, solange es dasselbe Team bleibt, das am selben Projekt arbeitet. Wenn sich eine dieser Änderungen ändert, sollten Sie erneut mit einem Fehler rechnen, da sich die zugrunde liegenden Variablen verschieben.
Cronax
9

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.

Iker
quelle
3
-1 Das Agile ist, dass viele der Risiken einfach nicht vorhergesagt werden können. Zum Beispiel fügten sie 1 Woche Puffer hinzu, falls etwas schief gehen sollte. Sie können die benötigte Zeit immer verdreifachen, verlieren dann aber gegen die Konkurrenz, die das nicht tut. Agile sollte die Mentalität "Es ist erledigt, wenn es erledigt ist" annehmen. Welches ist einfach unvereinbar mit Verträgen und Fristen wie beschrieben.
Euphoric
3
@Euphoric Dem kann ich nicht ganz zustimmen. Ja, der Punkt von Agile ist, dass viele Risiken nicht vorhergesagt werden können, und dafür ist der Puffer da, das gebe ich Ihnen zu. Dies bedeutet jedoch nicht, dass alle Risiken unvorhersehbar sind, und es bedeutet auch nicht, dass Sie blind in ein Projekt einsteigen sollten, ohne die Risiken zu berücksichtigen, die Sie vorhersagen können.
Iker
2
@Iker Das eine schließt das andere nicht aus, aber der Punkt, an dem man im Entwicklungsprozess wirklich agil ist, ist, dass "Es ist erledigt, wenn es erledigt ist" für den Kunden und das Team. Sicher, es gibt immer einige Risiken, die Sie vorhersagen können, aber Sie können niemals alle möglichen Risiken und genau die Auswirkungen, die sie auf Ihren Fortschritt haben werden, erfolgreich vorhersagen. Es sei denn, Sie können die Zukunft irgendwie sehen. Das ist der Grund, warum agile Arbeit eine spezielle Auftragsvergabe erfordert, bei der Sie zustimmen, dass "wir so lange weiterarbeiten, bis das Geld
aufgebraucht
ok, ich habe dies für die sofortige Ablehnung von Schuld als Konzept empfohlen. Ich stimme zu, dass Schuld eine unproduktive Komponente ist, die vom Erfolg ablenkt. Lassen Sie uns die Frage ändern. Vielleicht könnten wir es schaffen, "wie hätten wir damit umgehen können"? "Wie können wir daraus einen Erfolg für uns machen?" "Welche Veränderungen von jeder Partei hätten zu einem positiven Ergebnis führen können?" Es mag in Ordnung sein, "Schuld" in "verantwortlich" zu ändern, aber da jedes Projekt mit einem Lieferanten und einem Kunden eine Teaminteraktion ist, ist nicht trotzdem das gesamte globale "Team" verantwortlich? Die Frage, wer schuld ist, wird dann rhetorisch.
Joshua K
4

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.

gbjbaanb
quelle
6
"Game ready for christmas" könnte ein Aushängeschild für Scrum sein. Versenden Sie die 80%, die Sie fertig sind, und verkaufen Sie den Rest als DLC. Dies ist nicht die hier diskutierte hypothetische Situation, in der die Frist sowohl zeitlich als auch räumlich festgelegt wurde und eine 100% ige Strafe für Teillieferungen vorgesehen ist.
MSalters
2
@MSalters Sie gehen davon aus, dass das Spiel überhaupt funktioniert, dass 80% der Features nicht fehlen, die später hinzugefügt werden können, aber die Funktionalität beeinträchtigen oder Fehler verursachen. Es muss kein Spiel sein, es kann sich um jede Software handeln, die für eine bestimmte Zeit ausgeliefert werden muss und deren Frist unverändert
bleibt
6
Das ist die Grundvoraussetzung von Scrum! Defekte Funktionalität zählt nicht. Wenn Sie aus einem Wasserfall-Hintergrund stammen, werden Sie feststellen, dass Scrum Bugfixes gegenüber dem Hinzufügen neuer Funktionen priorisiert. "80% erledigt" bedeutet, dass Levels fehlen, Chefs fehlen usw.
MSalters
1
@gbjbaanb Nach dieser Überlegung könnte etwas zu 99,9% erledigt sein, aber immer noch nicht funktionieren, da es unmittelbar nach dem Start abstürzt.
user253751
@immibis aber das ist wahr. Dinge wie Spiele neigen nicht dazu, Features bis zum Ende wegzulassen, die meisten Teile eines Spiels müssen implementiert werden, damit das Ganze funktioniert - während Sie einige Features herausnehmen können (und ich weiß, dass Spiele, die dies getan haben), die sie nicht hinzufügen Funktionen inkrementell. Ein vermisster Boss wäre also ein kaputtes Spiel. Ich habe nur Spiele als Beispiel gewählt, da diese (insbesondere vor der Internetauslieferung) als Beispiele für harte Fristen gelten.
gbjbaanb
4

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.

Badeente
quelle
3
Ja, manchmal ist der Kunde zufriedener, wenn das Team zumindest einen Teil der Arbeitsfunktionen bereitstellt. Dies ist jedoch nicht immer der Fall. Ich spreche von Fällen, in denen (1) das Produkt für Endbenutzer nutzlos ist, es sei denn, 100% der Funktionen sind implementiert (zum Beispiel erfordert es eine teure Zertifizierung, die erst durchgeführt werden muss, wenn alles fertig ist) oder (2) der Kunde ist ein Unternehmen der alten Schule mit dem "All-or-Mothing" -Ansatz: Wenn das Produkt nicht zu 100% fertig ist, halten wir es für gescheitert, brechen Sie den Vertrag und entlassen Sie alle Verantwortlichen.
Andre Borges
2
Der Kunde wird immer froh sein, wenn die Art und Weise, wie Software funktioniert, Fortschritte erzielt. Die teure Zertifizierung kann warten, bis das Produkt ihrer Zufriedenheit entspricht. Die Freigabe für den Kunden bedeutet nicht, dass er sie für die Öffentlichkeit freigeben muss. In Fall 2 gibt es wirklich keine andere Möglichkeit, als Ihre Rechts- / Verkaufsteams bessere Verträge schreiben zu lassen. Ehrlich gesagt, wären Ihre Probleme mit dem Wasserfall dort dieselben, wenn nicht schlimmer.
RubberDuck
2
@AndreBorges Der Kunde wird mit Sicherheit glücklicher sein, 80% der Funktionen zu sehen, als 0% der Funktionen zu sehen. Zumindest auf diese Weise weiß der Kunde, dass das Produkt meistens fertig ist.
user253751
@immibis, wenn du das sagst, bedeutet das, dass du glücklich genug warst, einige „eigentümliche“ Kunden in deiner Arbeit zu meiden. Es gibt einige große, schwerfällige staatliche Unternehmen, die nicht so vernünftige Vertragsbedingungen durchsetzen. Wenn Sie jedoch alle Ihre Ressourcen in ihre Aufgaben investieren und erfolgreich sind, zahlen sie ernsthaftes Geld, das Ihr kleines Unternehmen in den Himmel heben könnte. Wenn Sie jedoch scheitern, suchen Sie möglicherweise nach einem neuen Job. Es ist das Risiko, das manche Menschen eingehen wollen.
Andre Borges
2
Genau! Aufgrund der internen Bürokratie und des Mangels an erfahrenen Führungskräften ist es für ein großes Unternehmen manchmal einfacher, eine versäumte Frist als "erfolgloses Experiment" zu betrachten und das Projekt insgesamt fallen zu lassen, als weitere Anstrengungen zu unternehmen, um zu versuchen, den Umfang zu kommunizieren und neu zu verhandeln. Traurig, aber wahr :(
Andre Borges
1

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.

kandierte_orange
quelle
Ich möchte nur annehmen, dass Sie Sprint und nicht Rückstand meinten - ich meinte genau das, was ich in der Frage geschrieben habe: den Sprint-Rückstand
Andre Borges,
Leute, die kreative Arbeit wie das Programmieren verrichten, reagieren am besten, wenn sie drei Dinge voraussetzen: Autonomie, Beherrschung und Zweck - dies kann für sich genommen ein großes Thema für Spekulationen sein, aber die Tatsache ist, dass leider viel Programmierarbeit weniger kreativ und mehr wird Routine (langweilige Aufgaben, feste Tech Stack und Feture Sets, strenge Verträge). Daher funktionieren Karotten und Peitschen in vielen Fällen einwandfrei.
Andre Borges
@AndreBorges Sie haben Recht, ich habe an den Produktstau gedacht. Kürzlich habe ich mit einem Tool gearbeitet, das den Sprint-Rückstand den Sprint und den Produkt-Rückstand den Rückstand nennt. Sie haben mich dabei erwischt, wie ich den Kampf verlor, um zu verhindern, dass mein Wortschatz urheberrechtlich geschützt ist.
candied_orange
@AndreBorges-Programmierung wird niemals Umschlagfüllung sein. Es ist fest ein Kerzenproblem. Der Grund dafür ist, dass sich wiederholende Probleme mit demselben Code gelöst werden können, mit dem auch das erste Problem gelöst wurde. Trotzdem kann das Management in eine Denkweise geraten, in der es denkt, Kreativität sei ein Problem, das es auszumerzen gilt. Ich habe für einige dieser Läden gearbeitet und bin von ihnen weggelaufen. Sie halten keine guten Leute. Sie produzieren keine gute Software. Entwickler sind Handwerker. Der Versuch, sie zu Fließbandarbeitern zu machen, schadet nur Ihrer Sache. Meine Aufgabe ist es nicht, Eier umzudrehen. Es ist zu gewährleisten, dass die Eier umgedreht werden.
candied_orange
0

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.

JeffO
quelle
0

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.
BatteryBackupUnit
quelle