Teammanager behindern den Scrum-Übergang aufgrund von Zurückhaltung bei der Entwicklerautonomie

Mein Team versucht seit einiger Zeit, auf Scrum umzusteigen, aber es scheint, als würde die bereits bestehende Kultur das Team daran hindern, zu einer neuen Denkweise überzugehen, oder sogar dazu führen, dass es sich in die entgegengesetzte Richtung bewegt.

Als Referenz hat das Team zwei Linienmanager, einen Projektmanager, einen Product Owner und fünf Entwickler.

  • Entwickler haben nie direkten Kontakt mit dem Product Owner. Obwohl argumentiert werden könnte, dass die Linienmanager diese Rolle ausfüllen, da sie die Arbeit für das Team definieren, wird dies von PM bestritten.
  • Die Projektmanagerin besteht darauf, dass sie die „Scrum-Führerin“ ist.
  • PM besteht auch darauf, dass Linienmanager Teil des Dev-Teams sind, da alle Agile-Teams eine „Teamleiter“-Rolle haben und die direkte Überwachung der Arbeit durch LMs in Ordnung ist, da sie schließlich die technischen Leiter sind, was eine gültige Scrum-Rolle ist.
  • PM besteht auch darauf, dass tägliche Standups als Berichtsinstrument dienen.
  • Tägliche Stand-Ups werden von LMs durchgeführt, die damit den täglichen Fortschritt verfolgen, jeden einzelnen Entwickler beaufsichtigen, seinen Ansatz kommentieren und neue Aufgaben zuweisen.
  • 1-3 Tage pro User Story werden von LMs als harte Grenze pro User Story anstelle einer Aufschlüsselungsrichtlinie verwendet. Wenn ein Entwickler 2 Tage für eine User Story überschreitet, erhält er eine E-Mail darüber, wie ein Entwickler für die Einhaltung einer Frist verantwortlich ist.
  • LMs bestehen darauf, dass kollektives Eigentum bedeutet, dass es eine Person pro Feature geben sollte, die für ihre Entwicklung verantwortlich ist.

Kann ich in dieser Situation irgendetwas tun, um dem Team als Entwickler beim Übergang zu einer Scrum-Denkweise zu helfen und zu vermeiden, dass die Moral des Teams aufgrund der daraus resultierenden täglichen Überwachung und Überwachung, die bis zu 10-15% der Arbeitswoche in Anspruch nimmt, gebrochen wird? ?

Warum ist einer der vielen Punkte, die Sie auflisten, ein Problem? Warum haben Sie Probleme damit, dass der PM der Scrum Master ist? Warum haben Sie Probleme mit technischen Leads oder dass sie Ihre Manager sind? Nichts von dem, was Sie aufgelistet haben, ist ein Scrum-Problem. Es wäre hilfreich, wenn Sie uns mitteilen könnten, was Sie möchten und warum es besser ist.
@bharal PM und Scrum Master sind völlig separate Rollen mit unterschiedlichen Anforderungen. Denken Sie an Softwareingenieur vs. Systemadministrator. Scrum hat auch keine Teamleiterrolle, Punkt. Ein Entwicklungsteam organisiert sich nicht selbst, wie es Scrum verlangt, wenn ein technischer Leiter bei den Grundlagen der Implementierung das Sagen hat. Das Problem ist also, dass das Team Scrum nicht implementiert, während es Zeit mit der Implementierung verschwendet.
@bharal Grundsätzlich widerspricht alles, was er aufgelistet hat, Scrum. Das mag an sich kein Problem sein, Scrum ist nicht die Wunderwaffe, manche Unternehmen sind vielleicht besser dran mit traditionellem Command & Control. Aber wenn sie versuchen, Scrum zu machen, dann sind sie vom Kurs abgekommen .
Nein, bei Scrum geht es nicht um die Definition eines Teamleiters oder was auch immer. Es geht darum, eine Umgebung zu schaffen, in der es eine kontinuierliche Feedback-Schleife des Fortschritts und ein kontinuierliches Ergebnis gibt, damit die Endbenutzer wissen, was vor sich geht. Das Ziel von Scrum ist es, dem Management ausreichende Daten zur Verfügung zu stellen, um die Ressourcenplanung zu unterstützen, die Beteiligten frühzeitig auf Probleme aufmerksam zu machen und sicherzustellen, dass die Ergebnisse den Erwartungen entsprechen. Zu sagen „Scrum sagt, dass es keinen Teamleiter gibt“ verfehlt den Punkt – es ist eine Methode zur Sichtbarkeit, nicht irgendwie so zu tun, als ob Entwickler keinen Teamleiter brauchen.
Der Zweck von Scrum besteht nicht darin, das Management über irgendetwas zu informieren – der Zweck von Scrum besteht darin, dass das eigentliche Team diese Dinge selbst erledigt.
@bharal Die Verwendung des Daily Standup als Management-Reporting-Tool steht im völligen Gegensatz zu Scrum. Das Standup soll für die Entwickler sein und so kann der Scrum Master eventuelle Blockaden beseitigen.
@DaveG Nein, das Standup ist ein weiteres Tool, um das Bewusstsein für Probleme auf der Managementebene zu schärfen, damit sie Blocker und kritische Probleme schneller erkennen. Es ist schön für die Entwickler, ja. Aber der einzige Grund , warum die Entwickler es bekommen , ist , weil es einen triftigen Grund für das Management gibt , es zu implementieren . Schauen Sie, Entwickler wollen alle, sagen wir, Ponys. Aber es gibt keinen verdammten Grund für das Management, ihnen Ponys zu geben, also bekommen sie keine. Entwickler wollen alle schnelle Maschinen, und es gibt einen Grund für sie, sie zu bekommen (weniger Zeit zum Kompilieren, sagen wir), also wird das Management sie für die Entwickler bekommen.
@bharal was Sie beschreiben, mag die Art und Weise sein, wie ein Unternehmen arbeiten möchte, aber in diesem Fall sollte es nicht "Scrum" nennen, was es tut. Von scrum.org/resources/what-is-a-daily-scrum : „Das Daily Scrum ist ein internes Meeting für das Entwicklungsteam. Wenn andere anwesend sind, stellt der Scrum Master sicher, dass sie das Meeting nicht stören.“ Es ist kein Werkzeug für das Management, um die Peitsche zu knacken.
@DaveG sicher, aber der Scrum Master nimmt diese Informationen und meldet sich. Oder zumindest tun sie das in jedem vernünftigen Unternehmen. Weil der Scrum Master für andere Dinge verantwortlich ist, als nur geistlos darauf zu achten, dass die Leute stehen oder was auch immer. Sie sind normalerweise auch ein PM oder ein Entwicklungsleiter (denn wie schwer ist es wirklich, an ein paar 10-minütigen Meetings pro Tag teilzunehmen? ). Es ist schön, diese Dinge als "für Entwickler" zu betrachten, aber die Leute, die diese Begriffe fördern, sind das Managementteam. Und sie brauchen einen Grund, sie zu sponsern.
@bharal Nein. Der Scrum Master ist nicht der Manager des Teams. Wenn Sie so arbeiten möchten, wie Sie es beschreiben, ist das in Ordnung. Es ist einfach nicht Scrum.
@DaveG Ich bin wirklich neugierig, ob es langlaufende Teams (mehr als ein Jahr) gibt, die nur Scrum-Master haben? Ich weiß, dass "Abschaumtrainer" darüber schreien, dass dies wichtig ist ... aber es scheint eine gigantische Geldverschwendung zu sein. Außerdem ist Scrum eine Methodik, die durch Ergebnisse definiert wird, und keine vorgeschriebene Erfolgsformel.
@bharal Ich habe früher in einem Unternehmen gearbeitet, in dem sich die Führungskräfte stark in Scrum eingekauft haben. Wir hatten eine riesige Klasse, die von Ken Schwaber unterrichtet wurde, wir verbrachten endlose Stunden damit, die Rollen zu diskutieren. Ich sage nicht, dass Scrum der einzig wahre Weg ist, ich sage nur, dass ich ziemlich gut weiß, wie es funktionieren soll. Der Scrum Master erledigt nicht nur 10 Minuten Arbeit am Tag. Sie versuchen auch, die Hindernisse aus dem Weg zu räumen, stellen sicher, dass der Produktmanager tatsächlich seinen Teil leistet, stellen sicher, dass Manager das Team nicht mitten im Sprint belästigen usw. Wahrscheinlich erledigen sie auch andere Aufgaben, aber „managen“ das Team nicht .
@DaveG richtig, aber wenn Sie anfangen zu sagen "Hindernisse aus dem Weg räumen", ist das so ziemlich das, was "ein Team leiten" beinhaltet. Die Rolle ist nur für den technischen Leiter oder Manager des Teams maßgeschneidert, da sie Autorität und ein Verständnis für ein Team erfordert. Die Scrum-Leute lieben es, einen Haufen Geld zu verlangen, um neue Rollen für Scrum Master zu schaffen (die wiederum großspurig postulieren, dass das Unternehmen mehr Training braucht usw.), aber die Rolle ist nur eine Managerrolle.
„Wenn ein Entwickler mehr als 2 Tage an einer User Story arbeitet, erhält er eine E-Mail darüber, wie ein Entwickler für die Einhaltung einer Frist verantwortlich ist“, wird es Ihnen sehr schwer machen, „die Moral des Teams nicht durch tägliche Überwachung und Überwachung zu brechen daraus resultierend, dass" und "bis zu 10-15% der Arbeitswoche in Anspruch nehmen" bedeutet, dass Sie es falsch machen. 2 Minuten pro Person, max. Sie sollten 15 Minuten pro Tag nicht überschreiten, was nicht viel anders ist als ein traditionelles einstündiges Statusmeeting einmal pro Woche.

Antworten (5)

Mal sehen, was hier falsch ist:

  1. Der Projektmanager sollte absolut nicht der Scrum-Leader sein. Absolut nicht. Diese Person hat nicht die geringste Ahnung, was „Scrum“ bedeutet.

  2. Linienmanager sollten auf keinen Fall Teamleiter sein und auf keinen Fall Teil des Entwicklungsteams sein.

  3. Tägliches Standup wird vom Scrum Leader durchgeführt. Nicht vom Vorgesetzten. Nicht vom Projektleiter. Der tägliche Standup dient NICHT der Berichterstattung.

  4. Der Projektleiter versteht die Bedeutung des Wortes „Termin“ nicht.

Wenn man Ihre anderen Kommentare hinzufügt, scheint dies eine absolut giftige und seelenzerstörende Umgebung zu sein. Bist du glücklich dort zu arbeiten? Gehst du gerne zur Arbeit oder hast du Angst davor?

Versuchen Sie nicht einmal zu helfen. Stellen Sie sicher, dass Ihr Lebenslauf gut ist, und suchen Sie nach einem besseren Job in einem besseren Umfeld.

Daily Standup wird vom Team für das Team durchgeführt. Der Scrum Master muss nicht einmal anwesend sein.
Es stellte sich heraus, dass Sie in Bezug auf die Umwelt absolut und hundertprozentig Recht hatten, nachdem ich diese Bedenken trotzdem geäußert hatte. Der konstruktiven Kündigung, die danach kam, ist er zumindest ausgewichen
Eine giftige und seelenzerstörende Umgebung … die Scrum implementiert. Klingt nach all den Orten, an denen ich gearbeitet habe, die Scrum verwendet haben. Muss nur ein verrückter Zufall sein, dass all diese Orte Scrum lieben.
^ Arbeitet derzeit in einer solchen Umgebung als Scrum Master

Mein Team versucht seit einiger Zeit, auf Scrum umzusteigen,

Ich würde sagen, das hat es nicht. Scrum-Begriffe wurden herumgeschleudert und missbraucht, aber das war es auch schon. Es ist kein Übergang sichtbar.

Ein Übergang würde Scrum Master erfordern, die ihn leiten. Ein Plan für den Übergang (vielleicht als eigenes Scrum-Projekt). Und Unterstützung durch das obere Management. Beides kann ich in deiner Beschreibung nicht erkennen.

Da kann man meiner Erfahrung nach nichts wirklich machen. Die Machthaber werden nicht einfach absteigen und aufgeben. Die Existenz von 4(!) Personen mit dem Titel „Manager“ oder „Eigentümer“ und nur fünf Entwicklern im Vergleich bedeutet, dass sie zu viel zu verlieren haben. Die Implementierung von Scrum würde bedeuten, dass mindestens zwei von ihnen ihre Stelle verlieren und einer möglicherweise für eine andere Position ausgebildet wird, die völlig anders ist als seine vorherige Stellenbeschreibung. Sie werden keine konstruktive Rolle in ihrer eigenen Obsoleszenz spielen .

Wenn das obere Management diesen Übergang nicht erzwingt, und ich meine erzwingen , nicht „erwünschen“, wird dies nicht geschehen. Sie werden an ihren Jobs festhalten. Es geht nicht um Kultur, sondern darum, dass sie mit Scrum sehen, dass das, was sie anbieten, nicht benötigt wird. In diesem Geschäft läuft ihnen die Zeit davon, und jede Verzögerung, jedes Problem beim Übergang wird ihnen einen weiteren fetten Gehaltsscheck bescheren.

Tut mir leid, so negativ zu sein. Abgesehen von der Suche nach einem Job, der Scrum tatsächlich anbietet, sind die besten Optionen, die Sie haben, den Kopf unten zu halten und zu hoffen, dass das obere Management seinen Job macht, um diesen Übergang durchzusetzen . Ein erster Blick darauf wären obligatorische Schulungen, externe Coaches vor Ort und die Besetzung der Rolle des Scrum Masters.

Bis dahin viel Glück und halten Sie Ihren Lebenslauf auf dem Laufenden.

Richtig umgesetzt, werden einige Leute nicht benötigt, sie drängen sich um Positionen. Das wird seinen eigenen Lauf nehmen. Entwickler halten am besten den Kopf gesenkt und schauen sich die Show an.
Es ist nicht so schlimm. Ich habe einmal ein Unternehmen mit 18 Managern und 3 Entwicklern gesehen.
@gnasher729 Eigentlich ist es immer noch schlimm. Ihre Situation ist im Vergleich dazu einfach viel, viel schlimmer... Ein Manager sollte für mehrere SCRUM- Teams da sein . Das OP hat derzeit 5 Manager für ein einzelnes unvollständiges SCRUM-Team.
@gnasher729 was zum Teufel haben all diese Manager getan ? Wie haben sie sich überhaupt beschäftigt aussehen lassen? Oder waren sie alle jeden Tag in tagelangen Besprechungen miteinander?

Kann ich in dieser Situation irgendetwas tun, um dem Team zu helfen?

Ihr Unternehmen scheint eine gemeinsame Phase zu durchlaufen, in der jeder seine eigene Interpretation davon hat, was Scrum sein sollte, und nach seiner eigenen Vision handelt. Das wird zwangsläufig scheitern.

Jedes Unternehmen implementiert Scrum auf seine eigene Art und Weise. Auch wenn es unternehmensübergreifende Gemeinsamkeiten geben mag, ist es meiner Erfahrung nach am wichtigsten, dass alle auf derselben Seite stehen.

Wenn Sie in der Lage sind, Schulungen anzubieten oder vorzuschlagen, könnte dies der Schlüssel zum Erfolg sein.

Bringen Sie die Führungskräfte zusammen, erörtern Sie, wie Scrum in Ihrem Unternehmen funktionieren soll, und schulen Sie dann alle im Scrum-Prozess Ihres Unternehmens.

Sie müssen offen dafür sein, dass Ihre speziellen Ideen für Scrum möglicherweise nicht die sind, die für Ihr Unternehmen vorgesehen sind. Sie und alle anderen müssen auf die gleiche Seite kommen.

Das Unternehmen bietet Schulungen an, die auch dem entsprechen, was ich vorgeschlagen habe. Für mich scheint es ein Team-Management-Problem zu sein
@VictorS das impliziert, dass ein Veränderungsprogramm nur fehlschlägt, weil Manager entweder unwissend oder inkompetent sind. Ist es nicht wahrscheinlicher, dass verschiedene Personen im Unternehmen unterschiedliche Probleme haben und daher unterschiedliche Vorstellungen davon haben, was Scrum erreichen soll? Ich denke, darauf will Joe hinaus. Anstatt das Problem als „Wie bringe ich dieses Team zu Scrum (TM)“ zu formulieren, könnte es hilfreicher sein, die Probleme des Unternehmens herauszuarbeiten und eine gemeinsame Basis für eine Lösung zu finden, die von Scrum inspiriert, aber letztendlich von diesen Teams geleitet wird sich.
@JimmyBreck-McKye Es scheint mir, dass die Antwort von bharal zu ihrer Perspektive passt. Ich bin mir nicht sicher, ob es da Gemeinsamkeiten geben kann, haha
Es könnte hilfreich sein, wenn das Unternehmen des OP den Begriff „Scrum“ einfach aufgibt. Man muss kein Scrum-Guru sein, um zu sehen, dass alles, was das OP auflistet, Scrum diametral entgegengesetzt ist. Wenn das Unternehmen es nur „Managementverfahren“ nennen würde, mag es das OP vielleicht immer noch nicht, aber das ganze „Das ist/ist nicht Scrum“-Argument würde verpuffen und alle könnten sich auf die Probleme konzentrieren.
@JoeStrazzere Genau, über die Definition von Scrum zu streiten ist eine Zeitverschwendung. Aber was passiert, wenn ein neuer Entwickler dem Team beitritt? Oder Management-Update-Verfahren? Oder Entwickler zusammen ein Bier trinken? Einfach zu sagen „Hey, unser neuer Prozess ist agil, hier sind die Regeln“ beseitigt das Problem vollständig. Wenn Sie dem Team sagen: "Reden Sie nicht darüber", wird das Gespräch verborgen bleiben, aber es wird nicht verschwinden. Sofern das Management keine ernsthaften Kontrollprobleme hat (klingt danach), sollte das Entfernen des Wortes „Scrum“ ein Kinderspiel sein.

Ihr Unternehmen hat nicht auf Scrum umgestellt, es hat auf das Scrum-Vokabular umgestellt. Es ist eine sehr häufige Situation.

Während die oberste Antwort vorschlägt zu gehen, was in der Tat die bequemere Option ist, gibt es zwei Wege, die Sie einschlagen können, wenn Sie bleiben und den Übergang unterstützen möchten:

  1. Vergessen Sie Scrum als Ganzes. Sehen Sie sich Agile im Allgemeinen an und versuchen Sie, Ihrem Team einige der Konzepte vorzustellen. Beispiele sind User Stories (Wer ist der Benutzer dieser Funktion und was möchte er damit tun?), Pair Programming, automatisierte Builds, automatisiertes Testen, eine Definition of Done und vieles mehr.

  2. Suchen Sie nach jemandem, der einen Scrum-Übergang unterstützt und einen gewissen Einfluss im Unternehmen hat. Überzeugen Sie sie, professionelle Scrum-Trainer für mindestens ein oder zwei Wochen einzustellen, um das Ganze in Gang zu bringen. Der Übergang Ihres Unternehmens ist keine Ausnahme, sondern die Norm; Das bedeutet, dass Scrum Trainer viel Erfahrung im Umgang mit solchen Situationen haben.

Das Problem ist, dass Sie den Sinn dieser Frameworks verfehlt haben.

Der Zweck eines Frameworks besteht darin, einen Mehrwert zu bieten . Ein gut ausgeführtes Framework ist eines , das mehr Wert bietet als alles zuvor und nicht eines, bei dem die "Regeln" genau befolgt werden. Die Regeln spielen keine Rolle, der Wert schon.

Zurück zu Agile und Scrum – sie haben sich durchgesetzt, weil sie einen Mehrwert bieten, wenn es um neue Daten geht, auf die das Management reagieren kann.

Daten müssen messbar sein. Wenn mehr Dinge messbar sind, ist das ein guter Wert. Wenn Daten genauer gemessen werden, ist das auch gut.

Das Hauptziel von Scrum besteht darin, dem Management ausreichend Daten zur Verfügung zu stellen, um die Ressourcenplanung zu unterstützen, die Beteiligten frühzeitig auf Probleme aufmerksam zu machen und sicherzustellen, dass die Ergebnisse den Erwartungen entsprechen. Zu sagen „Scrum sagt, dass es keinen Teamleiter gibt“ verfehlt den Punkt – es ist eine Methode zur Sichtbarkeit, nicht irgendwie so zu tun, als ob Entwickler keinen Teamleiter brauchen.

Das ist das Problem mit SCRUMs Definition von „kein Teamleiter“ usw. Es gibt kein wirkliches Argument dafür, warum dies einem Leiter vorgezogen werden sollte. Gibt es mehr Daten? Mehr Sichtbarkeit? Gibt es etwas , das mehr gemessen werden könnte, als wenn es einen Anführer gäbe?

Sobald Sie verstehen, dass die Bereitstellung von Daten für das Management das Wichtigste ist, wird alles einfacher. Kämpfen Sie nicht für die „korrekte Implementierung eines Frameworks“. Frage dich stattdessen jeden Tag:

  • Wie kann ich sichtbare Daten erstellen, auf die das Management reagieren kann? Kann ich ein Widget-Board erstellen, das den Fortschritt anzeigt>
  • Wie kann ich genauere sichtbare Daten erstellen? Kann ich eine Website erstellen, die Kernfunktionen und deren Testabdeckung auflistet?

So bieten Sie dem Management einen echten Mehrwert und schaffen echte Wachstumschancen.

Der versprochene Wert von Scrum ergibt sich hauptsächlich daraus, dass die Entwickler die Möglichkeit haben, ihre Arbeitslast selbst zu optimieren und zu verteilen und der Summe zu ermöglichen, einen besseren Wert zu liefern als ihre Teile zusammen. Ja, es ermöglicht auch mehr Sichtbarkeit, einfach weil alle an allem beteiligt sind. Das Fehlen von Befehl und Kontrolle kann hinderlich sein, aber ich sehe nicht, wie die Datenbereitstellung – die per Definition inkrementell ist – im Grunde nicht das Gegenteil davon ist. Wenn überhaupt 5 Personen (plus TLs, die sie konsultieren) darüber nachdenken dürfen, was das Management in ihren Daten sehen möchte, wird dies mit Sicherheit den Wert steigern
Es sei denn, Sie meinen Daten wie Daten darüber, was das Team tut und wie es täglich Fortschritte macht, wofür Scrum absolut nicht da ist.
Stand-Ups, User Story Breakdowns etc. sind also nicht das, was für Sichtbarkeit sorgt, dafür gibt es andere Tools. Ich würde diesen Artikel darüber vorschlagen, was Sichtbarkeit in Scrum bedeutet charlenedickson.wordpress.com/…
@VictorS Nein, der Wert von Scrum und Agile liegt in der Aufwärtsmobilität von Daten, sodass Sie mit empirischen Beweisen umgehen können, um Entscheidungen zu treffen (im Gegensatz zu Vermutungen und Annahmen). Bei den „Daten“ handelt es sich um Informationen über den Fortschritt eines Projekts. Aus diesem Grund verwenden Sie SCRUM.
kannst du dazu eine Quelle nennen? Ich kann dafür keine Unterstützung finden, außer Warnungen davor.
@VictorS und nehmen wir an, Sie implementieren dies - es geht nicht "nur zur Arbeit". Die Teammitglieder brauchen Anleitung und Training ... aber woher wissen Sie, wer was braucht? und all dieses Training wird Zeit brauchen. Sie werden weniger produktiv sein ... also wie viel produktiver müssen Sie sein, um dies auszugleichen? Wie viel produktiver glauben Sie, können Sie sein?
@Victor kurz gesagt, Scrum ist eine schreckliche Idee. drücke es nicht, es wird nicht funktionieren, noch nicht.
Nun, zunächst einmal senkt es die Kosten für das mittlere Management, und mein Unternehmen ist zufälligerweise mittelschwer und mit sinkenden Renditen. Es gibt auch obligatorische Schulungen, was bedeutet, dass das Management mit dem Produktivitätsabfall einverstanden ist. Haben Sie versucht, selbst Bücher zu kaufen?
@VictorS Mir ist kein Unternehmen bekannt, das mittlere Manager entlassen hat, um SCRUM zu implementieren und darüber hinaus zu einer Produktivitätssteigerung zu führen. Sehen Sie, Sie wollen in die Führungsebene aufsteigen, also fangen Sie an, wie ein Manager zu denken. Diese ganze "Kürzung des mittleren Managements" ist lächerlich - wer wird Ihren Urlaub genehmigen? Wer entscheidet, ob das Team mehr Ressourcen benötigt? Wer entscheidet, wer entlassen oder befördert wird? In welche Richtung sollte die technische Abteilung gehen? Ihre Führungskräfte haben nicht die Zeit für so etwas.
@VictorS las über Googles Experiment mit einer völlig flachen Kultur und wie schnell sie diese Vorstellung losgeworden sind. Als Manager möchten Sie die Probleme, mit denen ein Team konfrontiert ist, reduzieren und nicht die Schulung erhöhen, die es benötigt, um funktionsübergreifend zu sein. Sie möchten mehr Daten haben, um Ihre Entscheidungen zu rechtfertigen, kein neues Betriebssystem erstellen und keine Daten haben, um dies zu rechtfertigen.
Scrum ist weder das, was sie ausprobiert haben, noch eine flache Hierarchie. Es entspricht im Grunde der Trupptaktik, wenn die Linieninfanterie Befehl und Kontrolle ist. Trupps erhalten Ziele, die sie mit allen ihnen bekannten Mitteln innerhalb des Geltungsbereichs erledigen. Linieninfanterie marschiert auf Befehl in Formation und schießt auf Befehl. Ich gehe davon aus, dass Sie in einer traditionellen Führungsposition sind und inzwischen mehr als 15 Jahre Erfahrung haben, was die Akzeptanz erschweren könnte. Es steigert nachweislich die Produktivität. Ich empfehle dringend, mehr Forschung mit einem offenen Geist zu betreiben.
Teammanager behindern den Scrum-Übergang aufgrund von Zurückhaltung bei der Entwicklerautonomie
AntwortenHierDatenschutz-Bestimmungen1y, 0v