Durchsetzung eines einheitlichen Scrum-Ansatzes für alle Teams innerhalb einer Abteilung

8

Wo ich arbeite, haben wir kürzlich die Agile-Entwicklung mit Scrum umgestellt. Wir haben die typischen Wachstumsschmerzen durchgemacht, aber einen Ansatz erreicht, der vorerst zu funktionieren scheint (ob es langfristig funktioniert, ist eine andere Frage!).

Offensichtlich ist die Abteilungsleitung froh, dass der Übergang zu Scrum funktioniert. Aber sie haben angefangen, etwas zu tun, das sich für mich falsch anfühlt.

Das Management wird ein Team beobachten, sehen, was für sie funktioniert, und es der gesamten Abteilung vorschreiben. Dinge wie:

Die Definition von "Fertig"
Welche Story-Point-Werte können für das Story-Pointing verwendet werden (z. B. Weglassen von 8 in der Fib. -Sequenz, da nur 1, 2, 3, 5, 13 usw. während eines beobachteten Sprints verwendet wurden)?
Sagen Sie den Teams, dass sie ihren Story-Point-Wert von 1 kalibrieren müssen, um "ein UI-Label zu aktualisieren" und sie auf eine Obergrenze von 20 zu beschränken
- (obwohl nicht alle unsere Projekte Kunden haben und nicht alle Entwickler Erfahrung mit der Benutzeroberfläche haben)
Wenn Sie den Teams sagen, dass sie Story-Point-Schätzungen von 100 verwenden sollen, bedeutet dies "Wir werden diese Story später aufteilen".
Sagen Sie den Teams, dass sie Story-Point-Schätzungen der Unendlichkeit verwenden sollen, um zu bedeuten, dass dies ein Epos ist oder dass wir weitere Informationen benötigen.

Ich verstehe, dass sie versuchen, hilfreich zu sein, aber sollten nicht alle oben genannten Dinge spezifisch für das Scrum-Team sein? Das heißt, was für eine Gruppe von Personen in einem Projekt funktioniert, ist für eine andere Gruppe in einem anderen Projekt möglicherweise nicht sinnvoll.

Ich mache mir Sorgen, dass wir uns einem sehr präskriptiven und steifen agilen Ansatz zuwenden. Bin ich berechtigt, dies zu denken, oder überreagiere ich?

Bearbeiten

Nur um zu verdeutlichen ... mit "Management" und "Manager" meine ich nicht den Product Owner. Ich meine jeden Manager außerhalb des Scrum-Teams, aber innerhalb der Software-Abteilung.

agile scrum management

— MetaFight
quelle

Für mich klingt es so, als würde das Management die Arbeitsweise von AGILE ändern, um IHRE Bedürfnisse am besten zu erfüllen, und nicht das Team , das den Prozess verwendet. Das einzige Mal, dass es für mehrere Teams sinnvoll ist, dieselbe Story-Point-Größe zu teilen, besteht darin, verschiedene Projekte einfacher zu vergleichen, was die Teammitglieder nicht tun müssen. Ich würde versuchen, den Scrum Master darauf hinzuweisen, um zu sehen, ob sie einen Zug haben, und könnte das Management möglicherweise daran erinnern, dass Agile ein Prozess für die Teams ist, nicht für die Manager, die die Teams verwalten.

— Ampt

5

Zu viele Manager mit zu wenig zu tun ist eine großartige Möglichkeit, Talente zu entfremden.

— Erik Reppen

17

Natürlich sind Sie berechtigt, das zu denken. Die Tatsache, dass Sie über "Durchsetzung von Scrum" sprechen, ist eine dröhnende Alarmsirene.
Bei Scrum geht es in erster Linie um die Selbstorganisation des Teams. Sie können wählen, wie sie ihre Arbeit erledigen und wie sie sich organisieren möchten. Das Management hat nur ein Mitspracherecht bei der zu erledigenden Arbeit.
Der Grund, warum sich Teams organisieren sollten, ist, dass sie aufgrund der unterschiedlichen Natur der einzelnen Teammitglieder (und der Personen, mit denen sie arbeiten) und der Unterschiede bei den Produkten, an denen sie arbeiten, immer einzigartig sind. Eine Übung, die für ein Team perfekt funktioniert, kann sich nachteilig auf ein anderes Team auswirken. Deshalb müssen sie innerhalb eines bestimmten Bereichs (häufig wird eine Sandbox-Metapher verwendet) experimentieren, lernen und herausfinden, was für sie am besten funktioniert.
Was Sie brauchen, ist ein sehr kompetenter Scrum-Master (einer pro Team), der ein Team bei dieser Entdeckung führen kann, gleichzeitig aber auch mit dem Management zusammenarbeiten kann, um dem Team die Freiheit zu geben, an dieser Entdeckung teilzunehmen.

— Stefan Billiet
quelle

"Management" hat nicht nur ein Mitspracherecht bei dem, was getan werden muss, sondern auch bei den nicht funktionalen Kriterien, die das "Was" erfüllen muss: Qualität, Testbarkeit, Robustheit. Das Management hat keinen Einfluss darauf, wie Teams diese Anforderungen erfüllen, aber sie haben absolut das Recht, die (Akzeptanz-) Kriterien in diesen Bereichen festzulegen. Als solches hat das Management Einfluss auf die Definition von erledigt.

— Marjan Venema

Ich bin mir nicht sicher, ob das ganz richtig ist. Es ist das Recht und die Pflicht der Entwickler, qualitative Software zu produzieren. Wenn ein Manager betonen muss, dass die zu liefernde Software qualitativ, testbar und robust sein muss, dann haben Sie ein anderes (und wahrscheinlich viel tiefer liegendes) Problem. Wenn wir über SLA-Sachen sprechen, ist das eine andere Geschichte. Wie wird dies in der Praxis überprüft, wenn ein Manager Qualität, Testbarkeit oder Robustheit betont? Normalerweise nach dem Versand, zu welchem Zeitpunkt es größtenteils zu spät ist. Qualität kann von Entwicklern eingebaut und nicht von Testern hinzugefügt werden.

— Stefan Billiet

1

@MarjanVenema Die "Definition von Done", über die ich hier spreche, ist ein Scrum-Konzept (DoD) und bezieht sich darauf, wann eine Story oder ein Sprint als "Done" betrachtet werden. Ich verstehe, dass ein Dev-Manager Richtlinien für Qualität, Testbarkeit und Robustheit haben würde, aber dies sind so grundlegende Anforderungen, dass sie im DoD nicht explizit angegeben werden müssen. Wie StefanBilliet sagte, wenn diese Anforderungen explizit sein müssen, dann ist dies ein Zeichen für ein größeres Problem.

— MetaFight

1

Ich weiß, dass sie keine Selbstverständlichkeit sind. Ich arbeite einfach lieber mit einem talentierten Team zusammen, dem man vertrauen kann, um die Arbeit richtig zu erledigen, als mit Leuten, denen es egal ist. Es ist nie wirklich effizient zu versuchen, Qualitätsstandards durch Management "durchzusetzen". Wenn sich das Team nicht um die Qualität seiner Arbeit kümmert, brauchen Sie ehrlich gesagt ein anderes Team. Und ich spreche auch nicht nur von Entwicklern. Support und Geschäftsleute müssen gleichermaßen motiviert und fähig sein.

— Stefan Billiet

1

@ MarjanVenema Aber Sie verpassen den Punkt. Es geht nicht darum, das Team dazu zu bringen, sich zu kümmern oder ein System zum Spielen zu sein, weil es nicht um Verantwortlichkeit geht. Es geht darum, Ihre Schätzungen zu verbessern. Das obere Management sollte sich nicht darum kümmern, was die DoDs eines Teams sind. Sie sollten sich nur darum kümmern, ob ihre Schätzungen einigermaßen genau sind oder ob sie sich verbessern, wenn sie verbesserungsbedürftig sind. Es ist Sache des Teams, wie sie dorthin gelangen, und der Produktbesitzer, der die wichtigen Hindernisse bestimmt. Das obere Management sollte diese Einheitlichkeit nicht brauchen. Wenn dies der Fall ist, liegt ein Problem mit der Befehlskette vor.

— Erik Reppen

4

Willkommen zu einem der schlimmsten Albträume von Scrum. Sie sind auf einen der Gründe gestoßen, warum Scrum nicht die großartigen Dinge liefert, die jeder bei der Übernahme im Sinn hat.

Leider ist Scrum nicht mit dem oberen Management kompatibel, das dazu neigt, Managementprozesse im gesamten Unternehmen und in den Teams zu zentralisieren und zu erstellen. Um erfolgreich zu sein, muss das obere Management seine Denkweise ändern und sich auf das konzentrieren, was es von den Teams benötigt. Sie sollten sich nicht darauf konzentrieren, wie die Teams arbeiten. Das einzige Mal, wenn sie sich engagieren sollten, ist, wenn ein Team nicht auftritt, um den Grund herauszufinden.

Ich glaube, dass Sie sich mit dem Management zusammensetzen und über deren Anforderungen und die Leistungen der Teams sprechen müssen. Dies kann eine globale Anforderung für alle Teams sein. Es können Schätzungen sein, die sie verstehen, die Dauer usw. Diese Dinge sollten die Prozesse des Teams nicht bestimmen. Es ist wichtig, dass Sie die Managementerwartungen von der Art und Weise, wie Sie Scrum ausführen, trennen. Jedes Team muss sein eigenes Tempo und seine eigene Art finden, die Projekte voranzutreiben, damit sie erfolgreich und produktiv sind und das liefern, was das Management benötigt. Wenn Sie beispielsweise eine Schätzung von 15 Story-Punkten haben, sollte das Team in der Lage sein, diese Punkte basierend auf der durchschnittlichen Teamgeschwindigkeit in Manntage (oder Stunden) zu berechnen. Aber es wird einzigartig für das Team sein.

— Ioannis Tzikas
quelle

2

Aber es gibt Scrum-Trainer, die Ihr Geld nehmen und Ihnen sagen, dass Sie das tun können, wenn sie glauben, dass Sie es hören möchten. Aus diesem Grund sind Aussagen wie "Es funktioniert nur, wenn Sie es genau wie vorgeschrieben tun" kein Ersatz für kritisches Denken.

— Erik Reppen

1

Als Unternehmen sollte das Ausbalancieren Ihrer Ressourcen ein Wettbewerbsvorteil sein. Andernfalls erstellen Sie einfach eine Reihe einzelner Softwareunternehmen, die diese Hebelwirkung verlieren. Eine Organisation mit mehreren Teams und Projekten muss sich mit Umsatz und Teamausgleich befassen. Ich denke nicht, dass es eine gute Idee für jede einzelne Teamkombination ist, das Buch darüber neu zu schreiben, wie sie Scrum machen werden.

Immer wenn Sie versuchen, Dinge zu aggregieren, um etwas zu messen, ist Konsistenz wichtig, dh vergleichen Sie keine Äpfel und Orangen. Das Management sollte sich auf diese übergeordneten Anforderungen konzentrieren, aber sicherstellen, dass sie sich nicht zu sehr auf die Details der Arbeitsweise von Teams einlassen. Versuchen Sie, ihre Vorschläge anzuwenden, aber seien Sie bereit zu verteidigen, warum ein Team die Ausnahme sein kann. Jeder, der eine bestimmte Art, Dinge zu tun, einfach nicht persönlich mag, muss seine Erwachsenenhose anziehen und damit umgehen.

Es muss eine gewisse Flexibilität geben, damit Sie die Arbeit erledigen können. Bei Bedarf sollte Konsistenz herrschen. Wenn sich die Teammitgliedschaft ändert, sollte nicht jeder das Gefühl haben, dass es sein erster Arbeitstag ist.

Vielleicht ändern sich Ihre Teams nie, aber Sie sollten dieser Wahl eine Chance geben, indem Sie eine gewisse Konstanz haben.

— JeffO
quelle

Ich bin mir nicht sicher, ob ich Ihnen voll und ganz zustimme, aber ich glaube, ich verstehe, was Sie sagen. Oh, und +1 für "Zieh ihre Erwachsenenhose an". Ich muss daran denken, das öfter zu tun (kein Scherz).

— MetaFight

3

Ehrlich gesagt bin ich anderer Meinung. Wenn Sie Personen für den Status "Ressource" festlegen, ist dies der Anfang vom Ende. Entwickler sind Menschen, keine Zahnräder in einer Maschine, die umgeschaltet werden müssen, wenn jemand das Bedürfnis hat. Ihr Wettbewerbsvorteil sollte eine Kombination aus einer erweiterten technologischen Reife und einem umfassenden Fachwissen sein. Das ist das Zeug, aus dem großartige Produkte gemacht sind. Alles andere sind nur kurzsichtige kurzfristige Kosteneinsparungen, die meiner Meinung nach zu einem langfristigen Rückgang der Qualität und Größe Ihrer Produkte führen.

— Stefan Billiet

0

Nein, Sie reagieren nicht überreagiert und haben guten Grund zur Sorge. Das Management sollte sich auf den Kulturwandel konzentrieren. Das Management muss die richtige Richtung festlegen und den Teams den Kontext präsentieren, um die agilen Zeremonien zu nutzen, die gut funktionieren, damit das Team produktiv ist.

Ich bin froh, dass ich in einer Organisation arbeite, die seit über einem Jahr eine agile Transformation vom Wasserfall durchläuft und in dem Portfolio beginnt, in dem ich arbeite. Sie begannen ursprünglich mit einem Projekt, in dem ein agiles Team gebildet wurde. Der Erfolg der Lieferung durch agile Zeremonien wie Retros, relative Schätzungen und historische Prognosen unter Verwendung der Geschwindigkeit führte dazu, dass das gesamte Portfolio zusätzliche Teams mit eigenem Rückstand bildete.

Aus Erfahrung ist Agile nicht vorgeschrieben und Sie können keinen Cookie-Cutter-Ansatz einführen. Nur weil es in einem Team funktioniert hat, heißt das nicht, dass es in einem anderen Team funktioniert. Ich weiß das aus Erfahrung, weil wir ursprünglich dachten, wir könnten neue Teams starten, indem wir dieselben Dinge wie DoD anwenden, was 1 Punkt bedeutet, was 8 Punkte bedeutet. Aber es funktioniert nicht so kontextuell, dass sie wenig Bedeutung haben, wenn sie auf ein anderes Team angewendet werden. Übrigens bedeutete für eine Teamgeschichte über 8 Punkte, dass sie zu groß war und aufgeteilt werden musste.

Was funktionierte, war die Festlegung von Richtlinien für die Teams, wie sie gleichzeitig Stand-Ups, Retros, Showcases und bei jeder Retro-Aktion durchführen müssen, um die neuen Teams zu verbessern. Andere Dinge wie die Definition von erledigt und die Größe von Story-Punkten wurden nach ein paar Sprints eingeführt, als das Team mit dem Konzept der Story-Erzählung und dem Ausfüllen von Karten vertraut wurde und es nicht in den nächsten Sprint einschleichen ließ.

Ich weiß, dass dies für das Management ein schwieriger Verkauf ist, da es wissen möchte, wann Projekte geliefert werden, und wenn es darum geht, neue agile Teams zu bilden, ist es schwierig, dieses Bild im Voraus zu vermitteln. Aber jetzt hat das Portfolio den Ruf, eine starke agile Lieferfähigkeit zu haben. Wir würden immer noch stolpern, wenn der Ansatz des Ausstechers weiterhin auf die anderen Teams übertragen würde.

— Malcolm
quelle

0

In der Praxis Inkonsistenzen zwischen Scrum-Teams können tatsächlich ein Problem sein, beispielsweise wenn Teammitglieder zwischen Teams wechseln.

Es ist besser, zu versuchen, diese Art von Problemen beim Wissensaustausch zwischen Teams agiler zu lösen - vielleicht so etwas wie Lean Coffee- oder Scrum-of-Scrum-Sitzungen mit Ihren Scrum-Mastern. Dies würde Ihr Management hoffentlich dazu bringen, zu erkennen, dass Sie die Verantwortung für diesen Bereich übernehmen, und aufhören, zu versuchen, die Probleme von oben nach unten zu bewältigen.

— ndyer
quelle