it-swarm-eu.dev

Ist Agile das neue Mikromanagement?

Diese Frage kocht schon seit einiger Zeit in meinem Kopf, deshalb wollte ich diejenigen fragen, die in ihren Entwicklungsumgebungen agilen/Scrum-Praktiken folgen.

Mein Unternehmen hat es endlich gewagt, agile Praktiken zu integrieren, und hat mit einem Team von 4 Entwicklern in einer agilen Gruppe probeweise begonnen. Es waren 4 Monate mit 3 Iterationen und sie tun es weiterhin, ohne für den Rest von uns völlig agil zu werden. Dies ist auf die Tatsache zurückzuführen, dass das Management darauf vertraut, die Geschäftsanforderungen mit einer Reihe von Ad-hoc-Anfragen von oben zu erfüllen.

Kürzlich habe ich mit den Entwicklern gesprochen, die Teil dieser Initiative sind. Sie sagen mir, dass es keinen Spaß macht. Sie dürfen von ihrem Scrum-Master nicht mit anderen Entwicklern sprechen und dürfen keine Anrufe im Arbeitsbereich entgegennehmen (was bis zu einem gewissen Grad in Ordnung sein kann). Wenn ich zum Beispiel mit meinem Freund über Tritte sprechen möchte, der im agilen Team ist, darf ich nicht ohne die Zustimmung des Scrum-Masters. Wer sitzt direkt neben dem agilen Team.

Die Idee von all dem oder dem Agilen ist es, agilen Entwicklern ein vollständiges Vakuum von jeglichen Unterbrechungen zu bieten und sie in mehr als 6 produktive Stunden zu bringen. Nun, Leute, ich bin kein agiler Guru, aber was ich über das agile Rollout-Dokument von Yahoo und ähnliches für andere Organisationen gelesen habe, gibt mir das Gefühl, dass agil nicht billig ist. Es erfordert Ressourcen und Budget, um den Teams Agilität zu verleihen und Probleme zu beheben, wenn sie eintreffen, um sie wieder auf Kurs zu bringen.

Für den Anfang sind Schulungen für Entwickler und Coaching für Manager usw. erforderlich. Der aktuelle Scrum-Meister war ein Manager, der ein paar Tage an einem vom Management bezahlten agilen Schulungskurs teilgenommen hat und jetzt dieses agile Team leitet. Ich habe in der Besprechung auch gehört, dass das agile Manifest nicht vorschreibt, dass agil nicht in Stein gemeißelt ist und für jedes Unternehmen unterschiedlich angepasst wird. Nun, das klingt alles gut und vernünftig.

Zusammenfassend dachte ich immer, dass die Agilität den Entwicklungsteams Harmonie bringen sollte, was zu glücklichen Entwicklern führt. Ich habe jedoch ein ganz anderes Gefühl, wenn ich mit den Entwicklern im agilen Team spreche. Sie sind unglücklich darüber, dass sie nur arbeiten können, den ganzen Tag ruhig sitzen und nur arbeiten, und sie glauben, dass dies nur eine andere Möglichkeit für das Management ist, sie dazu zu bringen, mehr zu arbeiten.

Sagen Sie mir bitte, ob dies eines der Beispiele für bewährte Praktiken ist, die zum Zweck des egoistischen Vorteils für mehr Dollar verwendet werden. Oder vielleicht sind es nur wir, die Entwickler wie ich, und dieses agile Team hat das Gefühl, dass sie nicht gerne in einer Umgebung arbeiten, in der sie nur Arbeit atmen, weil sie bei der Arbeit sind.


Es ist ein Unternehmen im Gesundheitsbereich mit Niederlassungen in den USA. Es fühlt sich definitiv wie ein agiler Cowboy an, was mich wirklich dazu bringt, überhaupt nicht agil zu werden, besonders in meiner jetzigen Firma.

All dies hat damit zu tun, dass das Management völlig billig ist. Schneiden Sie teuren Kaffee für eine billigere Version aus, legen Sie Wert auf Einsparungen und arbeiten Sie produktiv, während Sie so schlank wie möglich bleiben.

Mein Gefühl ist, dass jemand im Management hinter der Tür diese Idee verworfen hat, dass Agilität Sie dazu bringt, mehr zu produzieren, damit wir unseren Vorgesetzten zeigen können, dass wir mit der gleichen Anzahl von Mitarbeitern mehr produzieren. Oder vielleicht können wir so die Mitarbeiterzahl reduzieren, wenn dies der Fall ist.

Sie haben ihre 5 Minuten tägliche Sitzung. Es ist jedoch nicht gestattet, mit jemandem außerhalb seines Teams zu chatten oder zu sprechen. Der Schwerpunkt liegt auf der Arbeit.

81
Smith James

Sie beschreiben eine Managementdiktatur, nicht agil. Bei Agile geht es um eine schrittweise Entwicklung in einem Bereich sich ändernder Anforderungen, nicht darum, den Menschen zu diktieren, wie sie ihre Arbeit individuell erledigen.

89
Sami Lehtinen

Sie dürfen von ihrem Scrum-Master nicht mit anderen Entwicklern sprechen und im Arbeitsbereich keine Anrufe entgegennehmen

Dies ist wirklich nicht Teil der agilen Praktiken - und ein separates Problem.

Eine große Motivation für agile Methoden ist erhöhte Kommunikation zwischen Entwicklern. Das Einschränken der Entwickler- <-> Entwicklerkommunikation ist ein anderes Problem als die agilen Praktiken. Ich sage nicht, dass dies nicht geschieht - es ist offensichtlich so und es wird als Teil des "agilen" Rollouts in Ihrer Organisation gekennzeichnet, aber dies ist wirklich ein anderes Thema als agil (und etwas gegen den Geist der agilen Entwicklung). IMO).

46
Reed Copsey

Das klingt nach einer ziemlich perversen Implementierung von Agile. Agilität sollte, wenn überhaupt, das Mikromanagement reduzieren, nicht erhöhen. Das Team verpflichtet sich und Teil des Prozesses ist, dass das Management darauf vertraut, dass das Team dies erreicht. Das tägliche Scrum ist eine Möglichkeit für die Entwickler, miteinander zu kommunizieren und zu informieren, was sie getan haben und nicht, wie sie ihre Zeit verbracht haben (was ein Fehler ist, den ich an einigen Stellen gesehen habe). Sogar der Schätzprozess sollte die explizite Zeitmessung aus den Schätzungen entfernen, da Sie die relative Komplexität schätzen sollten und nicht, wie lange eine Geschichte dauern wird (ein weiterer häufiger Fehler). Die Kontrolle der von Entwicklern aufgewendeten Zeit ist das Markenzeichen des Mikromanagements, und das Entfernen von Zeit aus dem Prozess ist einer der Grundpfeiler von Agile.

31
jjb

Die Umgebung, die Sie beschreiben, klingt nach Gartenvielfalt pseudo-agiler Bullshit.

Ich habe mich mit Agile beschäftigt, bevor es Agile war. Circa 2000 Ich habe mich mit Codierung beschäftigt, von Extreme Programming gehört, es ausprobiert und es hat mir gefallen. Es gab mir als Entwickler einen Kontext, in dem das Produzieren solider Software das Wichtigste war, und es gab mir Werkzeuge, um viel von dem Mist zu minimieren, der mich verrückt machte. Ich liebte es.

Das Problem heute, das ich erkläre es an anderer Stelle ausführlich , ist, dass die meisten Leute, die heutzutage "Agile übernehmen", nicht daran interessiert sind, etwas zu verbessern, wenn es ihnen unangenehm ist. Für sie ist "Agile" nur ein neuer Stick, um die Entwickler auf die gleiche Weise zu schlagen. Im Gegensatz zu einer Möglichkeit, die Produktivität radikal zu steigern und gleichzeitig den ganzen Mist zu beseitigen, der die Entwicklung verlangsamt.

Jetzt sofort. Ich gründe eine Firma und werde eine Menge XP und eine Reihe anderer Tricks verwenden, die ich in der agilen Welt gelernt habe. Aber gerade wegen Geschichten wie Ihrer zucke ich zusammen, wenn ich heutzutage von einer agilen Adoption höre.

Um Ihre Frage direkt zu beantworten : Agil sollte nicht das neue Mikromanagement sein. Es sollte darum gehen, die Leute, die die eigentliche Arbeit machen, zu befähigen, Scheiße zu erledigen. Aber in Ihrem Fall klingt Agile wie die neueste Lüge, die sie Ihnen erzählen, während sie sich ihren eigenen schlechten Instinkten hingeben. Das tut mir wirklich leid.

24
William Pietri

Das ist nicht agil.

Erstens Scrum ist nicht agil. Scrum ist ehrlich gesagt Bullshit. Ich bin in einem Extreme Programming House aufgewachsen (im wahrsten Sinne des Wortes - ich habe Kent Beck auf dem Sofa meines Vaters sitzen lassen und mit mir über das Testen gesprochen), und ich kann Ihnen direkt sagen, dass Scrum es nicht ist. Scrum ist ein Projektmanagement-Tool - ein definierter Rhythmus für ein Entwicklungsprojekt. Aber es hat nichts über die Entwicklung selbst zu sagen und sehr wenig über Anforderungen, Planung und die Beziehung zum Kunden. XP hat viel zu all dem zu sagen; jede andere Methode, die sich als agil bezeichnen will, muss etwas zur Konversation hinzufügen. Scrum-Befürworter haben es nicht als Prozess beschrieben, sondern als Ein Wrapper für einen Prozess. Ein weiser Mann hat einmal darauf hingewiesen, dass ein Wrapper das ist, was Sie entfernen und wegwerfen, um zu den guten Sachen zu gelangen.

Okay, Scrum Rant Over!

Zweitens ist ein Grundprinzip von XP, von dem ich glaube, dass es für jeden agilen Prozess von grundlegender Bedeutung ist, dass es zentriert auf den Entwickler ist. Dies ist eine Möglichkeit, Entwicklern die Möglichkeit zu geben, die Arbeit zu erledigen, von der sie wissen, dass sie sie erledigen müssen, und die so häufig daran gehindert werden. Ein agiles Team kann als Demokratie oder Autokratie strukturiert sein, aber die Führer sind Entwickler. Es gibt Rollen für Projektmanager und so weiter - wichtige Rollen - aber es geht nicht um Teamführung. Ein Manager - sorry, 'Scrum Master' - dort zu sitzen und Leute herumzukommandieren, ist ein sicheres Zeichen dafür, dass das Team nicht agil ist.

Ich denke, es sollte eine dritte geben. Das gibt es nicht.

23
Tom Anderson

Scrum ist das Bastardkind von Agile. Es ist die wasserfallartigste aller agilen Methoden, und deshalb ist es bei Managern am beliebtesten.

Bei allen agilen Methoden geht es darum, Arbeitscode zu erstellen, ohne dass Mist in die Quere kommt. Lesen Sie das noch einmal. Und wieder.

Alles, was diesem Ziel im Wege steht, unabhängig von den "agilen Regeln", ist schlecht. Wenn die Regeln im Weg sind, ändern Sie die f * * Regeln! Das ist der agile Weg, das macht ihn relevant und effektiv.

Das bestes Beispiel dafür gibt Alistair Cockburn (einer der Urheber des agilen Manifests):

„Stellen Sie 4-6 Personen in einen Raum mit Arbeitsstationen und Whiteboards und greifen Sie auf die Benutzer zu. Lassen Sie sie alle ein bis zwei Monate laufende, getestete Software an die Benutzer liefern und lassen Sie sie ansonsten in Ruhe. “

Wenn das für die Qualität der Leute funktioniert, die Sie haben, dann ist das alles, was Sie brauchen. Sie benötigen keinen Scrum Master oder eine "agile" Methode. Wenn es für Sie funktioniert, sich in ein tägliches Gedränge zu setzen, dann tun Sie es mit f * * *. Dich aufstehen zu lassen ist nur eine erbärmliche Aufhebung deiner Fähigkeit, selbst zu denken.

Es gibt eine Antwort für die Art von Agilität, die Sie tun. Es ist das. Drucken Sie es aus und stecken Sie es irgendwo fest, wenn niemand in der Nähe ist, und lassen Sie es selbst entdecken.

16
gbjbaanb

Der derzeitige Scrum-Meister war ein Manager, der ein paar Tage an einer vom Management bezahlten agilen Schulungsklasse teilgenommen hat. Jetzt leitet er dieses agile Team.

Das ist dein Problem. Managements wollen etwas Agiles, sie wissen nicht wirklich, was es ist, und sie zwingen es den Teams auf. Das ist ziemlich genau das, was zu tun ist, wenn Sie die Produktivität Ihrer Entwickler erheblich verringern möchten;)

Der neue Prozessvorschlag sollte von den Entwicklern stammen. Oder zumindest von ihnen geprüft und genehmigt wenn es sich um eine Managementidee handelt.

In jedem Fall, wenn die Entwickler es ablehnen, nicht implementieren! Oder es wird die Katastrophe sein, die Sie beschreiben.

11
user2567

"Agile" und jede andere "Managementmethode" wird häufig missbraucht, um Menschen Mikromanagement aufzuzwingen. OTOH wird manchmal auch missbraucht, um schlechte Verarbeitung zu verteidigen.

"we are Agile" ist die häufigste Entschuldigung, die ich für mangelnde Planung, mangelndes Nachdenken über Design, Funktionen, Qualität und Veröffentlichungszyklen höre. Dies in der Regel von Entwicklern und dem unteren Management. Es ist wahnsinnig auch die am häufigsten verwendete Ausrede, die ich von mittleren Managern, Architekten, Verkäufern usw. für Mikromanagement, ständig wechselnde Fristen und Featurelisten höre, um Menschen Überstunden zu erzwingen (die ständig wechselnden Fristen und Featurelisten stellen dies natürlich sicher) usw. .

Die beiden stehen natürlich oft im direkten Widerspruch und können im selben Projekt stattfinden.

9
jwenting

Um Ihre ursprüngliche Frage zu beantworten: Ist Agile das neue Mikromanagement? Ich würde nein sagen.

Lesen Sie zuerst this (Agiles Manifest) und Sie werden feststellen, dass es nicht aufgeführt ist, nicht mit Ihren Mitentwicklern zu sprechen.

Tatsächlich ist "Individuen und Interaktionen" genau das Gegenteil davon, nicht mit Ihren Mitentwicklern zu sprechen.

7
Ian

Agile sollte die neue Selbstverwaltung sein. Wenn Agile korrekt praktiziert wird, werden viele der Entscheidungen von einem Kunden und Entwickler getroffen, die eine vernünftige User Story erstellen Dies wird dem Backlog hinzugefügt, wenn Aufgaben identifiziert werden.

Beim täglichen Scrum geht es um Kommunikation, nicht um Management. Es wird einige Diskussionen über Priorität und Lastausgleich geben, aber die Person, die beim Scrum verwaltet wird, ist hoffentlich das Scrum Meister. Als Entwickler nehme ich teil, sage, was ich getan habe, was ich tun werde und welche Hilfe ich brauche. Dann sollte der Scrum Master aktiv werden und Hindernisse für meinen Fortschritt beseitigen.

Agile Teams dürfen nicht das Gefühl haben, dass die tägliche Arbeit hierarchisch verwaltet wird. Wenn Entscheidungen von jemandem an der Spitze einer hierarchischen Organisation aus der Ferne getroffen werden, ist dies der Fall Zeit für die Dezentralisierung der Entscheidungsfindung! Für einige Leute und einige Organisationen kann dies eine Brücke zu weit sein. Wenn Folgendes für Ihre Organisation nicht zutrifft:

Lebe das Agiles Manifest

"Wir entdecken bessere Möglichkeiten für die Entwicklung von Software, indem wir dies tun und anderen dabei helfen."

Vermeiden Sie "Treffen Sie den neuen Boss, genau wie den alten Boss". Entwickeln Sie Agile so weit wie möglich aus dem Team heraus. Manchmal geschieht dies, indem eine Koalition von Personen ausgewählt wird, die bereit sind, mit Agile an einem Testprojekt teilzunehmen. Wenn Sie Ihr agiles Team aus Freiwilligen oder eingeladenen Mitgliedern bilden können, die eine Erfolgsbilanz für gute Teamarbeit vorweisen können, können sie dies herausfinden. Verwenden Sie ein kleines Team für ein kurzes Projekt, möglicherweise für einen internen oder leicht zugänglichen Kunden.

Umfassen Sie die Änderung. Vielleicht können Sie etwas trainieren, aber vielleicht ist Ihr Budget knapp und das Geld ist einfach nicht da. Andere Möglichkeiten können ebenfalls zu Verbesserungen führen. Lesen Sie etwas, lassen Sie die Mitglieder des Teams lernen, was sie über Agile können, und unterrichten Sie sich gegenseitig. Möglicherweise finden Sie neue oder vorhandene Mitarbeiter, die für die Modellierung und Führung der agilen Einführung qualifiziert sind.

2
DeveloperDon

Agile Teams sind wie Fußballteams, die auf ein allgemein bekanntes Ziel hinarbeiten. Ich bin seit einigen Jahren Teil eines agilen Teams und der Schlüssel ist eine effektive und effiziente Kommunikation zwischen allen Beteiligten. Manager/Scrum-Meister sind lediglich Vermittler des Teams, und traditionelles Management/Mikromanagement wird den Geist des Teams zerstören.

In den Teams, in denen ich gearbeitet habe, empfehlen wir, nach der Arbeitszeit Teamspiele zu spielen, um die Kameradschaft innerhalb der Mitglieder zu verbessern. Ich habe diese Gedanken gesammelt hier .

1
Vinod R

Um Ihre Frage zu beantworten: Nein. Agil ist keine Form des Mikromanagements. Aber wie bei jedem Tool können Benutzer es falsch verwenden. Agile ist wunderbar, wenn sie richtig implementiert wird und wenn die Leute damit übereinstimmen.

Meine Gedanken zum Thema "Entwickler sprechen nur mit dem Scrum Master":

Ich habe an einem Ort gearbeitet, an dem das vorher eine Regel war. Die Regel bezog sich jedoch mehr darauf, die Leute zu bitten, Aufgaben zu erledigen. Zum Beispiel kann ich nicht zufällig zu einem Entwicklertester gehen und ihn bitten, in den nächsten Stunden einige Tests für mich durchzuführen. Ich muss mit dem Scrum Master sprechen, damit sie mit ihrem Teammitglied besprechen können, wie diese Arbeit in den Sprint passt, wenn es sich um einen Notfall handelt (oder wenn sie für einen zukünftigen Sprint in den Rückstand verschoben werden muss).

In diesem Fall habe ich das Konzept von "Entwicklern, die nicht miteinander sprechen" verstanden, weil es sich wirklich in Trichteraufgaben über einen Kontrollpunkt niederschlug, damit ein bestimmter Entwickler nicht überarbeitet ist oder so beschäftigt ist, Notfallaufgaben zu erledigen, dass er seine Pläne nicht erfüllen kann Arbeit erledigt.

Andernfalls sollten Entwickler miteinander sprechen. Immer. Es hilft Ihnen, Probleme schneller zu lösen, als Team näher zu kommen und schneller zu liefern.

Nur um eine andere Perspektive zu bieten: Ich war auch in einer Umgebung, in der die Leute dachten, Entwickler hätten "zu viel geredet". Nach einem Hinsetzen stellten wir fest, dass die Übersetzung in "Entwickler sind nicht unabhängig genug, um ihre eigene Arbeit zu erledigen. Weil alles so fragmentiert ist, müssen Entwickler zu drei anderen Personen gehen, um kleine Aufgaben zu erledigen."

Als die Manager beschlossen, agil zu werden, erwarteten sie, dass dies dazu beitragen würde, Informationen an die richtigen Stellen zu bringen und einen Großteil der Fragmentierung innerhalb des Unternehmens zu stoppen. Einige Leute waren etwas enttäuscht darüber, dass die Entwickler nach der Implementierung von Agile immer noch hin und her rannten. Was sie jedoch nicht realisierten, war, dass dies immer weniger geschah. Es hat allerdings einige Zeit gedauert. Vielleicht ist es so, dass die Leute erwartet haben, dass Agilität die Dinge über Nacht repariert, wenn dies in Ihrem Unternehmen der Fall ist. So funktioniert das einfach nicht.

0
JustBlossom