Ist Scrum nicht mit öffentlichen Ausschreibungen vereinbar?

43

Ich wurde von einer öffentlichen Organisation gebeten, einen informellen Workshop über die agile Entwicklung abzuhalten, in dem Begriffe und Konzepte von Scrum, Kanban und dergleichen erläutert wurden. Ich arbeite seit ungefähr fünf Jahren in agilen Umgebungen, aber ich sehe mich nicht als Scrum-Evangelist.

Nach dem Workshop gefiel ihnen die Idee. Sie erklärten jedoch, dass der Ansatz wahrscheinlich nicht auf sie zutreffen würde, da sie externe Softwareunternehmen beauftragen müssen, Software für sie zu entwickeln (sie haben nur wenige Entwickler selbst). Diese Aktivität muss in einem öffentlichen Ausschreibungsverfahren durchgeführt werden, das das Ergebnis, den Preis und den Zeitrahmen beschreibt. Dies ist eine rechtliche Voraussetzung, um ein Budget für diese Organisation (ein öffentliches Forschungsinstitut) zu beantragen.

Diese Einschränkungen stehen in gewissem Widerspruch zu den Grundprinzipien der agilen Entwicklung, nicht wahr?

Ist Scrum in einer solchen Umgebung einfach nicht kompatibel?

Was würden Sie dieser Organisation empfehlen?

Bakoyaro
quelle
1
Wenn Ergebnis, Preis und Zeitrahmen im Voraus festgelegt werden können, warum sollte man sich dann um einen agilen Prozess kümmern?
JeffO
3
Scrum ist per Definition mit allem kompatibel. Das Paradigma "Das Team besitzt den Prozess" ermöglicht es, den Prozess radikal zu ändern, sodass Scrum bei Bedarf zu einem Wasserfall wird. "Beweglich" zu sein bedeutet NICHT, dass Sie einem Prozess ohne Abweichung folgen müssen. Dies bedeutet, dass der Prozess an die Bedürfnisse angepasst werden kann. Beachten Sie, dass dieser Punkt für das Management EXTREM unbeliebt ist - sie wollen feste Prozesse und sie nennen alles "agil", wenn sie auf Agile / Scrum / Whatever festgelegt wurden.
Klaws
3
FWIW, IME, ich habe noch nie etwas gesehen, was Sebazzz beschreibt. Der Vertrag sieht ausdrücklich vor, was geliefert werden muss. Wenn es die Anforderungen nicht erfüllt, sind Sie noch nicht fertig. Und das ist das ganze Problem mit den agilen Methoden "Liefern, was Sie haben, wenn das Geld ausgeht". Es kommt selten vor, dass Sie ein Produkt liefern können, das nur einen Teil der vom Kunden benötigten Leistungen erbringt und für den Kunden tatsächlich von Wert ist. Normalerweise ist das das Gleiche wie es überhaupt nicht funktioniert. Abweichungen können angefordert werden, aber wenn diese Abweichung die Funktionalität beeinträchtigt, ist dies mit ziemlicher Sicherheit mit weniger Geld verbunden
Dunk
2
@ CortAmmon-Was ich von der Regierung gesehen habe, ist "klug", aber nicht wirklich wendig. Sie folgen im Wesentlichen immer noch dem Wasserfall und vergeben den Auftrag in Phasen anstelle des gesamten Entwicklungsaufwands über den gesamten Lebenszyklus wie in der Vergangenheit. Insbesondere in der Engineering-Phase ist es für sie anfälliger, mehr als einen Auftragnehmer einzustellen, da sie auf diese Weise wettbewerbsfähig die beste Lösung auswählen können, die sie zu einem herstellbaren Produkt machen möchten. Diese letzte Phase ist die teuerste. Sie wollen sehen, was sie bekommen, bevor sie sich für die Herstellung entscheiden. Ein teilweise funktionierendes Produkt wird nicht gewinnen.
Dunk

Antworten:

38

Scrum ist für diese Organisation wahrscheinlich nicht geeignet.

Im Scrum-Leitfaden heißt es: "Scrum ist ein Framework für die Entwicklung, Bereitstellung und Pflege komplexer Produkte." Es ist auch für ein Team von 3-9 Mitgliedern eines Entwicklungsteams konzipiert, die an dem Produkt arbeiten, einen Product Owner und einen Scrum-Master (der möglicherweise nicht im Entwicklungsteam ist) für insgesamt 4-11 Personen.

In Bezug auf die interne Entwicklung erwähnen Sie, dass sie nur wenige Entwickler haben. Wenn ein Team nicht groß genug ist, um ein Scrum-Team zu bilden, ist es nicht sinnvoll, Scrum vollständig zu verwenden. Einige Scrum-Methoden können jedoch für die Organisation hilfreich sein.

Für die Auftragsentwicklung ist es einer der externen Parteien möglich, Scrum zu verwenden. In diesem Fall ist es für das Forschungsinstitut hilfreich, die Scrum-Praktiken zu kennen und die Rollen und ihre Funktionsweise zu verstehen. Möglicherweise müssen sie noch die Besonderheiten der Verwendung von Scrum-Praktiken und anderer Praktiken durch die externe Entwicklungsorganisation verstehen, aber es kann ihnen dabei helfen, die Funktionsweise zu verstehen. B. die Notwendigkeit zu verstehen, an Sprint Reviews teilzunehmen oder mit der Organisation (wahrscheinlich deren Product Owner) bei der Bestellung des Product Backlogs zusammenzuarbeiten.

Thomas Owens
quelle
Hervorragende Antwort. Es ist sehr schwierig, wenn auch nicht unmöglich, Organisationen wie die vom OP beschriebenen zu einem agilen Ansatz zu bewegen.
Herr Positive
1
@MisterPositive Möglicherweise benötigen Sie das Forschungsinstitut nicht, um agil zu werden. Sie müssen jedoch wahrscheinlich in der Lage sein, mit externen Stellen zu interagieren, die bei der Vergabe eines Vertrags agil sind. Sie können mit Sicherheit die Vorteile von Agilität erkennen.
Thomas Owens
Das wirklich Gute an dieser Antwort ist meiner Meinung nach, dass es nicht in die Falle gerät, über Scrum zu streiten, das nicht geeignet ist, weil "Ergebnis, Preis und Zeitrahmen" festgelegt sind.
Doc Brown
1
@DocBrown Vielleicht, weil Scrum verwendet werden kann, wo der Preis und der Zeitrahmen festgelegt sind. Meiner Erfahrung nach stellen sie fest, dass es sich bei dem, was sie ursprünglich für nötig hielten und was sie wirklich brauchen, um zwei verschiedene Dinge handelt, wenn Sie den Stakeholdern schnell etwas zeigen. Und dann ändern sie das gewünschte Ergebnis innerhalb des ursprünglichen Preis- und Zeitrahmens.
Thomas Owens
Zustimmen. Software ist nicht so, als würde ein Architekt ein Gebäude entwerfen. Es ist von Natur aus ein sich bewegendes Ziel, bei dem der Boden immer unter Ihren Füßen davonrutscht. Nächstes Jahr sehen die Bemühungen des letzten Jahres passe aus.
22

18F, eine Agentur für digitale Dienste innerhalb der US-Regierung, hat viel daran gearbeitet, wie die Regierung Verträge abschließen kann, um die gesetzeskonforme Anwendung agiler Methoden zu ermöglichen. Dabei wurden allgemeine Ergebnisse und keine detaillierten Anforderungen an die Arbeitsweise festgelegt ist zu tun. Einige ihrer Ressourcen umfassen:

Ein Vorteil von agilen Arbeitsmethoden besteht darin, dass sie sich darauf konzentrieren, eine Lösung für ein Problem zu finden, nachdem der Auftrag vergeben wurde, dh während der Ausführung nach der Vergabe, anstatt die Detaillösung im Voraus wie in Teil 15 zu spezifizieren. Ein agiler Vertrag versucht dies Spezifizieren von Problemen, die detaillierte Lösungen erfordern, häufig als Product Backlog-Elemente, die Vertragslieferbereiche auf hoher Ebene beschreiben.

Um dieses Problem zu verstehen, wies das Amt für Verwaltung und Haushalt und das Amt für Beschaffungspolitik die Behörden an, die Verwendung von Leistungsnachweisen einzustellen und einen Leistungsnachweis (Performance Work Statement, PWS) für den Erwerb von Dienstleistungen zu verwenden. Ein PWS "sollte Anforderungen in allgemeinen Begriffen angeben, was (Ergebnis) zu tun ist, und nicht, wie (Methode) es zu tun ist". Gute Vertragsbedienstete weisen die Agenturen darauf hin, dass Sie durch den Kauf von Expertendiensten nicht über die besten Kenntnisse verfügen Wie wird gearbeitet? Als Missionsinhaber sind Sie der Experte für das, was erreicht werden muss, aber das Zusammenführen der beiden gefährdet Ihre Mission und erschwert es einem Vertrag, einen Mehrwert zu erzielen.

Im Grunde ist der Ansatz eher so, als würde man einen Dienstleister beauftragen, mit Ihnen zusammenzuarbeiten, um eine Lösung zu entwerfen, anstatt Seiten mit detaillierten Spezifikationen im Voraus aufzulisten. Die Institution würde keinen Architekten beauftragen, ein neues Gebäude zu entwerfen, indem sie auflistet: "Das Design muss vier Stockwerke mit einer Dachneigung von 37º haben. Die dritte Etage muss eine 22 Quadratmeter große Küche mit vier Leuchtstofflampen haben, die durch eine Bewegung gesteuert werden -empfindlicher Lichtschalter in einer abgehängten Decke. " Vielmehr hätten sie einen Vertrag, mit dem der Architekt in Absprache mit dem Kunden Planungsleistungen erbringen und sich darauf verlassen kann, dass der Lieferant, ein Fachmann auf diesem Gebiet, die daraus resultierenden Leistungen erbringt.

Obwohl die Einzelheiten von der Institution und den geltenden Beschaffungsrichtlinien und -gesetzen abhängen, zeigt dies, dass es trotz aller Misserfolge bei großen IT-Projekten der Regierung Gruppen gibt, die daran arbeiten, öffentliche Ausschreibungen für die Softwareentwicklung auf modernere agile Methoden umzustellen. bei genügend politischem Willen und vertrauenswürdigen Entwicklungspartnern. Die Art und Weise, wie solche Projekte konzipiert und verwaltet werden (einschließlich einer großen Menge an laufender Zeit, die während des gesamten Prozesses Benutzerfeedback liefert), die die Organisation möglicherweise verfolgen möchte oder nicht.

Zach Lipton
quelle
3
Dies ist eine großartige Antwort, insbesondere die letzten beiden Absätze. Dies ist wirklich eine großartige Möglichkeit, Dinge, die ich nicht in der Lage war, zusammenhängend zusammenzusetzen.
Thomas Owens
1
Ja, das ist die Antwort. Der Vertrag und wie er geschrieben wurde, ist das Problem. Ich kann weder bestätigen noch leugnen, dass ich irgendwann in meinem Leben für eine solche Organisation oder eine ähnliche Organisation gearbeitet habe, und als sie auf einen ergebnisorientierteren Vertrag umgestiegen sind, hat die agile Entwicklung begonnen, sich wie ein Lauffeuer auszubreiten.
Greg Burghardt
Es hört sich also so an, als müsse der Architekt zuerst beim Verfassen des Angebots behilflich sein, bevor es budgetiert und mit einem Zeitrahmen versehen werden kann. Es ist ein zweiphasiger Prozess, mit dem zweiten Satz: "Du,
12

Es klingt typisch. Sobald das Angebot schriftlich vorliegt, sind die Angebote eingegangen und einer der Bewerber hat den Zuschlag erhalten ... Soweit es die Vertreter der öffentlichen Organisation betrifft, ist das Projekt abgeschlossen.

Deshalb scheitern so viele dieser Projekte. Nachdem sie das Budget weit überschritten hatten.

Der Punkt, den sie vermissen (oder den sie zumindest nicht für wichtig halten), ist, dass sie Stakeholder sind, die an Meetings und Demos teilnehmen sollten.

Es gibt also keinerlei Konflikte mit Agile oder Scrum. Es sind Menschen, die ihre Rollen nicht übernehmen. Es ist die Art und Weise, wie die Regierung arbeitet, die dies verursacht.

Es ist nicht so, als würden wir dieses System gerne haben, und wir sind bereit, uns etwas Mühe zu geben und zu sehen, wie weit wir es bringen können.

Nein. Es ist, als ob "unsere Demokratie entschieden hat, dass wir dieses System bis dahin haben werden". Das lässt keinen Raum zwischen 100% Erfolg auf der einen und 100% Misserfolg auf der anderen Seite. Von Anfang an zum Scheitern verurteilt.

Es ist auch eine Einladung an den Markt, um lächerliche Preise zu bitten. Das Projekt nicht durchzuführen, weil es zu teuer ist, ist keine Option. Die Entscheidung, dies zu tun, wurde bereits getroffen, bevor das Angebot geschrieben wurde.

Fair genug, selbst wenn die Stakeholder ihre Rollen übernehmen würden, wären sie völlig machtlos. Keiner von ihnen hätte aus dem gleichen Grund einen glaubwürdigen Anhaltspunkt für diese Demos.

Martin Maat
quelle
5
Dies beantwortet die Frage nicht wirklich. Was würden Sie dieser Organisation empfehlen?
Philipp
9
Ist das nicht ein Klischee gegen Regierungen, das für alle Misserfolge verantwortlich ist, mehr als eine konstruktive Antwort? Ich weiß es nicht in Ihrem Land, aber in meinem Land gibt es viele erfolgreiche Regierungsprojekte. Ich werde Ihre Meinung nicht ändern können, aber hier ein interessanter Artikel, der auf objektiven Fakten und unabhängigen Beobachtungen basiert: mckinsey.com/industries/public-sector/our-insights/…
Christophe
6
"Deshalb scheitern so viele dieser Projekte. Nachdem sie das Budget weit überschritten hatten". Diese Trope wird immer wieder von Leuten beansprucht, die agile Prozesse forcieren. Und doch gibt es eine Menge erfolgreicher Entwicklungsunternehmen, die keine der vorgeschlagenen agilen Methoden anwenden. Sie neigen dazu, dies ohne Probleme zu tun. Wenn überhaupt, ist das eigentliche Problem die Gewohnheit, den billigsten Bieter anzuwerben und die bisherige Leistung und Fachkompetenz nicht genügend in den Vordergrund zu stellen. Schuld daran ist ein roter Hering. Erfolg kann von jedem kompetenten Team mit jedem vernünftigen Verfahren erzielt werden, mit dem es vertraut ist.
Dunk
OK, ich bin ein bisschen mitgerissen worden. Ich würde weiterhin empfehlen, die Fortschritte zu überwachen und diese Stakeholder-Rolle zu übernehmen, nachdem der Vertrag unterzeichnet wurde, vorausgesetzt, es liegt im besten Interesse aller, Ergebnisse zu erzielen. Und ich behaupte nicht, dass Agilität der Schlüssel ist. Ich behaupte, dass es keinen Konflikt mit den Prinzipien von Agilität gibt, und wies auf ein gemeinsames zugrunde liegendes Problem hin.
Martin Maat
Betreff: "Vorausgesetzt, es liegt im besten Interesse aller": Wo ich lebe, ist ein sehr teures langfristiges Projekt (für eine Erweiterung des Versorgungsnetzes) gescheitert. Unternehmen) und die Behörde des öffentlichen Dienstes, die möglicherweise rechtswidrige Gesetze erlassen hat, und die Kunden, von denen erwartet wird, dass sie alle retten. In der Regierung sollte so etwas nicht passieren, es liegt im Interesse aller Beteiligten, lebensfähig zu bleiben, ethisch zu handeln und das zu halten, was sie versprochen haben. Ich bin nicht sicher, ob Prozesse dabei helfen können oder nicht.
12

Nein, SCRUM ist nicht mit öffentlichen Ausschreibungen unvereinbar. Sie müssen explizit angeben, was Sie in einer öffentlichen Ausschreibung kaufen.

"Der Käufer möchte von einem erfahrenen SCRUM-Team, das aus 5 Entwicklern und einem zertifizierten SCRUM-Meister besteht, 10 2-wöchige Sprints der Entwicklung kaufen. Die Sprints werden von März 2018 bis Juli 2018 laufen." Beginn der Ausschreibung. Natürlich müssen Sie die erforderlichen Teamfähigkeiten auflisten und eine Vorstellung von dem Projekt geben, an dem sie arbeiten werden. Es ist jedoch durchaus akzeptabel, eine Ausschreibung zu haben, um ein Team einzustellen.

Natürlich verzichten Sie hier auf den "festen Anwendungsbereich". Das ist schließlich typisch für SCRUM. Mit etwas mehr Wortlaut in der Ausschreibung (aber wir betreten hier rechtliches Gebiet) können Sie eine kleine Bereichserweiterung zulassen, dh eine kleine Anzahl zusätzlicher Sprints. Wenn Sie jedoch nach den ersten 10 Sprints weitere 10 Sprints wünschen, müssen Sie wahrscheinlich eine erneute Ausschreibung vornehmen.

MSalters
quelle
3
Genau ! Dies ist eine ausgezeichnete und genaue Antwort. In diesem Webinar unter projectmanagement.com/videos/290684/… erklärt ein Beamter der US-Regierung ausführlich, wie es funktioniert. Das Prinzip der Verlagerung des Zwecks des Angebots vom Endprodukt zum Entwicklungsdienst kann in ähnlicher Weise auch in vielen anderen Vergabegesetzen geregelt werden. Die Hauptschwierigkeit liegt hauptsächlich in der manchmal konservativen Haltung einiger Interessengruppen und nicht in einer so genannten Unvereinbarkeit.
Christophe
1
Also würden sie das billigste Scrum-Team einstellen, das sie finden können, und wenn das Projekt mehr Stunden benötigt, stellen sie das zweitbilligste Team ein, um die mittlere Entwicklung zu übernehmen? Dieser Ansatz setzt voraus, dass der Kunde die Qualität des von ihm eingestellten Softwareteams beurteilt. Wenn sie über solches Fachwissen verfügen, frage ich mich, was sie brauchen, um den Vertrag überhaupt auszulagern?
Meriton - Streik
@meriton: Die meisten Ausschreibungen werden von der Regierung durchgeführt. Dies ist normalerweise erforderlich, um das günstigste qualifizierte Angebot zu verwenden. SCRUM ändert das nicht. SCRUM versetzt den Product Owner jedoch in eine aktive Rolle, was hier hilfreich ist.
MSalters
Wenn Sie jedoch einen Vertrag abschließen, ändert SCRUM die Anreize für den Dienstleister. Sie können nicht länger dafür verantwortlich gemacht werden, dass sie die Anforderungen nicht erfüllen. Ihr einziger Anreiz besteht darin, den Preis zu senken und gleichzeitig den Buchstaben der Qualifikationskriterien zu erfüllen, aber nicht notwendigerweise ihren Geist. Für den Käufer ist es einfacher zu beurteilen, ob die Software den Anforderungen entspricht, als ob das Team wahrscheinlich Software produziert, die diese Anforderungen erfüllt. Aber ja, Ihr Ansatz ist eine der besten Möglichkeiten, SCRUM im öffentlichen Sektor einzusetzen. Ich wollte nur erwähnen, warum Käufer es möglicherweise nicht übernehmen möchten.
Meriton - Streik
9

Es ist schwierig.

Offensichtlich können Sie die Arbeit nicht mit einem unbefristeten Budget anbieten. Sie müssen sich also ansehen, was zu tun ist und wie viel Aufwand dafür erforderlich ist.

Der Grund, warum viele Softwareprojekte scheitern, liegt in der Tatsache, dass Fehlerbehebung, Zeitaufwand und Umfang von vornherein sehr fehleranfällig sind. Beispielsweise ist eine Spezifikation, wie sie in einem Angebot angegeben ist, fast immer mehrdeutig.

Es gibt also ein grundlegendes Problem nicht nur bei der Agilität, sondern auch bei der Konzeption offener Ausschreibungen für die Softwareentwicklung. Die Chancen, dass jemand in der von Ihnen festgelegten Zeit genau das schafft, was Sie wollten, sind gering.

Wenn Sie etwas Flexibilität zulassen, können Sie dies verbessern.

Es hört sich so an, als sei der Prozess der öffentlichen Ausschreibung nicht flexibel. Sobald jedoch der Vertrag gewonnen ist, können Sie feststellen, dass es Spielraum gibt. Sie könnten beispielsweise ein agiles Arbeiten zulassen, müssten jedoch akzeptieren (und eine gesetzliche Genehmigung einholen), dass dies den Umfang beeinträchtigen könnte.

Jetzt glaube ich, dass dies zu einem besseren Produkt führen würde, da Sie frühzeitig sehen können, was passiert, und Änderungen vornehmen können, bevor sie in das Produkt eingebrannt werden. Enge Rückkopplungsschleifen und eine iterative Entwicklung können dazu führen, dass Produkte besser an die tatsächlichen Anforderungen angepasst werden (was möglicherweise nicht das ist, was ausgeschrieben wurde).

Jeremy French
quelle
3
+1 Ich kann nicht zählen, wie oft die Arbeit erledigt wurde, weil jemand einen erkennbar schlechten Vertrag angenommen und diese Verbindung verwendet hat, um den Vertrag in etwas zu verkaufen, das näher an dem liegt, was der Kunde eigentlich wollte.
Cort Ammon
1
Lassen Sie mich dies hervorheben - diese Antwort besagt, dass Scrum nicht mit öffentlichen Ausschreibungen unvereinbar ist, sondern mit vertragsbasierter Softwareentwicklung im Allgemeinen . Nicht, dass ich nicht zustimme.
Doc Brown
3

Kommt drauf an, aber wahrscheinlich schon.

Ich bin bereit zu wetten, dass jeder, der jemals mit einer Regierung an einem IT-Projekt gearbeitet hat, weiß, dass in der Praxis die in der Ausschreibung beschriebenen „harten Grenzen“ niemals alle eingehalten werden. Die Dinge gehen in der Regel über das Budget hinaus, verzögern sich und / oder der Umfang wird geändert. Normalerweise mehrere davon. Wenn die Regierungen bereit sind, zuzugeben, dass dies die Wahrheit ist, und bereit sind, sie wie die Richtlinien zu behandeln, die sie sind, dann kann scrum wirklich gut funktionieren.

Aus persönlicher Erfahrung (sowohl in meinem eigenen als auch in meinem beruflichen Netzwerk) weiß ich, dass sich die Anforderungen in den meisten Regierungsprojekten häufig ändern. Auch die zuständigen Gremien haben tendenziell viel Feedback, wenn sie sich am Ende eines Projekts endlich einbringen. Dies sind Probleme, für die Scrum gut geeignet ist.

Dies würde jedoch ein grundlegendes Umdenken der Regierungen und ihrer Behörden erfordern. In den meisten Ländern ist es sehr unwahrscheinlich, dass diese Änderung jemals stattfinden wird. Bis dahin sind öffentliche Ausschreibungen weiterhin nicht mit der Zusammenarbeit mit Scrum vereinbar. (Für diese Angelegenheit in meine persönliche Meinung wird öffentliche Ausschreibungen weiterhin mit inkompatibel sind jegliche nachhaltige Software - Entwicklung Praktiken, aber das ist eine andere Sache für eine andere Zeit ...)

Cronax
quelle
Ich wollte einen Kommentar wie Ihre letzte in Klammern
3

Was würden Sie dieser Organisation empfehlen?

An dieser Stelle nichts.

Was hier fehlt, ist die Geschichte, welche Probleme der aktuelle Prozess verursacht. Scrum ist nicht blind zu empfehlen. Es hat einen Punkt. Es ist keine Einheitsgröße.

Fragen Sie sie, welche Probleme sie durch ihren aktuellen Prozess verursacht haben. Hör mal zu. Empfehlen Sie nur Methoden, die sich mit ihren eigentlichen Problemen befassen. Sie werden in Richtung ihres gegenwärtigen Prozesses voreingenommen sein. Zunder scheinen einen Entwicklungsprozess zu diktieren, aber sie tun es nicht. Sie diktieren einen Lieferprozess. Aber das ist eine Unterscheidung, die dieses Team wahrscheinlich noch nie zuvor treffen musste.

Agile funktioniert am besten, wenn sich die Anforderungen über die Laufzeit des Projekts um mehr als 3% ändern. Ansonsten ist der Wasserfall immer noch sehr effektiv. Es wird noch heute an vielen Orten verwendet. Und natürlich formalisieren viele erfolgreiche Entwickler ihren Prozess nie so oder so. Informell funktioniert gut, wenn es um technische Probleme geht, nicht um die Menschen.

Sprechen Sie mit ihnen über ihren aktuellen Prozess und die damit verbundenen Probleme. Erzählen Sie ihnen, womit diese Methoden helfen. Aber wenn es nicht kaputt ist, beheben Sie es nicht.

kandierte_orange
quelle