Ist Agile das neue Mikromanagement?


80

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.


71
Ich habe mehr Missbräuche im Namen von agile gesehen, als ich kommentieren möchte. Viele Male bedeutet "wir machen agil" "wir werfen jeden Anschein von Prozess weg und tun, was wir wollen, Yeehaw!" (für die offensichtliche Cowboyreferenz). Eine ruhige Umgebung hilft auf jeden Fall, aber Sie müssen den Entwicklern erlauben, miteinander zu reden und Dinge herauszuholen - ohne die Zustimmung des Scrum- Diktators .
Berin Loritsch

28
Du machst nicht Agile ...
CaffGeek

13
Das ist wirklich eine Rede. Keine Frage.
JohnFx

8
2 Tage im zertifizierten Scrum-Master-Kurs machen Manager nicht zum Scrum-Master, genau wie 24 Stunden, in denen Sie sich C ++ in 24 Stunden beibringen, macht Sie nicht zum fähigen C ++ - Programmierer. Sie machen es einfach falsch.
Matt

9
Erforderliche Lektüre: Half-Arsed Agile Manifesto "Wir haben von neuen Möglichkeiten der Softwareentwicklung erfahren, indem wir Berater bezahlt und Gartner-Berichte gelesen haben ..."
Mittwoch,

Antworten:


89

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.


7
Das einzige, was ich in der Nähe finden konnte, war ein "Joel on Software" -Post über die zwölf wichtigsten Dinge, die jedes Unternehmen für seine Programmierer bereitstellen sollte. Einer der 12 war ein ruhiger Arbeitsplatz. Ich bezweifle jedoch, dass Joel Spolsky das so gemeint hat.
Berin Loritsch

5
Ein ruhiger Arbeitsplatz ist ein ruhiger Arbeitsplatz, an dem Sie sich unterhalten können, ohne andere zu stören. Das bedeutet, dass es nicht üblich ist, Personen über die Gegensprechanlage anzurufen und Generatoren für weißes Rauschen oder andere Methoden zur Minimierung des Geräuschpegels in Bereichen einzusetzen, in denen viele Menschen arbeiten. Eine No-Talking-Regel schafft keinen ruhigen Arbeitsplatz.
Kevin Cathcart

5
@ Kevin Cathcart, wir sind uns in diesem Punkt sehr einig. Jetzt war ich in einer Firma, in der das Gegenteil der Fall war. Wir hatten ~ 40 Leute in einem Bullpen mit offenen Tischen und keinen Würfeln. Das einzige Team, das etwas erreichen konnte, war das, das den größten Teil des Lärms machte. Vor dieser Art von Umgebung möchten Sie sich schützen.
Berin Loritsch

8
@ Kevin - Meine Entwicklungsabteilung ist eine Farm mit offenen Feldern, direkt neben einer Reihe von drei Glocken mit den Bezeichnungen "Sale", "Big Sale" und "Huge Sale". Einige Male am Tag rufen Verkäufer diese an und rufen "wooooo!". : - \
Dan Ray

2
@Dan Ich hatte vor ein paar Jahren eine Reihe von Interviews, in denen mir drei Startups sagten, sie müssten die Verkäufer von den Entwicklern entfernen, weil sie zu laut waren! @ # $ Ing loud.
Erik Reppen

46

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).


29
Es ist absolut gegen das allererste Prinzip des Agilen Manifests: "Individuen und Interaktionen über Prozesse und Werkzeuge". Weitere Informationen finden Sie unter agilemanifesto.org .
Berin Loritsch

"Es ist absolut gegen das allererste Prinzip des <XXX> Manifests"; Ersetzen Sie alles für XXX, und Sie haben Ihre Wahl Kult. ;-) Im Ernst, wundert dich das nicht?
CesarGon

5
@CesarGon, in diesem Fall geht es um die Prinzipien, die agiles Arbeiten ausmachen. Wenn Sie die Grundprinzipien von Agile nicht beschreiben können, möchten Sie vielleicht kein Agile. Ziemlich einfach. Ich sage nicht "konvertiere zum Glauben", ich sage "mach was du sagst, dass du glaubst". Im Ernst, nicht , dass ich fragen Sie machen?
Berin Loritsch

1
@CesarGon, in dem beschriebenen OP geht es um das genaue Gegenteil der Absicht dieser Richtlinie. Wann halten Sie Ihren Mittelton für nah genug? Die Art und Weise, wie Sie sprechen, klingt wie ein 95% iger Unterschied zwischen den Tönen ist nah genug. Komm schon. Und gib mir etwas Anerkennung. Ich arbeite seit langer Zeit in der realen Welt und definiere Prozesse in Unternehmen. Ich verstehe ziemlich gut, was nah genug ist - und was das OP beschreibt, ist es nicht.
Berin Loritsch

2
@Berin Loritsch: Ich gebe dir Anerkennung; es war nicht meine Absicht, anders zu erscheinen. Meine anfängliche Bemerkung über Kulte versuchte tatsächlich, teilweise einen Scherz zu machen. Der Punkt, den ich anstrebe, ist, dass wir nicht ein paar Zeilen in einem Manifest brauchen, um etwas zu verteidigen, das offensichtlich gegen den gesunden Menschenverstand verstößt. Das OP beschreibt eine Situation, in der alle Alarme klingeln. Ich hoffe du nimmst es schön; Entschuldigung, wenn ich zu hart war. :-)
CesarGon

31

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.


24

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.


4
+1. Agile / scrum / xp oder was auch immer sind nur "mumbo jumbo" -Begriffe für IT-Shops, die keine echten Software-Unternehmen sind. Wie Sie sagten, niemand, der radikale Veränderungen vornimmt, während er seinen Kopf mit diesen Praktiken in den Sand steckt. Alles, was man lesen muss, ist diese großartige Lean-Softwareentwicklung: Ein agiles Toolkit, das alle BS hinter sich lässt. Diese Praktiken gelten nicht für IT-Shops, ist mein Fazit.
Smith James

23

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


-1, ich stimme nicht zu. Agile Entwicklung bedeutet auch, dass Sie Prozesse bereinigen und vereinfachen sowie sich an Änderungen anpassen können. Und genau darum geht es bei Scrum. Bei Scrum geht es auch um Anforderungen und Planung, nur anders.
Falcon

6
Eh, komm schon, das ist 2012. Zitiere Kent Becks öffentliches Schreiben oder lass es. Es ist egal, ob er auf deiner Couch liegt.
nes1983

6
@ nes1983: Das habe ich 2011 geschrieben. Damals war es anders.
Tom Anderson

3
Ich habe den Begriff "technische Schulden" nie gehört, bis Scrum auf meinem Radar aufgetaucht ist. Ich war beim Training. Leicht zu verkaufendes Schlangenöl sollte das Management auf Kosten langfristiger Überlegungen zur Produktqualität ansprechen. 100% Bullshit. Obwohl ich es total schlucken würde, wenn Scrum Masters ein Schwert im Conan-Stil tragen müsste, um Leute zu verprügeln, mit denen die Integrität des Prozesses bedroht ist.
Erik Reppen

2
+1 für das Scrum-Rant. Ich betrachte Scrum als die "agile" Methode für Leute, die Wasserfälle so sehr mögen, dass sie es alle zwei Wochen machen möchten.
Kyralessa

16

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.


Bitten Sie sie, alle 2/3 Wochen laufende, getestete Software an die Benutzer zu liefern?
user272671

2
@ user272671 NO. Lassen Sie sie regelmäßig laufende, getestete Software an den Benutzer liefern. Nicht nach einem dumm willkürlichen Zeitplan wie 2 oder 3 Wochen. Wenn der Benutzer oder die Software so komplex ist, dass ein 6-wöchiger Zyklus funktioniert, dann machen Sie 6 Wochen. Wenn es auf einem "wenn abgeschlossen" getan werden kann, dann tun Sie das. Behemmen Sie sich nicht mit künstlichen Einschränkungen. Solcher ist nicht beweglich.
gbjbaanb

11

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.


9

"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.


Meiner Erfahrung nach habe ich nur agiles (immer scrum) eingeführt, um Mikromanagement zu erklären. Ich werde nicht leugnen, es ist eine andere und einzigartige Art des Mikromanagements. Ich habe noch nie von einem Entwickler gehört, dass er agil ist und ein kurzes Kommen erklärt. Welche Art von Management-Gedränge haben Sie erlebt?
JM Becker

1
Wann immer ich auf Scrum gestoßen bin, wurde es eingeführt, weil ein Manager (normalerweise höher als der Projektmanager) davon gehört hatte, dass es "das Ding" ist.
16.

7

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.


Nun, "Individuen und Interaktionen" sind das, was sie gerade in ihrem Team tun. Wie steht es mit dem agilen Manifest, wenn Sie den Scrum-Master-Standpunkt betrachten? Das Problem im Moment ist, dass sie keine Interaktion mit anderen Teams haben sollen, um ihre Produktivität aufrechtzuerhalten, was die Ursache für Beschwerden der agilen Gruppe ist.
Smith James

Sie interagieren nicht. Das ist das Problem. Sicher, ein Entwickler kann Privilegien missbrauchen und stundenlang über bedeutungslose Dinge sprechen. Die meisten guten Entwickler möchten jedoch ein qualitativ hochwertiges Projekt liefern. Es ist eine Ehrensache. Alles, was der Scrum Master tut, untergräbt das und macht es stattdessen zu einer Sache der Verdrängung. Darum geht es bei Agile nicht. Ein Scrum Master sollte es dem Team ermöglichen, produktiv zu sein, keine Peitsche zu knacken, und ihm sagen, dass es produktiv sein soll. Sie wollen bereits produktiv sein.
Berin Loritsch

2

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.


1

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 .


1
Entwickeln Sie Arbeitsbeziehungen nach der Arbeit. Wir sollten unsere oft vernachlässigten Beziehungen zu Freunden und Familie nach der Arbeit entwickeln. In Anbetracht dessen, dass Mitarbeiter selten Freunde sind und die meisten Gelegenheiten nutzen, um sich auf Kosten anderer selbst zu helfen. Die Firma yes-men, cronies und tools merkt es einfach nicht, weil die Möglichkeiten selten sind. XP könnte einen gewissen Wert haben, ich habe keine Erfahrung, um etwas anderes zu sagen. Scrum ist zu einer anderen Version des Mikromanagements geworden, zumindest bei den drei Unternehmen, die ich kenne. Ich hasse Corporate America viel zu sehr, um überhaupt ein wenig objektiv zu sein.
JM Becker

0

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.


-1

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.


siehe diesen link .. warum agile projekte scheitern .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Ich stimme auch den Informationen in diesem Artikel zu. Ich verstehe, dass es Leute gibt, die Agile für unfehlbar halten, aber die Realität ist, dass Agile wenig oder keinen Raum für die Einführung neuer und effektiverer Ideen lässt. is..brighthubpm.com / agile / 55778-warum-do-agile-projekte-scheitern
user272671

-3

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.


2
Du könntest nicht falscher sein. In agilen Umgebungen sollten Teams ein hohes Maß an kreativer Kontrolle haben. Agile erfordert extrem viel Eigeninitiative, da das Team entscheidet, wie jede Story umgesetzt wird. Das Management hat tatsächlich sehr wenig Kontrolle über den agilen Prozess. Die drei verschiedenen agilen Teams, in denen ich mitgewirkt habe, haben sehr viel Spaß gemacht. Es hört sich so an, als ob Sie eine schwere Inkompetenz erlebt haben, die sich selbst als agil identifiziert hat, ohne dass sie sich der Agilität annähert.
Bryan Oakley

fügen Sie einige Argumentation Ihre Behauptung zu unterstützen (was mir sicher Sinn macht , aber das spielt keine Rolle), und ich werde den downvote entfernen
gnat

1
Ich bin mit @Geo einverstanden. Bisher habe ich diesen Eindruck von "Agile" in der realen Welt. Wenn Sie eine solche Einstellung in der Fabrik haben, ist dies einfach eine Form des Mikromanagements. Jetzt versucht uns das Manifest zu sagen, dass es nicht so ist. Aber Projekt für Projekt muss ich noch mehr glauben, dass es einfach ein anderer Name für "Mikromanagement" ist. Und es tötet die Kreativität.
user272671
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.