Welche Art von Bewertungs-/Analysemodell sollte ich verwenden?

Ich wurde in eine Organisation gebracht, um deren Release Management zu verbessern. Vor ein paar Jahren durchliefen sie einen Übergang zur agilen Entwicklung. Ich habe zwei Workstreams: Run & Improve.

„Boots on the Ground“ (Run) mein Release-Management-Team stellt sicher, dass Sprints pünktlich ausgeführt werden, dass User Storys in Azure DevOps vorhanden sind, die Sprint- und Inkrementplanung im Allgemeinen erfolgt usw. Wir halten die Dinge so in Bewegung, wie sie es bei unserer Ankunft waren .

Höheres Niveau (Verbessern), mein Vorgesetzter würde eine Roadmap zur Verbesserung der Dinge begrüßen. Ich sammle Daten über jedes Team und wie sie ihre Sprints durchführen (Features/User Stories schreiben, Grooming (oder das Fehlen davon), Sprint-Planung (oder das Fehlen davon) usw.)

Also muss ich den aktuellen Zustand des Engineering-Prozesses beurteilen und Empfehlungen geben, wie er in Zukunft in einen besseren Zustand gebracht werden kann.

Zum Kontext führt ein Team wöchentliche Pflege durch. Ihre Geschichten sind gut geschrieben, mit allen Kriterien enthalten. Sie sind priorisiert, beinhalten aber nicht den erforderlichen Arbeitsaufwand, daher habe ich beobachtet, dass viele Geschichten auf zukünftige Sprints übertragen werden.

Ein anderes Team (das mehr als 10 Geschichten pro Tag hinzufügt) macht keine Pflege, hat eine schlechte Entwicklung der Geschichte (oft mit fehlenden Kriterien) und führt seine gesamte Sprintplanung in einem großen Meeting durch. Sie enthalten auch einen detaillierten Arbeitsaufwand auf Aufgabenebene, sodass ihre Schätzungen für die Arbeitsbelastung im Allgemeinen genau waren.

Andere Teams sind ähnlich wie oben.

Meine Frage ist, welche Bewertungs-/Analysemethode für diesen Bedarf am besten geeignet wäre? IE Es ist kein "5 Whys", aber vielleicht "SWOT"? Etwas anderes?

Antworten (2)

Wenn ich Ihre Situation richtig verstehe, suchen Sie nach einer Möglichkeit, Teams dabei zu helfen, darüber zu sprechen/zu analysieren/zu bewerten, welche Bereiche verbessert werden müssen, und den Personen, die diese Teams unterstützen (Manager, Trainer usw.), eine hochrangige Zusammenfassung dessen zu geben, was funktioniert und Was ist nicht. Auf dieser Grundlage würde ich Ihnen empfehlen, sich das Squad Health Check-Modell von Henrik Kniberg anzusehen .

Was dieses Modell im Wesentlichen macht, ist, dass Sie Workshops durchführen, in denen Mitglieder eines Teams ihre aktuelle Situation aus verschiedenen Perspektiven (Engineering-Prozess, einfache Freigabe, geeigneter Prozess, Spaß, Geschwindigkeit usw.) diskutieren und bewerten und eine grafische Zusammenfassung erstellen des Ergebnisses. Anschließend verwenden Sie die Daten, um den Teams zu helfen, sich zu verbessern, und die Personen außerhalb des Teams erhalten eine klare Visualisierung dessen, was funktioniert und was nicht.

Mit den Daten darüber, in welchen Bereichen sich die Teams verbessern müssen, könnten Sie eine Roadmap erstellen, welche Verbesserungen die Teams wann vornehmen wollen. Das Ergebnis der Zustandsprüfung ist in gewisser Weise eine Roadmap für sich, aber Sie können natürlich eine detailliertere Roadmap nach Ihren Wünschen erstellen, wenn dies ein gewünschtes Ergebnis ist.

Brillant! Das ist genau das, wonach ich gesucht habe – ein Reifegradmodell, aber eines, das wirklich zu dem passt, worauf ich hinaus will. Diesen Typ/Version habe ich noch nie gesehen.
@richardlpalmer freut mich zu hören, dass ich helfen konnte! Henrik Kniberg und seine Kollegen von blog.crisp.se haben viele gute Ideen für fast alles, was die Verbesserung von Unternehmen und Teams betrifft! Viel Glück für Sie!
Danke für den Link – ich habe ihn zu meinen Lesezeichen hinzugefügt. :)

Also muss ich den aktuellen Zustand des Engineering-Prozesses beurteilen und Empfehlungen geben, wie er in Zukunft in einen besseren Zustand gebracht werden kann.

Da dies ein agiles Umfeld ist, würde ich folgende Fragen stellen:

  • Können sich die Teams selbst nicht verbessern?
  • Sind die Teams befähigt, ihre eigenen Probleme zu lösen?
  • Ist das Arbeitsumfeld kooperativ?
  • Was denken die Teams selbst sind die Probleme?

Es wäre auch sinnvoll zu definieren, was Verbesserung für die Menschen in Ihrer Organisation bedeutet. Werden einfach mehr Codezeilen geschrieben? Ist es eine Steigerung der Zufriedenheit der Geschäftsanwender? Ist es die Geschwindigkeit, mit der die Teams auf Veränderungen reagieren?

Was ich vermeiden würde, ist, Ideen zu entwickeln, sie meinem Vorgesetzten vorzulegen und sie dann den Teams zu überlassen. Dies wird die Teams entmachten und es weniger wahrscheinlich machen, dass sie ihre Probleme in Zukunft selbst lösen. Bei Agilität geht es darum, Teams aufzubauen, die wissen, wie man prüft, sich anpasst und sich selbst verbessert.

Das stimmt definitiv mit dem überein, was ich mir vorstelle – auch um zu beurteilen, wo sie in Bezug auf Agile Best Practices stehen. Ich neige dazu, SWOT für jedes Team durchzuführen und sie dann in einer allgemeineren Analyse zusammenzufassen, was die Art von Analyse ist, die ich herauszufinden versuche. Vielleicht PEST (Political, Economic, Social and Technology), da es gut mit SWOT funktioniert. Ich halte weder eine RCA (Root Cause Analysis) noch Porters Five Forces für angemessen. Ich bin mir immer noch etwas unsicher, welches Framework ich für die Präsentation verwenden soll ...
Ich fürchte, dass ich mit diesen Frameworks nicht vertraut bin. Mein Ansatz ist in der Regel das typische Format einer Scrum-Retrospektive, die es dem Team erleichtern soll, seine eigenen Probleme zu identifizieren, sie zu priorisieren und sich dann auf ein oder zwei zur Lösung zu konzentrieren.
Oskars Antwort war schließlich perfekt für mich. Danke aber nochmal!