Ich coache derzeit ein Nicht-Entwicklungsteam in Scrum-Praktiken. Das Team konzentriert sich auf Backoffice- und Verwaltungsprozesse. Dies macht die Arbeit zu einer Art Pull-Warteschlange, in die Kanban besser passen würde, wenn die tatsächliche Fertigstellung des Arbeitsergebnisses keine externen Auswirkungen auf das Team wäre; So wie es ist, wurde Scrum aufgrund seines Fokus auf Stand-ups und Retrospektiven als Framework ausgewählt, von denen die Organisation glaubt, dass sie die Kommunikation innerhalb des Teams verbessern und zu einer schrittweisen Prozessverbesserung führen werden.
Kürzlich hat das Team „früh scheitern“ als Sprintziel für eine Iteration identifiziert. Die Idee war, dass es für Aufgaben, die nicht rechtzeitig erledigt werden können, möglicherweise keine alternativen Lösungen oder Problemumgehungen gibt – das Geschäftsmodell akzeptiert das Risiko, dass ein gewisser Prozentsatz der Aufgaben ungeachtet der Prozesseffizienz fehlschlägt –, aber dass diese drohen Fehler müssen transparent und für das gesamte Team sichtbar sein.
Das Ziel, frühe Fehler sichtbar zu machen, knüpft direkt an das logische Ziel an, die Kommunikation innerhalb des Teams zu verbessern. Dies geht etwas über die Aufgabenkoordination und Blocker-Identifikation eines täglichen Stand-up hinaus; Es erfordert einen kleinen Paradigmenwechsel in der Art und Weise, wie das Team routinemäßig miteinander kommuniziert.
In dem Maße, in dem das Ziel und seine Folge vom Team als Sprint-Ziel ohne konkrete Metrik gewählt wurden, um festzustellen, ob das Sprint-Ziel erreicht oder nicht erfüllt wurde, übernehme ich als Scrum Master die Verantwortung dafür, dass dies geschehen kann. Ich glaube immer noch, dass dies gültige Ziele für die Iteration waren, aber es fehlt ihnen an Konkretheit und einer "Definition of Done". Beides hat im Nachhinein keine selbstverständliche Leistungskennzahl, die sich präzise nachvollziehen lässt.
"früh scheitern" ist etwas subjektiv, aber ich glaube, ich könnte dies möglicherweise messen, indem ich die verstrichene Zeit vom Start des Arbeitselements bis zu seinem angekündigten Scheitern berechne und dann die "Fehlervorlaufzeit" (z. B. die Zeit zwischen dem Deklarieren einer Aufgabe) nachverfolge „nicht bestanden“ und das ursprüngliche Fälligkeitsdatum). Vielleicht gibt es eine noch bessere Metrik, die ich noch nicht berücksichtigt habe; Für Vorschläge in dieser Hinsicht bin ich natürlich offen.
„Teaminterne Kommunikation verbessern“ ist matschiger. Effektive Kommunikation ist ein Soft-Skill. Alles, was ich messen kann (z. B. E-Mail-Volumen, in der Job-Warteschlange aktualisierte Statusfelder usw.), sind bestenfalls Proxy-Metriken und nicht besonders genaue. Abgesehen davon, dass ich die Leute danach befrage, wie gut sie das Gefühl haben, dass die Kommunikation läuft, kann ich mir keinen praktischen Weg vorstellen, um dieses notwendige (aber vielleicht schlecht formulierte) Ziel zu messen.
Angesichts der angegebenen Sprint-Ziele und unter der Annahme , dass die Organisation Wert darin sieht, diese beiden Ziele zu erreichen:
Ich denke, die Metrik, die Sie für "früh scheitern" vorschlagen, ist wahrscheinlich nahezu optimal. Es könnte interessant (obwohl wahrscheinlich zu kostspielig) sein, den Zeitpunkt zu verfolgen, zu dem das Arbeitselement zum ersten Mal als "in Schwierigkeiten" identifiziert wurde.
Die verstrichene Zeit zwischen 2 und 3 kann einige interessante Informationen für die zweite Metrik liefern.
Fehleranalyse – Da das Ziel darin besteht, frühzeitig zu scheitern, führen Sie eine Fehleranalyse des Arbeitselements durch. Wenn die Kommunikation innerhalb des Teams zu dem Fehler beigetragen hat, wird dies als Kommunikationsfehler gewertet. Verfolgen Sie entweder die Anzahl oder den Prozentsatz der Kommunikationsfehler.
Ich bin mir nicht sicher, ob ich Punkt 2 verstehe, aber ich denke , Sie fragen sich, wie Sie aussagekräftige Metriken für weiche Ziele erstellen können. Ich denke, die Antwort ist, nach den Auswirkungen zu suchen, die das weiche Ziel auf die harten Geschäftsziele hat.
Für „Fail Early“ kann ein gültiges Maß in Verbindung mit (oder anstelle von) chronologischer Vorlaufzeit der Aufwand sein, der der Aufgabe gewidmet wird, bevor ein Fehler identifiziert wird. Dadurch erhalten Sie eine bessere Vorstellung von den Ressourcenauswirkungen und davon, ob Sie sowohl Geld als auch Zeit sparen. Nehmen wir zum Beispiel an, dass mir 50 % Aufwand für eine dreiwöchige Aufgabe (also 1,5 Wochen FT-Aufwand über diesen Zeitraum) budgetiert sind und ich einen Fehler nach zwei Wochen feststelle, nachdem ich 100 % meiner Zeit für die Aufgabe aufgewendet habe. Überwiegt der Vorteil, einen Fehler eine Woche früher zu melden, die Kosten dafür, dass ich mehr Zeit als geplant für die Aufgabe aufgewendet habe?
Ich bin mir nicht sicher, ob Umfragen für "Verbesserung der Kommunikation innerhalb des Teams" eine gute Idee sind. Angenommen, Ihr Team ist klein, werden die von Ihnen generierten Daten bestenfalls lückenhaft sein. Und wenn das Erreichen von Sprintzielen in die Bonusstruktur des Teams eingebunden ist, wäre es relativ einfach, dass es zu geheimen Absprachen kommt. Vielleicht wäre es ein besserer Ansatz, wenn Sie die Häufigkeit der angesprochenen Probleme verfolgen, die anscheinend mit schlechter Kommunikation zusammenhängen. Ich war in einer Reihe von Situationen, in denen ein Teammitglied Problem X angesprochen hat, und bei der Untersuchung stellte sich heraus, dass dies auf eine Art Kommunikationszusammenbruch zurückzuführen ist.
Verbessern Sie die Kommunikation innerhalb des Teams
Da die Kommunikationsqualität sowohl subjektiv als auch sehr persönlich ist, glaube ich nicht, dass es dafür ein einfaches Maß geben wird. Ich bin auch nicht davon überzeugt, dass es am Ende eines zwei- oder dreiwöchigen Sprints als „erledigt“ markiert werden kann, da es sich, wie Sie betonen, eher um eine langfristige Maßnahme handelt.
Trotzdem denke ich, dass Ihr Ansatz zur Erfolgsmessung im Großen und Ganzen richtig ist. Vermutlich gab es eine treibende Kraft hinter dem Wunsch, die Kommunikation innerhalb des Teams zu verbessern – ein Mangel an persönlichen Meetings, zu viele E-Mails, Nacharbeiten aufgrund schlechter Kommunikation usw. – und idealerweise haben Sie einige Benchmarks, an denen Sie arbeiten können. Auch ohne Benchmarks könnten Sie eine Umfrage auf Likert-Skala verwenden , um festzustellen, ob die Leute denken, dass sich die Kommunikation verbessert hat. Quantitativ könnte man meiner Meinung nach messen, ob jeder an Stand-ups teilnimmt und daran mitwirkt; ob Dokumente (zum Beispiel) auf einem Wiki oder einem gemeinsamen Laufwerk geteilt werden; wie viele formelle Besprechungsanfragen gestellt wurden (im Gegensatz zu persönlichen Gesprächen). Es wird alles davon abhängen, wie das Team derzeit arbeitet und wo es hin will.
Früh scheitern
Ich stimme diesbezüglich tendenziell den Ansätzen von Mark und Doug zu, aber auch hier denke ich, dass es schwierig ist, die "Vollständigkeit" dieser Aufgabe nach nur wenigen Wochen zu messen - es sei denn, Ihr Maß für die Vollständigkeit besteht einfach darin, dass Sie ein dokumentiertes Maß für frühes Versagen haben ( des Typs, den Doug und Mark vorgeschlagen haben). Ich denke eigentlich, dass letzteres ein akzeptables Ergebnis ist, aber ich habe möglicherweise falsch verstanden, was Sie aus dem Sprint herausholen möchten.
Beide Tore sind wirklich schlechte Tore. Beides ist nicht messbar, weil keines wirklich im Geringsten von Bedeutung ist. Die Antwort ist zu fragen, warum eines dieser beiden Dinge für das Team wichtig ist. Was ist der Zweck der Verbesserung der Kommunikation innerhalb des Teams? Warum wollen sie früh scheitern? Beide klingen als Schlagworte raffiniert, aber sie bedeuten an und für sich nicht wirklich etwas. Finden Sie heraus, was sie mit diesen Dingen zu erreichen versuchen, und machen Sie sich das zum Ziel (dies wird höchstwahrscheinlich messbar sein).
Es ist wie eine User Story: Als (Teammitglied) will ich (früh scheitern) damit ( hier liegt das messbare Ziel ).
Haftungsausschluss : Ich bin kein Scrum-Experte und habe keine Erfahrung mit Nicht-Entwicklerteams. Daher ist meine Antwort sowohl theoretisch als auch von Lean/Kanban-Denken durchdrungen
Das Tor eines Tores ist mindestens dreifach :
Vor diesem Hintergrund muss ein Ziel definiert werden, damit man wissen kann, ob es erreicht wurde oder nicht. Mit anderen Worten, ein Ziel sollte von einer Definition of Done begleitet werden .
Wenn Sie an dieser Stelle eine Metrik haben, die jeder versteht und die aus geschäftlicher Sicht relevant ist: in Ordnung. Da diese Kennzahl für Ihre Stakeholder aussagekräftig ist, erfüllt das Ziel seinen dreifachen Zweck.
Aber wenn Sie keine Metrik haben, machen Sie sich nicht die Mühe, Dinge zu berechnen, die Ihren Stakeholdern keine interessanten Informationen liefern (wie das E-Mail-Volumen). Versuchen Sie stattdessen, das Team (einschließlich der Stakeholder) diese Frage beantworten zu lassen: Wann wissen wir, dass unser Ziel erreicht ist?
Die Definition von „erledigt“ muss Ihnen dabei helfen, die Gründe gut zu verstehen, warum das Team sein Ziel nicht erreicht hat. Denken Sie daran, wenn Sie eine Metrik definieren, die Erfolgs-/Fehlerbedingungen definieren soll, da Sie sie als Wurzel der Fehleranalyse haben werden. Ihr Ziel ist hier, das Verständnis zu erleichtern .
Mein Ratschlag zum Umgang mit subjektiven Zielen lautet: Versuchen Sie nicht, sie zu rationalisieren . Lass sie subjektiv sein. Nehmen wir das Beispiel „Teaminterne Kommunikation verbessern“. Hier hilft wohl nur, die Teammitglieder danach zu fragen. Fragen Sie während des Sprint Retrospective Meetings die Teammitglieder (einschließlich der Stakeholder), ob sie denken, dass das Ziel erreicht wurde und warum. Idealerweise haben Sie den „Warum“-Teil bereits vor dem Sprint definiert. Ob das Ziel erreicht ist oder nicht, wird sich dann in einer kurzen Diskussion zeigen und wahrscheinlich mehr Aufschluss geben als das Ergebnis einer schrägen Rechnung (Am Ende des Sprints ist „Ich weiß gar nicht, was du getan hast!“ besser als "Unsere +Kommunikationsrate+ beträgt 0,473")
Ich bin mir ziemlich sicher, dass es nicht möglich ist, subjektive Ziele und die damit verbundenen Handlungen zu messen, weil ihre Messung auch subjektiv sein wird, aber eine Messung muss objektiv sein.
Subjektive Ziele tauchen jedoch meist auf, wenn das Team nicht wirklich weiß, wie es ein bestimmtes Problem angehen soll, und zu experimentieren beginnt . Aus diesem Grund wird ihnen normalerweise empfohlen, die Ergebnisse (wie Vorlaufzeit und Durchsatz) zu messen und zu beobachten, denn wenn sie eine positive Differenz aufweisen, haben die Gegenmaßnahmen funktioniert, und diese Ergebnisse können objektiv gemessen werden.
Was wäre, wenn Sie das Auftreten (Erwähnung) eines Problems zählen und prüfen, wie diese Daten Woche für Woche aussehen ? Nehmen wir an, dass der Satz „wir müssen früh scheitern“ oder „wir hätten früher scheitern sollen“ von einem der Teammitglieder gesagt wird. Sie zählen die Gelegenheiten oder bitten die Teammitglieder darum, und am Ende des Sprints überprüfen Sie diese Daten. Wenn die Anzahl fast Null ist, bedeutet dies, dass Sie dieses Problem gelöst haben.
Vor einiger Zeit waren wir uns nicht sicher, ob wir Continuous Delivery wirklich brauchen. Also haben wir die Gelegenheiten gezählt, bei denen wir es hätten besser machen können, wenn wir kontinuierliche Lieferung gehabt hätten. Wir hatten 5 Gelegenheiten in 2 Monaten, also haben wir es nicht umgesetzt, weil wir ohne gut waren.
Ich denke, diese Technik kann auch für Ihr Team funktionieren. Wenn die Mitglieder seltener sagen, dass „sie früher scheitern müssen“ , könnte das bedeuten, dass sie für sie früh genug scheitern. Oder wenn sie nicht das Bedürfnis verspüren, zu erwähnen, dass die Kommunikation innerhalb des Teams verbessert werden muss, könnte dies bedeuten, dass sie gut genug für sie ist.
Matthias Jouan