Ist Agile das neue Mikromanagement?

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

Mein Unternehmen hat es endlich gewagt, agile Praktiken zu integrieren, und hat mit einem Team von 4 Entwicklern in einer agilen Gruppe probeweise angefangen. Es hat 4 Monate mit 3 Iterationen gedauert und sie machen es weiter, ohne für den Rest von uns völlig agil zu werden. Dies liegt an der Tatsache, 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 keine Anrufe im Arbeitsbereich entgegennehmen (was in gewissem Umfang in Ordnung sein kann). Wenn ich zum Beispiel mit meinem Freund über Kicks im agilen Team sprechen möchte, 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 für Unterbrechungen zu bieten und sie in über 6 produktive Stunden zu versetzen. Nun, Leute, ich bin kein agiler Guru, aber was ich für andere Organisationen gelesen habe, gibt mir das Gefühl, dass agil nicht billig ist. Es sind Ressourcen und Budget erforderlich, um die Teams agil zu machen und Probleme bei ihrem Eintreffen zu beheben, um sie wieder auf Kurs zu bringen.

Für den Anfang ist eine Schulung für Entwickler und ein Coaching für Manager usw. erforderlich. Der derzeitige Scrum-Master war ein Manager, der ein paar Tage im agilen Schulungskurs verbracht hat, den das Management bezahlt hat. Er leitet nun dieses agile Team. Ich habe auch in der Besprechung gehört, dass agiles Manifest nicht vorschreibt, dass agiles nicht in Steinen liegt und für jedes Unternehmen unterschiedlich angepasst wird. Nun, das klingt alles gut und vernünftig.

Abschließend dachte ich immer, dass die Agilität Harmonie in den Entwicklungsteams 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 nichts anderes als arbeiten können, den ganzen Tag still sitzen und nur arbeiten, und sie sind der Meinung, dass es nur eine andere Möglichkeit für das Management ist, sie zu mehr Arbeit zu bewegen.

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 es nicht mögen, in einer Umgebung zu arbeiten, in der sie nur arbeiten, weil sie bei der Arbeit sind.

Es ist ein Unternehmen im Gesundheitswesen mit Niederlassungen in den USA. Es fühlt sich definitiv wie ein Cowboy-Stil an, der mich wirklich dazu bringt, überhaupt nicht agil sein zu wollen, vor allem nicht in meiner jetzigen Firma.

Alles hat damit zu tun, dass das Management völlig billig ist. Verzichten Sie auf teuren Kaffee für eine günstigere Version, achten Sie auf Einsparungen und Produktivität, 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 Chefs zeigen können, dass wir mehr mit der gleichen Mitarbeiterzahl produzieren. Oder vielleicht können wir damit den Personalbestand reduzieren, wenn dies der Fall ist.

Sie haben ihre 5-minütige tägliche Besprechung. Es ist jedoch nicht gestattet, mit jemandem außerhalb des Teams zu chatten oder zu sprechen. Der Schwerpunkt liegt auf der Arbeit.

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

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

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

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

Das klingt nach einer ziemlich perversen Implementierung von Agile. Wenn überhaupt, sollte Agilität das Mikromanagement reduzieren und nicht steigern. Das Team geht eine Verpflichtung ein und es ist Teil des Prozesses, dass das Management darauf vertraut, dass das Team dies erreicht. Das tägliche Gedränge 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). Selbst der Schätzungsprozess sollte explizite Zeitverzögerungen 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.

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

Ich habe mich mit Agile beschäftigt, bevor es Agile war. Um das Jahr 2000 habe ich mich mit dem Programmieren beschäftigt, von Extreme Programming gehört, es ausprobiert und es gemocht. Es gab mir als Entwickler einen Kontext, in dem das Produzieren von solider Software das Wichtigste war, und es gab mir Werkzeuge, um einen Großteil des Mistes, der mich verrückt machte, zu minimieren. Ich liebte es.

Das heutige Problem, das ich an anderer Stelle im Detail erläutere , ist, dass die meisten Leute, die heutzutage "Agile" einführen, nicht daran interessiert sind, etwas zu verbessern, wenn es sie unangenehm macht. Für sie ist "Agile" also nur ein neuer Schläger, 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 bremst.

Jetzt sofort. Ich gründe eine Firma und verwende eine Menge XP sowie eine Reihe anderer Tricks, die ich in der agilen Welt gelernt habe. Aber gerade wegen Geschichten wie deiner zucke ich zusammen, wenn ich heutzutage von einer agilen Adoption erfuhr.

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

Das ist nicht wendig.

Erstens ist Scrum nicht agil . Scrum ist, ehrlich gesagt, Schwachsinn. Ich bin in einem Extreme Programming-Haus 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. Über die Entwicklung selbst und über die Anforderungen, die Planung und die Beziehung zum Kunden hat es jedoch nichts zu sagen. XP hat darüber viel zu sagen; Jede andere Methode, die sich als agil bezeichnen will, muss etwas zum Gespräch beitragen. Scrum-Befürworter haben es nicht als Prozess beschrieben, sondern als Wrapper für einen Prozess. Ein weiser Mann wies einmal darauf hin, dass Sie eine Hülle entfernen und wegwerfen müssen, um zu den guten Sachen zu gelangen.

Okay, scrum rant vorbei!

Zweitens ist ein Grundprinzip von XP, das meiner Meinung nach für jeden agilen Prozess von grundlegender Bedeutung ist, dass es auf den Entwickler ausgerichtet ist . Auf diese Weise erhalten Entwickler die Möglichkeit, die Arbeit zu erledigen, von der sie wissen, dass sie sie erledigen müssen, und werden so häufig daran gehindert. Ein agiles Team kann als Demokratie oder als 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. Es ist ein sicheres Zeichen dafür, dass das Team nicht agil ist, wenn ein Manager - Entschuldigung, "Scrum Master" - da sitzt und die Leute herumkommandiert.

Ich denke, es sollte einen dritten geben. Gibt es nicht

Scrum ist das Bastardkind von Agile. Es ist die wasserfallartigste aller agilen Methoden und deshalb die beliebteste unter Managern.

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

Alles, was diesem Ziel im Weg steht, ungeachtet der "agilen Regeln", ist schlecht. Wenn die Regeln stören, ändere die f * * Regeln! Das ist der agile Weg, das macht es relevant und effektiv.

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

„Platzieren Sie 4-6 Personen in einem Raum mit Workstations 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, die Sie haben, funktioniert, dann ist das alles, was Sie brauchen. Sie benötigen keinen Scrum Master oder eine "agile" Methodik. Wenn sitzt für Sie arbeitet in einem täglichen Gedränge nach unten, dann f * * * es tun. Sie aufstehen zu lassen, ist nur eine erbärmliche Aufhebung Ihrer Fähigkeit, für sich selbst zu denken.

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

Der derzeitige Scrum-Meister war ein Manager, der ein paar Tage an einem vom Management bezahlten agilen Schulungskurs 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 lassen Sie sich zumindest von ihnen prüfen und genehmigen, wenn es sich um eine Managementidee handelt.

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

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

"Wir sind agil" ist die häufigste Ausrede, 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 natürlich auch die am häufigsten benutzte Ausrede, die ich von mittleren Managern, Architekten, Verkäufern usw. für Mikromanagement höre, die immer neue Fristen und Featurelisten einführt und die den Leuten massiv Überstunden aufzwingt (die immer neuen Fristen und Featurelisten sorgen natürlich dafür) usw. usw .

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

Um Ihre ursprüngliche Frage zu beantworten, ist Agile das neue Mikromanagement, ich würde nein sagen.

Lesen Sie zuerst dieses (Agile-Manifest), und Sie werden feststellen, dass es nicht aufgeführt ist, wenn Sie nicht mit Ihren Mitentwicklern sprechen.

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

Agil sollte das neue Selbstmanagement sein. Wenn Agilität richtig geübt wird, werden viele der Entscheidungen von einem Kunden und einem Entwickler getroffen, die an einer User Story mit angemessenem Umfang arbeiten, die dem Backlog hinzugefügt wird, wenn Aufgaben identifiziert werden.

Das tägliche Gedränge dreht sich um Kommunikation, nicht um Management. Es wird einige Diskussionen über Priorität und Lastenausgleich geben, aber die Person, die am Scrum verwaltet wird, ist hoffentlich der Scrum-Master. Als Entwickler sage ich, was ich getan habe, was ich tun werde und welche Hilfe ich brauche. Dann sollte der Scrum Master in Aktion treten 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 weit her von jemandem an der Spitze einer hierarchischen Organisation getroffen werden, ist es Zeit für die Dezentralisierung der Entscheidungsfindung! Für manche Menschen und Organisationen ist dies möglicherweise eine Brücke zu weit. Wenn Folgendes für Ihre Organisation nicht zutrifft:

Lebe das Agile Manifest

"Wir entdecken bessere Wege, um Software zu entwickeln, indem wir dies tun und anderen dabei helfen."

Vermeiden Sie "Treffen Sie den neuen Chef, das gleiche wie der alte Chef." Entwickle Agile so weit wie möglich aus dem Team. Manchmal geschieht dies, indem eine Koalition derjenigen ausgewählt wird, die bereit sind, mit Agile an einem Testprojekt teilzunehmen. Wenn Sie Ihr Agile-Team aus Freiwilligen oder eingeladenen Mitgliedern zusammenstellen können, die eine Erfolgsgeschichte für gute Teamarbeit vorweisen können, können sie es erarbeiten. Setzen Sie ein kleines Team für ein kurzes Projekt ein, vielleicht für einen internen oder leicht zugänglichen Kunden.

Umfassen Sie die Änderung. Vielleicht kannst du etwas trainieren, aber vielleicht ist dein Budget knapp und das Geld ist einfach nicht da. Andere Möglichkeiten können ebenfalls Verbesserungen bringen. 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 Einführung von Agile qualifiziert sind.

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 Teamgeist zerstören.

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

Um Ihre Frage zu beantworten: Nein. Agilität ist keine Form von Mikromanagement. Aber wie jedes Werkzeug können die Leute es falsch benutzen. Agile ist wunderbar, wenn es richtig implementiert wird und wenn die Leute damit übereinstimmen.

Meine Gedanken zum Thema "Devs sprechen mit niemandem außer dem Scrum Master":

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

In diesem Fall verstand ich das Konzept "Entwickler sprechen nicht miteinander", weil es sich wirklich auf das Trennen von Aufgaben über einen Checkpoint auswirkte, sodass ein bestimmter Entwickler nicht überlastet oder so beschäftigt ist, dass er seine geplanten Aufgaben nicht ausführen kann Arbeit erledigt.

Ansonsten sollten Entwickler miteinander reden. Immer. Es hilft Ihnen, Probleme schneller zu lösen, sich als Team zu nähern und schneller zu liefern.

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

Als sich die Manager für einen Umstieg auf Agile entschieden, 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 irgendwie enttäuscht, dass die Entwickler nach der Implementierung von Agile immer noch hin und her liefen. Was sie jedoch nicht realisierten, war, dass es immer weniger passierte. Es dauerte jedoch einige Zeit. Wenn dies in Ihrem Unternehmen der Fall ist, kann es sein, dass von den Mitarbeitern erwartet wird, dass sie über Nacht mit Agilität Abhilfe schaffen. So funktioniert das einfach nicht.

Der ursprüngliche Autor Smith Janes hat möglicherweise Erfahrungen gemacht. Aber das sind die typischen Probleme, die ich im Agile-Projekt gefunden habe.

1. Die meisten Organisationen, Entwickler, sollen in mehreren Projekten arbeiten, in Agile / Scrum. Sprints werden niemals als solche betrachtet. Ihr Scrum-Meister geht davon aus, dass Sie am Ende des Sprints mit Ihren Geschichten fertig sein sollten. Ihr Scrum-Meister widmet sich möglicherweise nur einem Projekt, nicht jedoch den Entwicklern oder einen Anruf zulassen.
2. Ich habe Agile-Projekte gesehen, in denen Sprint geplant ist, Stories in Sprint eingeschlossen, ohne zusammengedrängt zu werden. Auf halbem Weg oder mitten in den Sprints. Entwickler, die Abhängigkeiten nicht gelöst, Anforderungen oder Story nicht abgeschlossen finden, werden erzählt ist einer der Missbräuche in den meisten agilen Projekten.
3. Testen: TTD .. ja, es ist sehr gut .. aber ich habe gesehen, dass sich die meisten Agile-Projekte vollständig auf TTD verlassen ... kein Umfang und keine Zeit für funktionale oder menschliche Tests. Ein weiterer Missbrauch ... Viele Scrum-Meister auch Ich kenne oder verstehe die Bedeutung von Funktionstests nicht. Ihr Code funktioniert möglicherweise einwandfrei, wenn er nicht den geschäftlichen Anforderungen entspricht. Er ist nutzlos. Dies geschieht, wenn Unternehmen nicht weit im Voraus teilnehmen oder wenn die Teilnahme vorhanden ist, aber die geschäftlichen Entscheidungen nicht widerspiegeln Am Ende werden die Entwickler beschuldigt, dass Sie die Funktionalität nicht geliefert haben. Andernfalls kommt es zu Änderungen in letzter Minute. Überlange Stunden, weil Ihr Scrum-Meister nicht die Schuld für eine nicht abgeschlossene Story übernehmen möchte.

Missbrauch hier ... entweder geringe Geschäftsbeteiligung oder Teilnehmer, der nicht über ausreichende Kenntnisse verfügt, oder Geschäftsmann, der mitten im Sprint ausfällt.

1. Nicht alle Projekte sind für Agile geeignet. Die meisten Manager oder Scrum-Master wissen das nicht. Wartungsprojekte. Ein Defekt, von dem zunächst ausgegangen werden kann, kann in 8 Stunden erledigt und im Sprint akzeptiert werden. Nach 4 Stunden stellte ich fest, dass es sich um Java / ein anderes Produkt handelt ... (ich hatte kürzlich einen mit Quartz Scheduler in Zusammenhang stehenden Handelsdefekt innerhalb unseres Projekts). Finanzierung, neue Version oder Upgrade sollten von Internal Engineering usw. genehmigt werden. 5. Rückblick: Nur eine Handvoll von Agile-Projekten erledigt diesen Schritt. Wenn überhaupt erledigt. Management, hat Scrum Master niemals die Verantwortung für die fehlgeschlagenen Storys übernommen.
2. Pairing .. Viele Entwickler betrachten Pairing als einen Ort, an dem sie Mitarbeiter missbrauchen. Sie kritisieren andere Design- und Codierungspraktiken. Sie behandeln sie als Teamarbeit. Sie lernen voneinander. Ein anderer Weg, Agile / Scrum zu missbrauchen.

Agile ist definitiv eine gute Methode. Es sei denn, Ihre Organisation folgt nicht vollständig oder nicht geschult. Es wird missbraucht. Nebenwirkungen 60+ Arbeitsstunden / Woche, Schuldzuweisungen, niedrige Moral.

Agile ist Mikromanagement in Verkleidung. In Agile gibt es keinen Platz für Initiative oder Kreativität. Es hat den Spaß am Programmieren verringert, damit inkompetente Manager die Kontrolle behalten können, auch ohne eine Ahnung vom technischen Standpunkt zu haben.