Ich hatte in den letzten Jahren das Privileg, mit mehreren Teams und Scrum Masters zusammenzuarbeiten. Bei vielen Gelegenheiten hatte ich einige interessante Diskussionen. Einige dieser Themen habe ich in einem virtuellen Gespräch mit einem imaginären Scrum Master zusammengefasst.
Scrum Master: Mein Team glaubt, dass ich ihnen nicht genug Spielraum für Fehler lasse. Ich versuche, sie zu unterstützen, aber ich fühle mich für das Ergebnis verantwortlich. Wenn sie also nicht das tun, was ich für das Beste halte, glaube ich, dass ich das Recht habe, ihnen zu sagen, was sie tun sollen. Schließlich bin ich der Scrum Master und bestimme somit den Prozess. Richtig?
Ich: Das kommt auf den Kontext an. Die meisten Unternehmen beginnen mit Scrum, um von der "guten", altmodischen Art und Weise der Arbeit an einem Produkt wegzukommen. Sie müssen etwas anderes ausprobieren, weil die derzeitige Arbeitsweise NICHT funktioniert. Selbst wenn wir denken, dass wir etwas anders machen, neigen wir dazu, an den Dingen festzuhalten, die wir gewohnt sind zu tun. Das ist nicht unbedingt etwas Schlechtes, aber wenn Sie wirklich wollen, dass sich Ihr Team ändert, müssen auch Sie sich ändern. Die Rolle des traditionellen Projektmanagers oder technischen Leiters in einem Scrum-Team ist anders. Ein Scrum Master soll den Wandel erleichtern und die Lernkurve so hoch wie möglich halten. Das Team oder den Prozess zu kontrollieren ist zu altmodisch. Und Sie haben schon einmal gesehen, dass das nicht funktioniert. Richtig? Ja, Sie können die Führung übernehmen, aber das können auch andere Teammitglieder. Und bitte geben Sie ihnen das Gefühl, dass sie einen Schritt in Richtung Veränderung tun können. Geben Sie ihnen die Möglichkeit zu scheitern. Viele großartige Ideen und Verbesserungen entstehen aus Fehlern. Auf diese Weise lernen wir.
Scrum Master: Ja, das verstehe ich, aber die Symptome des Teams sind schlechte Schätzungen und mangelndes Engagement, qualitativ hochwertige Software zu liefern. Wenn ich dabei nicht die Führung übernehme, wird es niemand tun!
Ich: Ich glaube nicht, dass irgendjemand minderwertige Software liefern will. Jeder hat eine andere Meinung über Qualität. Die einen meinen, sie bestehe in der Verwendung von Codemustern oder Standards, die anderen meinen, es gehe darum, dass alle Ihre Testautomatisierungswerkzeuge "grün" sind. Ich bin mir da nicht so sicher. Ich denke, dass die Qualität eines Produkts von den Menschen abhängt, die für seine Entwicklung verantwortlich sind. Wenn also jemand wirklich ein schlechtes Gefühl in Bezug auf das Produkt, den Prozess oder die Organisation hat, wirkt sich das auf das Produkt aus.
Eines Tages habe ich das Team gebeten, ihre imaginäre Albtraum-Schlagzeile für den Newsletter des Unternehmens aufzuschreiben, um die Kreativität für unsere nächste explorative Testsitzung anzuregen. Einer von ihnen schrieb auf: "Niemand benutzt unsere Software". Und alle anderen nickten und stimmten der Aussage zu. Plötzlich verstand ich das Engagement des Teams. Sie haben nicht an ihr Produkt geglaubt! Ich verstehe, dass Sie sich dafür verantwortlich fühlen, qualitativ hochwertige Software zu liefern, aber wenn sich niemand stolz oder leidenschaftlich dafür einsetzt, das richtige Produkt zu entwickeln, haben Sie ein größeres Problem, als Ihr Produkt nicht pünktlich zu liefern.
Scrum Master: Wow! Das klingt beängstigend. Und das Schlimmste ist... Es ist bei unserem Team irgendwie erkennbar. Daran sollte ich arbeiten! Ich bin immer noch für das Standup-Meeting verantwortlich, oder?
Ich: Nun ja... Sie sind nicht der Einzige, der für das Standup verantwortlich ist. Ich habe schon wirklich gute Standups gesehen, bei denen kein Scrum Master anwesend war. Die meisten Teams denken, dass ein Standup eine tägliche Statusbesprechung ist. Vor allem, wenn ein Scrum Master anwesend ist. Das Team berichtet an seinen Master. Das Gleiche, was Sie vorher gemacht haben? Erinnern Sie sich? Versuchen Sie, das Team zu stimulieren und zu inspirieren, wirklich an den Aufgaben mitzuarbeiten. Schauen Sie einfach weg, wenn Ihnen jemand Bericht erstattet. Schauen Sie auf Ihr Scrumboard und lassen Sie das Team miteinander über den Burndown und die Schritte sprechen, die sie unternehmen müssen, um das Sprint-Ziel zu erreichen.
Oh... und es ist wirklich wichtig, diese Meetings so kurz wie möglich zu halten. Manchmal müssen Sie nicht das Format Vergangenheit, Zukunft und Hindernisse verwenden. Niemand nimmt gerne an Statusbesprechungen teil. Konzentrieren Sie sich also auf die nächsten Schritte (Zukunft) und nicht auf die Dinge, die gestern erledigt wurden. Geben Sie den Teammitgliedern das Gefühl, dass sie sich für den Scrum-Prozess engagieren. Als ob er ihnen gehört. Nicht Sie.
Scrum Master: Damit ich das richtig verstehe. Das Team leitet das Standup. Und das Standup-Format ist nur ein Leitfaden. Damit kann ich leben. Ich mache mir nur Sorgen, dass niemand die Verantwortung für die Hindernisse und andere Probleme übernimmt. Wir brauchen immer noch eine Art von Struktur in diesem Prozess, oder?
Ich: Ja! Wir sollten versuchen, diese Richtlinien zu verwenden, aber lassen Sie sich und Ihr Team nicht vom perfekten Prozess leiten. Das Erreichen eines Ziels hatte nie etwas mit dem Befolgen eines Prozesses zu tun. Es sind immer noch die Bemühungen und das Engagement des Teams, die den Unterschied ausmachen. Wenn niemand die Verantwortung für die Hindernisse und Probleme übernimmt, leiten Sie das Team mit Ideen an. Geben Sie ihnen die Inspiration, die Hindernisse selbst zu lösen. Wenn ein Problem oder ein Hindernis außerhalb der Zuständigkeit des Teams liegt, wird es Sie um Hilfe bitten!
Ein Beispiel: Die Abteilungen QA und IT Operations machen zu viel manuelle Arbeit. Das Team erhält also Feedback und Fehlerberichte außerhalb der Sprints, was jede Veröffentlichung verzögert. Und dennoch drängen Sie Ihr Team dazu, besser abzuschätzen und seine Verpflichtungen zu erfüllen. Vielleicht sollten Sie Ihren Aufgabenbereich in Richtung eines Engagements ändern, das über das Team hinausgeht?
Scrum Master: Ich verstehe... Ich sollte wirklich versuchen, ihnen eine Chance zu geben. Ich traue ihnen einfach nicht, wissen Sie. Und ich stimme zu, dass ich dem Team bei Problemen helfen könnte, die nicht in den Aufgabenbereich des Teams fallen. Vielleicht könnte ich unser Management bitten, einige QA- und Ops-Mitarbeiter in unser Team zu holen. Das würde helfen, die Feedbackschleifen zu beschleunigen.
Ich: Ja! Das sollten Sie! Das Team wird Sie dorthin bringen, wohin Sie wollen, aber so, wie es das Team will, wie es das Team weiß!
Scrum Master: Was ist mit all diesen Agile Software Tools, Tabellen, Diagrammen und Metriken?
Ich: Sie fühlen sich für unsere Leistung verantwortlich. Und Sie versuchen, einen Prozess und Metriken zu entwickeln. Ich verstehe, dass Sie das Team gut aussehen lassen wollen, aber seien Sie vorsichtig, wenn Sie es übertreiben. Denken Sie an die Dinge, die Sie vor der Einführung von Scrum getan haben. Wenn Sie etwas ändern wollen, müssen Sie sich von Ihren alten Gewohnheiten verabschieden. Ich habe mit Teams gearbeitet, die sich nur um die Anzahl der Benutzer kümmerten, die ihr System nach einer Veröffentlichung nutzen. Und sie behielten diese Zahlen im Auge und reagierten bzw. änderten ihre Pläne entsprechend. Seien Sie offen für neue Dinge. Und versuchen Sie nicht, die Kontrolle über das Team zu übernehmen. Das gesamte Team sollte zur Rechenschaft gezogen werden und sich für seine Arbeit verantwortlich fühlen. Wenn sie eine coole neue Methode finden, um wichtige Kennzahlen zu behalten. Lassen Sie sie! Und Sie werden sehen, dass sie sich befähigt fühlen, großartige Dinge zu tun und sich sogar mehr für das Unternehmen engagieren.
Scrum Master: Ja... Engagement, Verpflichtung und Befähigung. Ich habe versucht, während unserer Retrospektiven daran zu arbeiten, aber sie sind zum Kotzen! Keiner nimmt gerne daran teil.
Ich: Das habe ich bemerkt. Es ist in Ordnung, wenn Sie die Retrospektiven leiten, aber lassen Sie dem Team etwas Raum für Kreativität bei der Lösung von Hindernissen oder anderen Problemen. Sie müssen nicht mit Lösungen aufwarten. Inspirieren Sie das Team einfach mit großartigen Ideen und geben Sie ihm das Gefühl, dass es die Wahl hat, es auf Ihre Weise oder vielleicht auf ihre Weise zu tun. Eine andere Sache, die mir aufgefallen ist, ist, dass sich das Team keine Zeit nimmt, um seine Fortschritte in Bezug auf die Verbesserungen der letzten Retrospektiven zu bewerten. Wann immer Sie beschließen, etwas zu verbessern, machen Sie es messbar und bewerten Sie das Ergebnis, damit das Team seine Bemühungen um Verbesserungen sehen kann.
Bevor ich es vergesse! Sorgen Sie dafür, dass mindestens eine Person im Team für die Verfolgung der retrospektiven Maßnahmen (wie die Stabilisierung der Testautomatisierung) verantwortlich ist. Das bedeutet nicht unbedingt, dass Sie es sind. Um eine Gruppenverantwortung für Verbesserungen zu schaffen, ist es auch wichtig, dass jemand anderes die Verantwortung für die Lösung von Problemen übernimmt.
Scrum Master: Bei der Rolle des Scrum Masters geht es also nicht um Autorität oder das Management von Menschen?
Ich: Auch hier kommt es auf den Kontext an. Ich habe mit einem Scrum Master gearbeitet, der zwar sehr direktiv war, uns aber auch dazu inspiriert hat, besser zu werden. Wir hatten einen engen Zeitplan und eine knappe Frist. Er ließ uns die Stärken und Schwächen verschiedener Optionen sehen und bewerten. Aufgrund seiner großen Erfahrung traf er immer die richtige Wahl. Und wir vertrauten ihm.
Suchen Sie nicht nach dem I in Team, denn das befindet sich im 'A-Loch' ;-)
Verfasst von
Kishen Simbhoedatpanday
Unsere Ideen
Weitere Blogs
Contact