Gibt es ein gutes Modell für die Wahl eines agilen Vorgehens?

Ich weiß nicht viel darüber, wie man Methoden auswählt (ich habe immer Scrum als Grundlage verwendet und es auf die spezifischen Bedürfnisse des Projekts und der Organisation zugeschnitten), aber bitte beachten Sie, dass Agilität eher eine Denkweise als ein Projekt ist.

Wenn Sie agile Methoden in einer neuen Organisation einführen möchten, sind die wichtigsten Punkte:

• Teammitglieder müssen bevollmächtigt und für das Ergebnis verantwortlich gemacht werden (in den meisten Fällen ist keine Genehmigung durch höhere Behörden erforderlich – zum Beispiel muss die PO in der Lage sein, den Umfang zu ändern, ohne den Sponsor einzubeziehen)
• Das Engagement der gesamten Organisation ist erforderlich, damit auch nur ein einzelnes Team agil sein kann (ein Beispiel: Wir konnten unseren ersten Sprint nicht starten, weil die Sicherheitsabteilung die Teammitglieder nicht autorisiert hat, Schlüssel für den Entwicklungsraum für 2 Wochen zu erhalten)
• Es ist kein Marathon, es ist ein Sprint - Sie müssen kontinuierlich Energie reinstecken, es gibt keine langsameren Phasen (keine Zeit für Ihre anderen Aufgaben - wenn Sie zu 100% im Projekt sind, passt keine andere Arbeit in deinen Zeitplan)
• Nehmen Sie Veränderungen an – erwarten Sie, dass Vereinbarungen, die gestern getroffen wurden, überarbeitet und möglicherweise morgen rückgängig gemacht werden, machen Sie kein Aufhebens darum
• Seien Sie flexibel in Bezug auf das Ergebnis – was Sie sich vorstellen, ist möglicherweise nicht das, was Sie nach ein paar Änderungen erhalten werden
• Und ganz wichtig: Vertrauen Sie den anderen Teammitgliedern – Sie sollten keine Unternehmenspolitik oder Machtspiele betreiben, Sie sitzen im selben Boot

Wenn Sie das Glück haben, dass diese Punkte akzeptiert (und von Ihrer Organisation unterstützt) werden, ist die konkrete Methodik eigentlich ziemlich irrelevant.

Wenn Ihre Organisation, wie Sie sagen, extrem bürokratisch und wasserfallorientiert ist, würde ich nicht zu viel Zeit damit verschwenden, darüber nachzudenken, was zu tun ist, und stattdessen anfangen, etwas zu tun:

1. Finden Sie ein zu lösendes Problem
2. Finden Sie heraus, wie Sie es lösen können
3. Wenden Sie Ihre Lösung an
4. Prüfen und anpassen

Oder, wie Dave Thomas vorschlägt :

So gehen Sie agil vor:

Was zu tun ist :

Finden Sie heraus, wo Sie sind

Machen Sie einen kleinen Schritt in Richtung Ihres Ziels

Passen Sie Ihr Verständnis basierend auf dem an, was Sie gelernt haben

Wiederholen

Wie es geht :

Wenn Sie mit zwei oder mehr Alternativen konfrontiert sind, die ungefähr den gleichen Wert liefern, gehen Sie den Weg, der zukünftige Veränderungen einfacher macht.

Tun Sie dies gemeinsam mit Ihrem Team, lassen Sie die Methodik Hand in Hand mit dem Engagement der Mitarbeiter wachsen, insbesondere wenn Sie dauerhafte Ergebnisse erzielen möchten.

Ach und viel Glück ;)

Sozusagen nicht wirklich eine Antwort, aber ich würde vorschlagen, dass Sie sich diesen sehr interessanten Vortrag von Yuval Yeret ansehen: "Good and bad ways to kickstart agile the Kanban way" . Er stellt vor, wie man die Einführung von Agile mithilfe von Kanban vorantreibt, wobei jede kleine Änderung als Option betrachtet wird, und gibt einige gute Ratschläge zum Änderungsmanagement auf Kanban-Art.

Außerdem können Sie zum selben Thema auch ein Interview mit Yuval Yeret von Ben Linders lesen.

(Quellen: infoq.com)

Erstens – Bei der agilen Softwareentwicklung geht es darum, Ihren Prozess an Ihre Bedürfnisse anzupassen. Scrum ist nicht agil, Kanban ( JIT ) ist nicht agil. Es ist Ihr Team , Prozesse zu ändern oder eigene Prozesse zu entwickeln, die zu Ihrer Situation passen – das bedeutet Agilität.

Heutzutage gibt es unter den Methoden ein klares Verständnis dafür, was schneller ist und in besserer Qualität auflöst. Es hängt von Ihrer Qualifikation, Ihrem Team und Ihrer Organisation ab, was Sie tatsächlich anwenden können:

1. Continuous Delivery ist heute die erste Wahl. Sie können für PRD freigeben, auch wenn Funktionen noch nicht fertig sind (es gibt Techniken, die es ermöglichen, diese Änderungen zu verbergen). Aber Sie brauchen jemanden, der darin Erfahrung hat, damit es funktioniert. Und es kann zu einer schlechteren Qualität als die nächste Wahl führen, wenn Sie ein schwaches Entwicklerteam haben.
2. Just-in-time , Theory of Constraints – damit geben Sie jede Aufgabe frei (oder gruppieren sie in kleinen Batches). Wenn Sie nicht stark in CD sind, ist dies die beste Option, um damit zu beginnen. Es ist ein bisschen langsamer als CD und schneller als Scrum und führt zu einer sehr guten Qualität.
3. Scrum – es basiert auf Iterationen und hat viele zusätzliche Aktivitäten. Dies führt also zu einer geringeren Qualität und einer langsameren (viel langsameren) Entwicklung. Aber es ist immer noch viel besser als Waterfall.

Diese schließen sich nicht immer gegenseitig aus. Nochmals - Ihre Situation muss höchstwahrscheinlich geändert werden. Und Prozesse müssen nicht statisch sein – Sie können sie je nach aktueller Stimmung im Team hin und her ändern.

Ich würde vorschlagen, dass Sie es einfach halten und diesen Schritten folgen :)

1. ein Team zusammenstellen
2. Erstellen Sie ein Produkt-Backlog
3. schätzen Sie Ihren Rückstand
4. Kick eines Sprints oder einer Iteration

dann prüfen, anpassen und wiederholen!

Viel Glück :)