Ist es gültig und möglich, feste, unverrückbare Fristen in Scrum zu bewältigen?
Ich denke, es ist einfach verwirrend für mich, weil ich dachte, dass eines der Kernprinzipien des Projektmanagements darin besteht, realistische Schätzungen eines Fertigstellungstermins auf der Grundlage begrenzter Informationen zu ermitteln. Gibt es einen Zweig des Projektmanagements, insbesondere des Agile- oder Scrum-Projektmanagements, der das Gegenteil betrifft, beginnend mit dem Abschlussdatum und rückwärts arbeitend, um kreative Wege zu finden, alles einzufügen?
Ich versuche, die Methodik und Strategie des Projektmanagements in meinem aktuellen Unternehmen zu verstehen. Es ist ein großes Finanzinstitut und es laufen zu jeder Zeit Hunderte von Projekten. Es gibt ein großes Programmmanagementbüro, das Statusinformationen zu vielen verschiedenen laufenden Arbeitsthreads sammelt, um den Status bis zur Führungsebene zu kommunizieren. Die Projektmanager pflegen Projektpläne und koordinieren Projektstatusinformationen von Projektressourcen an die Programmmanager.
Das Seltsame, was ich nicht herausfinden kann, ist, dass es, wenn ein Projekt in der Konzeption ist, keinen wirklichen technischen Aufwand gibt, um Schätzungen des Aufwands oder der Zeit für die Projektmeilensteine zu bestimmen. In dieser Phase scheint es völlig unwichtig zu sein, da alle Projekttermine von den IT-Verantwortlichen oder vom LOB ungesehen festgelegt werden.
Nachdem uns das Datum mitgeteilt wurde, wird uns gesagt, dass wir eher eine formelle Schätzung des Aufwands (Story Points) als der Zeit vornehmen sollen, da die Organisation den Führungsauftrag hat, agil und Scrum zu sein. Das Seltsame ist, dass, nachdem wir alle Epics und T-Shirt-Größen identifiziert haben, der Projektmanager immer noch herausfinden muss, wie er all dies in die vorgegebene Frist einpassen kann. Um dies zu tun, teilen wir uns auf und führen eine detaillierte Schätzung der Story Points eines einzelnen Epos durch, normalerweise eine kleine Größe, dann werden die gesamten Story Points davon vergleichend verwendet, um die insgesamt angenommenen Story Points zu ermitteln. Von dort bestimmt der Projektmanager die Geschwindigkeit und beweist, ob alle Projektmeilensteine bis zum Stichtag erreichbar sind.
Das Konzept des Minimum Viable Product existiert nicht. Der PM muss zeigen, wie viele Leute benötigt werden, damit diese Frist möglich ist, und wenn es zu teuer ist, kann das Projekt abgebrochen werden, bevor es überhaupt begonnen hat.
Die Sache ist die, dass in den letzten Jahren fast jedes Projekt als gescheitert angesehen werden konnte, weil sie diese Fristen fast nie einhielten. Was ich nicht verstehe, ist, dass sich trotz Scheitern nach Scheitern nichts Wesentliches zu ändern scheint. Es scheint auf lange Sicht nicht wirklich wichtig zu sein, mit dem Projekt zu spät zu kommen. Wenn das Projekt zu spät kommt, nehmen die Statusmeetings zu und die allgemeine Angst scheint zuzunehmen, aber fast alle arbeiten weiter, wie sie es normalerweise tun.
Andere Leute, die schon lange in der Firma sind, haben mir gesagt, dass es eigentlich zwei Dates sind. Die formale Frist, die auf dem Papier steht, und das Datum, das die Führungskräfte tatsächlich erwarten, wenn das Projekt in der Realität abgeschlossen sein wird. Als ich fragte, warum die Deadline nicht einfach Realität werden sollte, stimmten sie fast überall darin überein, dass die Unternehmensführung der Meinung ist, dass die Menschen „härter arbeiten“, wenn Projekte auf dem Papier zu spät laufen.
Ich sehe das aus mehreren Gründen nicht funktionieren. Veteranen im Unternehmen spüren den Druck nicht, weil sie glauben, dass versucht wird, sie dazu zu bringen, härter zu arbeiten. Neuere Leute werden demoralisiert und hören auf, es zu versuchen. Jeder verbringt mehr Zeit in Statusmeetings mit ängstlichen Programmmanagern, anstatt sich auf die Projektarbeit zu konzentrieren, und schließlich ist die Natur der Arbeit eher wissensbasiert und verwaltet externe Abhängigkeiten als harte Kernarbeit mit Reihen von Leuten, die bis 2 Uhr morgens wütend auf Tastaturen tippen. Die meisten arbeiten solide 40 und gehen ungeachtet des Drucks nach Hause, weil oft langes Bleiben nicht früher echte Straßensperren beseitigt.
Ist es gültig und möglich, feste, unverrückbare Fristen in Scrum zu bewältigen?
Ja. Wir haben ein Projekt im Zusammenhang mit den Olympischen Spielen mit Scrum durchgeführt. Natürlich ist die Frist unverrückbar festgelegt. Daran ist nichts auszusetzen. Wir konnten den Umfang so anpassen, dass wir das, was erreicht werden konnte, rechtzeitig vor der Eröffnungszeremonie starten konnten. In Ihrem Fall scheinen Ihre Projektmanager auch flexibel genug zu sein, um passende Ressourcen zu finden. Sie können sich Mike Cohns Präsentation über die Anwendung von Agile auf „Fixed-Date, Fixed-Scope und Fixed-Everything-Projekte“ ansehen .
uns wird dann gesagt, dass wir eher den Aufwand (Story Points) als die Zeit schätzen sollen, weil die Organisation den Führungsauftrag hat, agil und Scrum zu sein
Die Schätzung in Story Points vorzunehmen ist der richtige Ansatz. Wenn Sie eine gute Referenz benötigen, lesen Sie Jeff Sutherlands Story Points: Warum sind sie besser als Stunden?
Wir teilen uns auf und führen eine detaillierte Schätzung der Story Points eines einzelnen Epos durch, normalerweise eine kleine Größe, dann werden die gesamten Story Points davon vergleichend verwendet, um die insgesamt angenommenen Story Points zu ermitteln.
Dies ist in dieser Phase des Projekts nicht ungewöhnlich. Im Laufe des Projekts erfahren alle (Entwicklungsteam und Product Owner) mehr über das Projekt. Und der Product Owner kann die Priorität entsprechend anpassen.
Der PM muss zeigen, wie viele Leute benötigt werden, damit diese Frist möglich ist, und wenn es zu teuer ist, kann das Projekt abgebrochen werden, bevor es überhaupt begonnen hat.
Das ist der richtige Geschäftsansatz. Wenn der Return on Investment (ROI) nicht da ist, warum das Projekt?
Von dort aus bestimmt der Projektmanager die Geschwindigkeit
Wenn der Projektmanager die Geschwindigkeit empirisch bewertet (basierend auf der tatsächlichen Geschwindigkeit, die das Team in 3 oder mehr Sprints erreicht hat), ist das in Ordnung. Sonst könnte es weit weg sein.
Darüber hinaus sind Sie in viele Spekulationen abgeschweift, ohne wesentliche Informationen zu behandeln, die uns helfen können, Ihren Prozess besser zu verstehen:
Agile unterstützt das Konzept fester Fristen. Sie priorisieren Ihren Rückstand und kommen bis zum Erreichen der Frist so weit unten in der Liste wie möglich.
Was Sie nicht tun können, ist sowohl die Zeit als auch den Umfang festzulegen.
Theoretisch können Sie Ressourcen variieren und Zeit und Umfang festhalten. Dies ignoriert jedoch die Schwierigkeit, Ressourcen hochzufahren. Wie das Gesetz von Brooks bekanntlich besagt: „Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später“. Um also Zeit und Umfang festzulegen und nur die Ressourcen zu variieren, müssten Sie in der Lage sein, potenzielle Verzögerungen weit im Voraus vorherzusagen.
Sie könnten auch argumentieren, dass Zeit und Umfang festgelegt werden können, wenn Sie eine große Menge an Ressourcen auf das Projekt werfen. Aber auch das kann scheitern, da der Output potenziell abnehmen kann, wenn die Anzahl der Personen am Projekt zunimmt und die Kommunikation zu einem Problem wird (das n+1-Problem).
Die Idee, Fristen zu setzen, um Menschen dazu zu bringen, „härter zu arbeiten“, wurde in informationsbasierten Industrien weitgehend widerlegt. Das Problem ist, dass es viele verschiedene Möglichkeiten gibt, ein Codierungsproblem zu lösen, und die schnellsten Lösungen sind häufig die schlechtesten in Bezug auf Qualität und zukünftige Erweiterbarkeit.
Vielleicht wäre Ihr bester Ansatz in dieser Organisation, vorzuschlagen, dass sie ein kleines Testprojekt nach agilen Prinzipien statt nach ihrem derzeitigen Ansatz durchführen. Vereinbaren Sie einige Metriken, die den Erfolg des Projekts messen, bevor es beginnt. Manchmal braucht es nur eine Erfolgsdemonstration, um sie für sich zu gewinnen.
Hinzu kommt, ich hochempfehlen, Mengen und Quellen für „auftauchende Arbeit“ (was auch immer nicht in der anfänglichen Rückstands- vs. Geschwindigkeitsberechnung enthalten war) zu verfolgen und dies kontinuierlich in Ihre Planung oder Ihren prognostizierten Umfang einzubeziehen. Damit meine ich Punkte für „unbekannte Unbekannte“ oder neue Backlog-Elemente, die bei jedem Sprint auftauchen, Punkte für Feedback, Punkte für Pivots aufgrund von Benutzertests, Punkte für standardmäßige „Hopplas, die größer waren, als wir dachten“. Meiner Erfahrung nach ist dies bei weitem der größte einzelne Bereich, der übersehen wird und Teams gegenüber dem Management in eine schlechte Position bringt, wenn es darum geht, ihre ursprüngliche Schätzung des Umfangs zu erreichen. Viele Agilisten werden sagen, wenn Sie die Geschwindigkeit messen, während diese Dinge passieren, wird sie einfach "in der Wäsche herauskommen", aber das ist '
Du bist nicht allein. Viele Unternehmen nennen sich agil, aber nur wenige sind es wirklich. Was seltsam klingt, ist, dass Ihr Unternehmen universelle Story Points benötigt, die für alle gelten. Story Points sind eine relevante Metrik, die nützlich ist, wenn ein Team eine gewisse Geschichte hat und seine Geschwindigkeit kennt. Ansonsten sind Story Points nur Zufallszahlen. Ich habe für ein ähnliches Unternehmen wie Ihres gearbeitet und versucht, sie über SCRUM aufzuklären. Nach ein paar Monaten der Frustration habe ich aufgegeben und gekündigt. Manchmal ist die Unternehmens- oder „das haben wir schon immer so gemacht“-Mentalität unveränderbar.
Sklivvz