Hat Scrum irgendwelche Vorteile bei der Vergabe von Verteidigungsaufträgen?

12

Gestern beim Wasserkühler mitgehört: "Scrum hat keinen Platz im Defence Contracting."

Ich bin eher anderer Meinung, da ich glaube, dass Scrum für viele Szenarien maßgeschneidert werden kann und ich sehe, dass Verteidigung eine davon ist. Dies löste eine große Debatte unter meinen Kollegen aus (viele von uns arbeiten im Bereich der Vertragsverteidigung) mit einer ziemlich ausgeglichenen Aufteilung für / gegen.

Um dies zu einer richtigen Frage zu machen: Hat jemand Scrum in einer verteidigungsvertraglichen Situation erfolgreich eingesetzt (oder hat Erfahrung damit)? Was hat gut funktioniert, was hat nicht gut funktioniert und welche (wenn überhaupt) Modifikationen an Vanille-Scrum haben Sie vorgenommen?

development-process scrum development-methodologies

— Sean Madden
quelle

3

Agile ist bestrebt, Abfälle zu entfernen. Organisationen, die mit Agilität erfolgreich sein wollen, müssen sich an diesem Ziel ausrichten. Politische Organisationen tendieren dazu, andere Prioritäten zu setzen.

— Martin Wickman

5

"Scrum hat keinen Platz im Verteidigungsgeschäft."

Nach meiner Erfahrung ist das Haupthindernis der Kunde. Die meisten Regierungsbehörden haben das Wasserfallmodell in ihrer DNA. Sogar Verträge werden in Wasserfallphasen abgeschlossen - zuerst werden die Anforderungen, dann das Design und dann die Implementierung finanziert. In der klassischen Wasserfalltheorie denken sie vielleicht sogar, dass sie verschiedene Unternehmen dazu bringen können, verschiedene Phasen zu absolvieren.

Es gibt Möglichkeiten, das zu umgehen, obwohl IMO. Machen Sie eine Vorabanforderung und gestalten Sie wie ein Wasserfall. Teilen Sie dann in der Implementierung die Anforderungen in iterative User Stories auf. Verwenden Sie interne Test- / Expertenbenutzer, um jede Iteration zu bewerten. Je nach Kunde sind sie möglicherweise an einer Teilnahme interessiert oder nicht. Kein reines Gedränge, aber es ist vielleicht das Beste, was Sie tun können.

— Doug T.
quelle

3

Ich habe als Praktikant für drei Teams in einem Air Force Reseach Labor gearbeitet, einmal in der Entwicklung von Produktionssoftware, einmal im Rapid Prototyping und ein drittes Mal in der Überprüfung und Validierung von Vertragsarbeiten. Beide Entwicklungspositionen waren agil. Tatsächlich lag die Produktionsposition sehr nahe bei Scrum, mit weniger Kundeninteraktion (Software wurde alle paar Iterationen geliefert, Kunde vor Ort alle 3 bis 6 Monate), und dies war im Jahr 2006. Ich stimme zu, dass der Kauf und das Verständnis der Kunden am größten sind Problem, aber einige Regierungsbehörden (oder zumindest Teams) befürworten in der Tat agile Methoden.

— Thomas Owens

@ Thomas Owens Dieser Kommentar wäre eine gute Antwort.

— Hugo

1

Während es schwierig sein kann, Scrum vollständig zu implementieren, kann es vorteilhaft sein, einige der Scrum-Praktiken zu übernehmen. Egal, wie Sie beispielsweise Anforderungen sammeln, Sie können immer noch häufig Releases und Demos erstellen. Sie können immer noch von regelmäßigen Retrospektiven profitieren. Schauen Sie sich andere Prozesse wie Lean oder Kanban an und prüfen Sie, ob sie auch Ihrem Team helfen können.

Überlegen Sie sich, wie Sie den Prozess spezifisch für Ihr Team, Ihr Projekt und Ihre Branche verbessern können, anstatt dogmatisch einem Prozess zu folgen. Prozessangelegenheiten . Die Methodik eines Teams hat großen Einfluss auf die gelieferte Software.

— Epotter
quelle