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?

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.

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:

• Verbesserung der Regierungsergebnisse durch ein agiles Vertragsformat
• Kaufvertrag für Agile Blanket
• Modular Contracting (Aufteilen großer Projekte in kleinere modulare mit agiler Entwicklung)
• Verwendet Ihr Projekt "agilefall"?

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.

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.

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.

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

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

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.