Frage:
Teammanager behindern den Scrum-Übergang aufgrund der Zurückhaltung bei der Entwicklerautonomie
Victor S
2018-10-07 17:04:45 UTC
view on stackexchange narkive permalink

Mein Team versucht seit einiger Zeit, auf Scrum umzusteigen, aber es scheint, dass die bereits bestehende Kultur das Team daran hindert, zu einer neuen Denkweise zu wechseln oder sich sogar in die entgegengesetzte Richtung zu bewegen.

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

  • Entwickler haben niemals direkten Kontakt zum Product Owner. Obwohl argumentiert werden könnte, dass die Vorgesetzten diese Rolle ausfüllen, da sie die Arbeit für das Team definieren, wird dies von PM abgelehnt.
  • Die Projektmanagerin besteht darauf, dass sie die 'Scrum-Leiterin' ist.
  • PM besteht auch darauf, dass Vorgesetzte Teil des Entwicklerteams sind, da alle agilen 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 Stand-ups als Berichterstellungstool dienen.
  • Tägliche Stand-ups werden von LMs ausgeführt, die damit den täglichen Fortschritt verfolgen, jeden einzelnen Entwickler überwachen und ihre Kommentare abgeben Gehen Sie vor und weisen Sie neue Aufgaben zu.
  • 1-3 Tage pro User Story werden von LMs als harte Grenze pro User Story anstelle einer Aufschlüsselungsrichtlinie verwendet. Wenn ein Entwickler mehr als 2 Tage für eine User Story benötigt, 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 pro Feature eine Person für die Entwicklung verantwortlich sein sollte.

Kann ich in dieser Situation etwas tun, um dem Team als Entwickler beim Übergang zu einer Scrum-Denkweise zu helfen und zu vermeiden, dass die Moral des Teams durch die daraus resultierende tägliche Überwachung und Überwachung beeinträchtigt wird? 10-15% der Arbeitswoche?

Warum ist eines der vielen Elemente, die Sie auflisten, ein Problem?Warum hast du 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 getrennte Rollen mit unterschiedlichen Anforderungen.Denken Sie Software Engineer vs System Admin.Scrum hat auch keine Teamleiterrolle.Ein Entwicklerteam organisiert sich nicht selbst, wie es Scrum verlangt, wenn ein technischer Leiter die Grundlagen der Implementierung festlegt.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 könnte an sich kein Problem sein, Scrum ist nicht die Silberkugel, einige Unternehmen könnten mit traditioneller Führung und Kontrolle besser zurechtkommen.Aber wenn sie "versuchen", Scrum zu machen, dann sind sie * weit * vom Kurs entfernt.
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 Rückkopplungsschleife des Fortschritts und ein kontinuierliches Ergebnis gibt, damit die Endbenutzer wissen, was vor sich geht.Ziel von Scrum ist es, dem Management ausreichende Daten zur Verfügung zu stellen, um die Planung von Ressourcen zu unterstützen, die Stakeholder frühzeitig auf Probleme aufmerksam zu machen und sicherzustellen, dass die Ergebnisse den Erwartungen entsprechen.Die Aussage "Scrum sagt, dass es keinen Teamleiter gibt" geht am eigentlichen Punkt vorbei - es ist eine Methode zur Sichtbarkeit, die nicht so tut, als ob Entwickler keinen Teamleiter benötigen.
Der Zweck von Scrum besteht nicht darin, das Management über irgendetwas zu informieren - der Zweck von Scrum besteht darin, das eigentliche Team diese Dinge selbst tun zu lassen.
@bharal Die Verwendung des täglichen Standups als Management Reporting Tool widerspricht völlig Scrum.Der Standup soll für die ** Entwickler ** sein, damit der Scrum Master alle Blockaden beseitigen kann.
@DaveG Nein, der Standup ist ein weiteres Tool, um das Bewusstsein für Probleme auf Managementebene zu schärfen, sodass sie Blocker und kritische Probleme schneller erkennen können.Es ist * schön * für die Entwickler, ja.Der einzige Grund, warum die Entwickler es bekommen, ist, dass * es einen tragfähigen Grund für das Management gibt, es zu implementieren *.Entwickler wollen alle zum Beispiel Ponys.Aber es gibt keinen verdammten Grund für das Management, ihnen Ponys zu geben, damit sie keine bekommen.Entwickler wollen alle schnelle Maschinen, und es gibt * einen * Grund für sie, sie zu bekommen (z. B. weniger Zeit für das Kompilieren), sodass das Management sie für die Entwickler bekommt.
@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.Von https://www.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 nicht störendas Treffen".Es ist kein Werkzeug für das Management, um die Peitsche zu knacken.
@DaveG sicher, aber der Scrum Master nimmt diese Informationen und berichtet.Oder zumindest tun sie dies in jeder vernünftigen Gesellschaft.Weil der Scrum Master für andere Dinge verantwortlich ist, als nur dafür zu sorgen, dass die Leute stehen oder was auch immer.Sie sind normalerweise auch PM oder Entwickler (weil es wirklich schwierig ist, 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 sponsern, 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 langjährige (mehr als ein Jahr) Teams gibt, die * nur * Scrum-Meister haben?Ich weiß, dass "Abschaumtrainer" schreien, dass dies wichtig ist ... aber es scheint eine titanische Geldverschwendung zu sein.Außerdem ist Scrum eine Methodik, die durch Ergebnisse definiert wird, und keine Erfolgsformel.
@bharal Ich habe in einer Firma gearbeitet, in der sich die Manager stark für Scrum entschieden haben.Wir hatten eine große Klasse von Ken Schwaber unterrichtet, wir verbringen 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 pro Tag.Sie versuchen auch, die Hindernisse zu beseitigen, sicherzustellen, dass der Produktmanager tatsächlich seinen Teil dazu beiträgt, dass die Manager das Team während des Sprints nicht belästigen usw. Wahrscheinlich erledigen sie auch andere Arbeiten, aber ** nicht ** "Management "des Teams.
@DaveG richtig, aber wenn Sie anfangen, "Hindernisse beseitigen" zu sagen, ist das ziemlich genau das, was "Teamführung" bedeutet.Die Rolle ist nur für den Team-Tech-Lead oder -Manager maßgeschneidert, da sie Autorität und Verständnis für ein Team erfordert.Die Scrum-Leute lieben es, eine Menge Geld zu verlangen, um neue Rollen für Scrum-Meister zu schaffen (die wiederum großartig postulieren, wie das Unternehmen mehr Schulungen usw. benötigt), aber die Rolle ist nur eine Manager-Rolle.
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (https://chat.stackexchange.com/rooms/84191/discussion-between-daveg-and-bharal).
"Wenn ein Entwickler mehr als 2 Tage für eine User Story benötigt, erhält er eine E-Mail darüber, wie ein Entwickler für die Einhaltung einer Frist verantwortlich ist." Dies wird es für Sie sehr schwierig machen, "zu vermeiden, dass die Moral des Teams durch tägliche Überwachung und Überwachung verletzt wirdDaraus resultiert, dass "und" 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 sich nicht wesentlich von einer herkömmlichen einstündigen Statusbesprechung einmal pro Woche unterscheidet.
Fünf antworten:
nvoigt
2018-10-07 17:52:20 UTC
view on stackexchange narkive permalink

Mein Team versucht seit einiger Zeit, auf Scrum umzusteigen.

Ich würde sagen, dass dies nicht der Fall ist. Scrum-Begriffe wurden herumgeschleudert und missbraucht, aber das war's. Es ist kein Übergang sichtbar.

Für einen Übergang müssten Scrum Masters ihn führen. Ein Plan für den Übergang (möglicherweise als eigenes Scrum-Projekt). Und Unterstützung durch das obere Management. Ich kann beides in Ihrer Beschreibung nicht sehen.

Nach meiner Erfahrung können Sie nichts wirklich tun. Die Machthaber werden nicht einfach aussteigen und es aufgeben. Die Existenz von 4 (!) Personen mit dem Titel "Manager" oder "Eigentümer" und nur fünf Entwicklern im Vergleich bedeutet, dass zu viel für sie zu verlieren ist. Die Implementierung von Scrum würde bedeuten, dass mindestens zwei von ihnen ihren Arbeitsplatz verlieren und einer möglicherweise auf eine andere Position geschult wird, die völlig anders ist als die vorherige Stellenbeschreibung. Sie werden keine konstruktive Rolle in ihrer eigenen Veralterung spielen.

Wenn das obere Management diesen Übergang nicht erzwingt und ich meine erzwingen , nicht "wünschen", wird dies nicht passieren. Sie werden an ihren Jobs festhalten. Es geht nicht um Kultur, es geht um die Tatsache, dass sie mit Scrum sehen, dass das, was sie anbieten, nicht benötigt wird. Sie haben keine Zeit mehr in diesem Geschäft und jede Verzögerung, jedes Problem bei der Umstellung wird ihnen einen weiteren fetten Gehaltsscheck gewähren.

Tut mir leid, dass ich so negativ bin. Abgesehen von der Suche nach einem Job, der Scrum tatsächlich anbietet, besteht die beste Möglichkeit darin, den Kopf gesenkt zu halten und zu hoffen, dass das obere Management seine Aufgabe erfüllt, diesen Übergang durchzusetzen . Ein erster Blick darauf wäre eine obligatorische Schulung, externe Trainer vor Ort und die Übernahme der Rolle des Scrum Masters.

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

Richtig umgesetzt werden einige Leute nicht notwendig sein, sie drängen sich um ihre Position.Dies wird seinen eigenen Kurs nehmen.Entwickler halten am besten den Kopf gesenkt und schauen sich die Show an.
Es ist nicht so schlimm.Ich habe einmal eine Firma mit 18 Managern und 3 Entwicklern gesehen.
@gnasher729 Eigentlich ist es immer noch schlecht.Ihre Situation ist nur viel, viel schlimmer im Vergleich ... 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 gemacht?Oder waren sie alle jeden Tag in tagelangen Treffen miteinander?
gnasher729
2018-10-07 21:41:22 UTC
view on stackexchange narkive permalink

Mal sehen, was hier falsch ist:

    Der Projektmanager soll absolut nicht der Scrum-Leader sein. Absolut nicht. Diese Person hat nicht die geringste Ahnung, was "Scrum" bedeutet.

  1. Vorgesetzte sollen absolut nicht Teamleiter sein und absolut nicht Teil des Entwicklungsteams. + Nicht vom Vorgesetzten. Nicht vom Projektmanager. Täglicher Standup dient NICHT zur Berichterstattung.

  2. Der Projektmanager versteht die Bedeutung des Wortes "Frist" nicht.

    3. ol>

    Wenn Sie Ihre anderen Kommentare hinzufügen, scheint dies eine absolut giftige und seelenzerstörende Umgebung zu sein. Bist du glücklich dort zu arbeiten? Gehst du gerne zur Arbeit oder fürchtest du dich davor?

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

Der tägliche Standup wird vom Team für das Team durchgeführt.Der Scrum Master muss nicht einmal da sein.
Es stellte sich heraus, dass Sie absolut hundertprozentig Recht mit der Umwelt hatten, nachdem ich diese Bedenken trotzdem geäußert hatte.Zumindest der konstruktiven Entlassung, die danach kam, ausgewichen
Eine giftige und seelenzerstörende Umgebung ... die Scrum implementiert.Klingt nach all den Orten, an denen ich gearbeitet habe und an denen Scrum verwendet wurde.Es muss nur ein verrückter Zufall sein, dass all diese Orte Scrum lieben.
Joe Strazzere
2018-10-07 17:15:00 UTC
view on stackexchange narkive permalink

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

Ihr Unternehmen scheint eine gemeinsame Phase zu durchlaufen, in der jeder seine eigene Interpretation von Scrum hat sollte sein und handelt nach ihrer eigenen Vision. Das wird sicherlich scheitern.

Jedes Unternehmen implementiert Scrum auf seine eigene Art und Weise. Obwohl es Gemeinsamkeiten zwischen Unternehmen geben kann, ist es meiner Erfahrung nach am wichtigsten, dass alle auf derselben Seite sind.

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, versuchen Sie herauszufinden, wie Scrum in Ihrem Unternehmen funktionieren soll, und schulen Sie dann alle im Scrum-Prozess Ihres Unternehmens.

Sie müssen offen sein für die Tatsache, dass Ihre Bestimmte Ideen für Scrum sind möglicherweise nicht die, die für Ihr Unternehmen bestimmt sind. Sie und alle anderen müssen auf derselben Seite sein.

Das Unternehmen bietet Schulungen an, die auch meinen Vorschlägen entsprechen.Für mich scheint es ein Problem des Teammanagements zu sein
@VictorS, das impliziert, dass ein Änderungsprogramm nur fehlschlägt, weil Manager entweder ignorant oder inkompetent sind.Ist es nicht wahrscheinlicher, dass unterschiedliche Mitarbeiter unterschiedliche Probleme haben und daher unterschiedliche Vorstellungen davon, was Scrum erreichen soll?Ich denke, das ist es, worauf Joe hinaus will.Anstatt das Problem als „Wie bringe ich dieses Team zu Scrum (TM)?“ Zu formulieren, ist es möglicherweise hilfreicher, die Probleme des Unternehmens herauszufiltern und eine gemeinsame Grundlage für eine Lösung zu finden, die von Scrum inspiriert, aber letztendlich von diesen Teams geleitet wirdsich.
@JimmyBreck-McKye Es scheint mir, dass die Antwort von Bharal zu ihrer Perspektive passt.Ich bin mir nicht sicher, ob es Gemeinsamkeiten geben kann, haha
Es kann hilfreich sein, wenn das OP-Unternehmen den Begriff "Scrum" einfach aufgibt.Sie müssen kein Scrum-Guru sein, um zu sehen, dass alles, was in den OP-Listen aufgeführt ist, Scrum diametral entgegengesetzt ist.Wenn das Unternehmen es nur "Management Procedures" nannte, würde es dem OP vielleicht immer noch nicht gefallen, aber das gesamte Argument "Dies ist / ist nicht Scrum" würde verdampfen und alle könnten sich auf die Themen 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 haben Entwickler zusammen ein Bier?Wenn Sie einfach sagen "Hey, unser neuer Prozess ist Agile, hier sind die Regeln", wird das Problem vollständig behoben.Wenn Sie dem Team sagen, dass Sie nicht darüber sprechen sollen, bleibt das Gespräch verborgen, aber es verschwindet nicht.Wenn das Management keine ernsthaften Kontrollprobleme hat (hört sich so an), sollte das Entfernen des Wortes "Scrum" ein Kinderspiel sein.
Peter
2018-12-04 01:22:59 UTC
view on stackexchange narkive permalink

Ihr Unternehmen ist nicht zu Scrum übergegangen, sondern zum Scrum-Vokabular. Es ist eine sehr häufige Situation.

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

  1. Vergessen Sie Scrum als Ganzes. Schauen 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öchten sie damit machen?), Pair Programming, Automated Builds, Automated Testing, eine Definition of Done und vieles mehr.

  2. Suchen Sie nach jemandem, der einen Scrum-Übergang unterstützt und eine gewisse Schlagkraft im Unternehmen hat. Überzeugen Sie sie, mindestens ein oder zwei Wochen lang professionelle Scrum-Trainer einzustellen, um das Ganze in Gang zu bringen. Der Übergang Ihres Unternehmens ist keine Ausnahme, sondern die Norm. Das heißt, Scrum-Trainer haben viel Erfahrung im Umgang mit solchen Situationen.

    3. ol>
bharal
2018-10-07 23:19:17 UTC
view on stackexchange narkive permalink

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

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

Zurück zu Agilität und Scrum - sie haben Akzeptanz gefunden, weil sie einen Wert 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 ausreichende Daten zur Verfügung zu stellen, um die Planung von Ressourcen zu unterstützen, die Interessengruppen frühzeitig auf Probleme aufmerksam zu machen und sicherzustellen, dass die Ergebnisse den Erwartungen entsprechen. Die Aussage "Scrum sagt, dass es keinen Teamleiter gibt" geht am eigentlichen Punkt vorbei - es handelt sich um eine Methode zur Sichtbarkeit, die nicht vorgibt, dass Entwickler keinen Teamleiter benötigen.

Das ist das Problem bei der Definition von SCRUM Kein Teamleiter usw. Es gibt kein wirkliches Argument dafür, warum dies einem Führer vorzuziehen ist. Gibt es mehr Daten? Mehr Sichtbarkeit? Gibt es irgendetwas , das mehr gemessen werden kann, als wenn es einen Leiter gäbe?

Sobald Sie verstanden haben, dass die Bereitstellung von Daten für das Management das Schlüsselelement ist, alles wird einfacher. Kämpfe nicht für die "korrekte Implementierung eines Frameworks". Fragen Sie sich 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 Site erstellen, auf der die Kernfunktionen und deren Testabdeckung aufgelistet sind?

Auf diese Weise bieten Sie dem Management einen echten Mehrwert und schaffen echte Wachstumschancen.

Der versprochene Wert von Scrum kommt hauptsächlich von den Entwicklern, die die Möglichkeit haben, ihre Arbeitslast selbst zu optimieren und zu verteilen, und es der Summe ermöglichen, einen besseren Wert als die Teile zusammen zu liefern.Ja, es ermöglicht auch mehr Sichtbarkeit, einfach weil jeder an allem beteiligt ist.Ein Mangel an Befehl und Kontrolle kann behindern, aber ich sehe nicht, wie die Datenlieferung - die per Definition inkrementell ist - im Grunde nicht das Gegenteil davon ist.Wenn überhaupt, können 5 Personen (plus TLs, die sie konsultieren) darüber nachdenken, was das Management in ihren Daten sehen möchte, was mit Sicherheit den Wert erhöht
Es sei denn, Sie meinen Daten wie Daten darüber, was das Team tut und wie es sich täglich weiterentwickelt, wofür Scrum absolut nicht gedacht ist.
Stand-Ups, User Story Breakdowns usw. bieten also keine Sichtbarkeit, dafür gibt es andere Tools.Ich würde diesen Artikel darüber vorschlagen, was Sichtbarkeit in Scrum bedeutet https://charlenedickson.wordpress.com/why-is-visibility-so-important-in-scrum-any-agile-team/
@VictorS nein, der Wert von Scrum und Agile liegt in der Aufwärtsmobilität von Daten, sodass Sie mit empirischen Beweisen als Entscheidungshilfe (im Gegensatz zu Vermutungen und Annahmen) auskommen können.Die fraglichen "Daten" sind Informationen über den Fortschritt eines Projekts.Aus diesem Grund verwenden Sie SCRUM.
Können Sie eine Quelle dazu zitieren?Ich kann keine Unterstützung dafür finden, außer Vorsichtsmaßnahmen dagegen.
@VictorS und sagen wir, Sie implementieren dies - es ist nicht "nur zur Arbeit".Die Teammitglieder brauchen eine Anleitung und Schulung ... aber woher weißt du, wer was braucht?und all dieses Training wird einige Zeit dauern.Sie werden weniger produktiv sein ... also wie viel produktiver müssen Sie sein, um dies auszugleichen?Wie viel produktiver können Sie Ihrer Meinung nach sein?
@Victor kurz gesagt, Scrum ist eine schreckliche Idee.Drück es nicht, es wird sowieso nicht funktionieren.
Zunächst einmal senkt es die Kosten für das mittlere Management, und mein Unternehmen ist zufällig mittelschwer und weist rückläufige Renditen auf.Es gibt auch obligatorische Schulungen, was bedeutet, dass das Management mit dem Produktivitätsverlust gut zurechtkommt.Haben Sie versucht, selbst Bücher zu kaufen?
@VictorS Mir ist nicht bekannt, dass * irgendein * Unternehmen mittlere Manager entlässt, um SCRUM zu implementieren, und dass dies zu einer Steigerung der Produktivität führt.Schauen Sie, Sie möchten zur Managementebene wechseln, also denken Sie wie ein Manager.All dieses "Cut Middle Management" ist lächerlich - wer wird Ihren Urlaub genehmigen?Wer entscheidet, dass das Team mehr Ressourcen benötigt?Wer entscheidet, wen er feuert oder wen er befördert?In welche Richtung sollte die technische Abteilung gehen?Ihre leitenden Angestellten haben keine Zeit für dieses Zeug.
@VictorS las über Googles Experiment mit einer völlig flachen Kultur und wie schnell sie diesen Gedanken loswurden.Als Manager möchten Sie die Probleme, mit denen ein Team konfrontiert ist, * reduzieren * und nicht das Training erhöhen, das 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 versucht haben, noch eine flache Hierarchie.Es ist im Grunde gleichbedeutend mit der Taktik des Trupps, wenn die Linieninfanterie das Kommando und die Kontrolle übernimmt.Trupps erhalten Ziele, die sie mit allen Mitteln erreichen, die sie im Rahmen kennen.Linieninfanterie marschiert in Formation, wenn es gesagt wird, und feuert, wenn es gesagt wird.Ich gehe davon aus, dass Sie eine traditionelle Führungsposition innehaben und über 15 Jahre Erfahrung verfügen, was die Akzeptanz erschweren könnte.Es ist erwiesen, dass es die Produktivität erhöht.Ich empfehle dringend, offener zu forschen.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...