Ich bin neu in der Scrum-Domäne und habe kürzlich einen „Scrum at Scale“-Workshop in der Nähe meiner Stadt gefunden. Ich bin ein Software-Ingenieur, der sich eher der Datenwissenschaft zuwendet. Wie würde mir skaliertes Scrum helfen, Projekte mit vielen Stakeholdern besser zu managen, und wie unterscheidet es sich von Standard-Scrum?
Scrum@Scale ist ein spezielles Framework, das von Jeff Sutherland und Scrum, Inc. entwickelt wurde, um Scrum über ein einzelnes Team hinaus zu skalieren. Allgemeiner bezieht sich skaliertes Scrum (oder „Scrum im [Unternehmens-] Maßstab“) auf die Rahmenbedingungen und Praktiken, die erforderlich sind, um Scrum-Konzepte über mehrere Teams hinweg anzuwenden, was häufig bei sehr großen oder komplexen Unternehmensprojekten (z. B. „im Maßstab“) erforderlich ist. .
Standard-Scrum behandelt bereits mehrere Stakeholder. Skalierte Scrum-Frameworks zielen auf Programme mit mehreren Teams ab . Die Verwaltung von Stakeholdern ist eine Funktion des Product Owners in Standard-Scrum, kann aber in anderen Frameworks Teil anderer Rollen (oder sogar ganzer Teams) sein.
Im Kern ist Scrum ein Framework für die Entwicklung eines Produkts aus einem einzelnen Product Backlog, das von einem einheitlichen Scrum-Team betreut wird. Im Laufe der Zeit wurden innerhalb der agilen Community verschiedene Ansätze zur Skalierung von Scrum über ein einzelnes Team hinaus gefördert. Unabhängig vom Framework versuchen sie alle, eines oder mehrere der folgenden Probleme zu lösen:
Dies ist keine vollständige Liste, aber das Thema „mehrere Teams“ ist eines, das Scrum nicht von Haus aus angeht.
Zu den verschiedenen Frameworks und Skalierungsmechanismen, die verwendet werden, um Scrum über ein einzelnes Team hinaus zu skalieren, gehören:
NB: SAFe verwendet Scrum auf Teamebene, ist aber wohl kein wirklicher Versuch, Scrum selbst auf Unternehmensebene zu skalieren. Stattdessen verwendet es andere Mechanismen und Frameworks auf verschiedenen Organisationsebenen. Ob Sie es in „skaliertes Scrum“ aufnehmen, ist Geschmackssache, aber als eines der bekannteren skalierten Frameworks habe ich mich entschieden, es hier der Vollständigkeit halber aufzunehmen.
Andere agile Ansätze wie Lean, Kanban, DevOps usw. sind in dieser Liste nicht enthalten, da sie nicht von Natur aus auf Scrum basieren. Dennoch sind Skalierungsprobleme häufig unabhängig vom Framework vorhanden und müssen in jedem team- oder abteilungsübergreifenden Agilitätsansatz angegangen werden.
Es würde Ihnen mit mehreren Interessengruppen nicht helfen.
Scrum ist bereits dafür gedacht, mit mehreren Stakeholdern (und einem einzelnen Product Owner, der ihre Bedürfnisse in einem einzigen priorisierten Produkt-Backlog konsolidiert) umzugehen. Scrum at Scale soll Ihnen bei Projekten helfen, die so groß sind, dass Sie mehrere Teams benötigen .
Wenn Sie wissen wollen, wie Sie mit Ihren Stakeholdern besser umgehen können, wäre ein Product Owner Training die bessere Wahl.
Nun, meiner Meinung nach versucht „Scrum at Scale“, sich mit dem realen Problem auseinanderzusetzen, dass – ja, meiner Meinung nach – „Scrum eine zu starke Vereinfachung ist“. Verstehen Sie das, und es wird Ihnen gut gehen. „Scrum“ hat viele nützliche Ideen für die Projekt- und Teamorganisation, predigt aber lieber.
Mein Rat lautet einfach: „Verwenden Sie Scrum“, weil es in der Tat nützlich ist, aber „ glauben Sie es nicht ganz “. Schlürfen Sie das Kool-Aid, aber trinken Sie nicht das ganze Glas. Behalten Sie es im Blick.
Reale Softwaresysteme „berühren“ üblicherweise viele verschiedene Abteilungen und Aktivitäten einer Organisation und interagieren mit anderen Projekten auf eine Weise, die harte Einschränkungen auferlegt, die kein einzelnes Team lösen oder notwendigerweise auch nur erkennen kann. Dies schließt natürlich nicht den Wert einer „Scrum“-Organisation und eines „Scrum“-Workflows innerhalb dieses Teams aus.
„Scrum at Scale“ argumentiert, dass die Organisation im Scrum-Stil dennoch auf mehreren Ebenen angewendet werden sollte, sodass verschiedene „Scrum“-Teams in einer „Scrum“-Manier geführt werden, bis ein „Über-Scrum-Master“ sie alle beherrscht. Ich werde offen meine Meinung äußern, dass dies praktisch Unsinn ist. Die Methodik ist meiner ehrlichen Meinung nach „nicht skalierbar“, und das sollte auch nicht erwartet werden. Aufgrund des Zeit- und Kostenaufwands aller Softwareprojekte sowie ihres übergreifenden Einflusses auf das Gesamtunternehmen "haben wir dafür Vizepräsidenten", und deshalb sind ihre Entscheidungen immer Kompromisse.
=== BEARBEITEN :
In einem Versuch, die oben geäußerte Meinung zu klären , „warum Scrum nicht skalieren kann oder sollte“, werde ich auf Wunsch von Todd Jacobs meine vorherigen Kommentare ergänzen, ohne sie zu streichen.
Ich möchte nun die Bemerkung machen, dass alle Projekte mit Umfang und Grenzen definiert sind, innerhalb derer das Management hofft, dass die „Scrum“-Methodik zufriedenstellende Ergebnisse im festgelegten Budget und Zeit und mit akzeptablem Geschäftsrisiko erzielen wird. Aber wenn wir dann versuchen, „Scrum“ auf höheren Ebenen innerhalb der Organisation anzuwenden, erreichen wir schnell Abstraktionsebenen und Ebenen der Besorgnis, die sich auf das Unternehmen als Ganzes auswirken und für die die (inhärent riskanten) „Erkundungsmethoden“ verfochten werden „Scrum“ sind nicht mehr anwendbar oder gar sicher. Darauf habe ich angespielt, als ich sagte: "Deshalb haben wir Vizepräsidenten, und deshalb sind ihre Entscheidungen immer Kompromisse."Sie treffen ihre unscharfen High-Stakes-Entscheidungen nicht auf der Grundlage der gleichen Prinzipien, die „Scrum“ am Herzen liegen – sie können es nicht und sie sollten es auch nicht.
Reale Projekte sind oft durch technische, geschäftliche, geschäftliche Risiken und finanzielle Bedenken, die nicht geändert werden können, mit anderen Projekten verzahnt, sodass jedes Projekt so konzipiert werden muss, dass sie berücksichtigt werden. Scrum-basierte Teams arbeiten dann innerhalb dieser festgelegten Grenzen und bemühen sich ernsthaft, ihre Aktivitäten selbst auszuwählen und zu optimieren.
Die sorgfältige Abgrenzung dieser Grenzen – die nicht dem Team überlassen bleibt – ist meiner Meinung nach jedoch ein wesentlicher Grund dafür, warum „Scrum“ als praktikable Strategie wahrgenommen wird. Es ist meiner Ansicht nach eine Mikrostrategie , aber keine Makrostrategie .
Es ist, könnte man sagen, ein „riskanter“ Ansatz, aber wenn dieses Risiko gut eingedämmt ist, könnte es sich als Vorteil erweisen. Aber wenn dieselben Konzepte dann innerhalb des Organisationsbaums auf höhere Ebenen gehoben werden, glaube ich, dass diese Risiken unhaltbar werden. Wir wissen bereits, wie man Führungskräfte auf diesen Ebenen Entscheidungen treffen lässt. Meiner Meinung nach sollten wir Scrum stattdessen „erblühen lassen, wo es gepflanzt wird und wo es manchmal blüht“, nämlich an den Blättern des organisatorischen Projektbaums, um das Ergebnis jedes Projekts so gut wie möglich zu machen .
Leichtigkeitsrennen im Orbit
kinkajou