Wenn Agile schief geht [geschlossen]

Ich schreibe einen Agile-Kurs für einige der neuen Leute, die wir kürzlich an Bord haben, und ich möchte eine warnende Geschichte hinzufügen, damit sie verstehen, dass Agile nicht für alle Projekte gedacht ist.

Mein Problem ist, dass ich aufgrund der Art der Projekte, an denen ich mit Agile arbeite, bisher nicht ehrlich sagen kann, was schief gehen kann und warum, wenn Sie es in einem falschen Projekt verwenden.

Worauf sollten Sie achten, wenn ein Agile-Projekt schief geht?

Der größte Misserfolg bei "Agile" -Teams resultiert aus dem sogenannten Cargo Culting . Im Wesentlichen möchten Teams die Auswirkungen erfolgreicher agiler Teams nachahmen, damit sie die sichtbaren Aktionen nachahmen

• Tägliche Stand-ups (die ungefähr eine Stunde dauern)
• Arbeit in Sprints aufteilen
• User Stories (das sind normalerweise wenig mehr als ein Satz, aber eine Schätzung wird erwartet)

Das sind die drei, die Sie in diesen Umgebungen durchweg als "angewendet" sehen werden, aber nur sehr wenig Engagement, um tatsächlich agil zu sein. Tatsächlich werden Sie vom Management hören, dass wir "agil handeln". (Lauf weg bei diesen beiden Worten, es ist ein schlechtes Zeichen.)

Sie werden auch viel über technische Schulden hören, aber ihre Definition für technische Schulden lautet "Mach es schnell und schmutzig und vielleicht werden wir es später besser machen." (Übersetzung: Wir werden den Eindruck erwecken, dass wir uns um die Wartbarkeit kümmern, aber in Wirklichkeit werden wir die gleiche Mentalität wie im Heizraum beibehalten, da dies in der Vergangenheit für uns funktioniert hat.)

Andere Schlüsselausdrücke: "Ich weiß, dass diese Geschichten nicht vollständig definiert sind, aber wir sind agil, damit wir sie im Laufe der Zeit korrigieren können."

"Wir machen eine agile Entwicklung, damit Sie in der Lage sein sollten, das, was ich brauche, im Sprint unterzubringen, wenn ich es identifiziere."

"Wir sind nicht in der Lage, unsere engagierten Geschichten zu Beginn des Sprints festzuhalten, da sich die Bedürfnisse während des Sprints ständig ändern."

Der Schlüsselindikator für den Erfolg eines agilen Projekts ist, ob der Projektleiter (Scrum Master oder welche Rolle auch immer) Erfahrung oder eine formelle Schulung für die Leitung eines agilen Projekts hatte. Zu oft habe ich gesehen, wie Leute in einem Buch über Agile gelesen haben oder an einem zweitägigen Kurs über Scrum-Master teilgenommen haben und dachten, sie hätten das Zeug dazu, ihn erfolgreich umzusetzen. Tut mir leid, dass es nicht passiert, Captain.

Leute, die nicht verstanden haben, worum es bei Agilität geht (geht?) Und wenden es an auf:

• Kunden, die bis zum Stichtag nicht für Kommentare zur Verfügung stehen
  ... und danach rechtliche Schritte drohen;

• Manager, die Entwickler vom Kunden fernhalten (wahrscheinlich, weil sie leicht unterbezahlt sind und Schiffe überspringen könnten, um für den Kunden zu arbeiten) und in einem verzweifelten (aber oft erfolgreichen) Versuch ein Spiel mit dem " kaputten Telefon " spielen bei der Suche beschäftigt und nützlich,

  Siehe auch: Pilzmanagement , auch bekannt als "obskur gehalten, Gülle gefüttert" und spitze Chefs . :)

• Teams, die zu groß sind , um irgendwohin zu gelangen;

• Unternehmen, die ihre Gehaltsliste der einstmals bekannten Systemarchitektur-Designer behalten, die ihre Aufmerksamkeit verzweifelt von der Tatsache ablenken, dass sie das eigentliche Programmierhandwerk völlig aus den Augen verloren haben, indem sie großartige, unpraktische, schwer zu realisierende UML- Sagrada- Familien überarbeitet haben .

Agile eignet sich nicht für befristete oder Festpreisverträge. Sobald Sie sich für ein solches Tier angemeldet haben, müssen Sie liefern. Agile ist sehr gut darin, sich für immer weiterzuentwickeln, da Kunden ihre Meinung ändern und ihre Anforderungen „klären“. Das hilft dir nicht an dem Tag, an dem das Geld ausgeht, sondern muss die Arbeit noch beenden.

Agile eignet sich jedoch sehr gut für die Phase nach dem Projekt, wenn Sie inkrementelle Updates und Fehlerkorrekturen durchführen.

Der andere Aspekt, bei dem Agile versagt, ist nicht ein Fehler von Agile, sondern ein Fehler von Menschen, die auf all den alten Dingen bestehen, wie umfassender Projektdokumentation, vorab erstellten Entwürfen und schlechten Kommunikationswegen. (Das halbherzige agile Manifest ).

Hier sind ein paar Fragen, die hilfreich sein können, um nach einer Antwort zu suchen, um ein Beispiel zu finden, bei dem ein Versuch, Agil zu werden, schlecht verlaufen kann:

• Ist Agile das neue Mikromanagement?
• Der Agile Prozess: Wie und was soll dokumentiert werden?
• Richtige Mischung aus Planung und Programmierung für ein neues Projekt

Hast du jemals von "Pseudo Agile" gehört? Hier sind ein paar Blog-Einträge dazu:

• Vom Pseudo-Agilen zum Wasserfall - Der Weg eines kleinen und neuen Softwareunternehmens
• Pseudo Agile!

Es gibt etwas zu sagen für Unternehmen, die ihre eigene Meinung zu Agile vertreten und es in etwas anderes zerlegen.

Ich habe in einem äußerst erfolgreichen Agile-Team gearbeitet sowie in einigen, die es mit Agile versucht haben, es aber nicht zum Laufen gebracht haben.

Der erfolgreiche hatte die folgenden Elemente:

• Wirklich "Agile" Anforderungen. Es gab User Stories, und wir haben sie verschlüsselt.
• Verfügbarer Product Owner. Wenn eine User Story, aus der ich programmiert habe, unvollständig ist, kann ich leicht zum Product Owner gehen, ihn fragen, was dort sein soll, es hinzufügen und den Code vervollständigen.
• Engagement für den Prozess und die Erkenntnis, dass es sich um eine Lernkurve handelt.
• Konzentriertes Team.
• Manager, die die agile Art und Weise kannten und verstanden, Dinge zu tun, die sich dafür einsetzen, dass sie funktionieren.

Das erfolgreiche Team hat Agile gemacht und es wirklich gut gemacht. Ich würde denken, dass Sie ziemlich leicht scheitern könnten, wenn Sie keinen der obigen Punkte haben. Das erste und das zweite gehen Hand in Hand, und wenn Sie das nicht haben, wird Agile nicht funktionieren.

Das Team, in dem ich war, das Agile nicht gut machte, hatte auch ein paar Elemente:

• Mangelndes Engagement des Managements. Das Management glaubte nicht an die Philosophie und zögerte deshalb, sich zu engagieren.
• Anforderungen an anderen Orten als User Stories dokumentiert. Siehe oben zum Engagement des Managements. Außerdem hatten wir hochbezahlte Anforderungsanalysten und große teure Anforderungswerkzeuge, die jemand brauchte, um den Einsatz zu rechtfertigen.

Ich werde zu den bereits geposteten großartigen Antworten hinzufügen, dass nach meiner Erfahrung agiles und spezielles Scrum nur funktionieren wird, wenn Management UND Team gewillt sind, viel Transparenz darüber zu schaffen, was vor sich geht.

Dies bedeutet, dass es in öffentlichen Unternehmen (z. B. Regierungen) sehr schwierig sein wird, die ordnungsgemäße Funktion zu gewährleisten.

Meiner Meinung nach dreht sich bei Agile alles um die Kultur des Teams, das trainiert. Wenn die Kultur schlecht ist, die Teammitglieder nicht miteinander auskommen und die Leute nicht zusammenarbeiten, um die Sprint-Verpflichtungen zu erfüllen, ist die Kultur oder das Team mangelhaft.

Ich würde jedoch nicht unbedingt sagen, dass Waterfall in einer solchen Umgebung unbedingt funktionieren wird, es ist keine Schwarz-Weiß-Situation, sehr wenig ist wirklich Schwarz-Weiß.

Ein gutes agiles Team ist gemeinschaftlich. Sie haben einen Stammesgeist der Gemeinschaft, in dem alle Mitglieder auf die gleichen Ziele hinarbeiten. Das Team gelingt oder scheitert zusammen. Sie arbeiten gemeinsam an der Lösung von Problemen. Ein Teammitglied wird aufhören, was er mit seinen Aufgaben tut, um einem kämpfenden Teammitglied zu helfen. Alles ist sinken oder schwimmen.

Wenn dies nicht der Fall ist, wird schnell klar, was nicht stimmt. Wenn sich die Teammitglieder hinsetzen, auf ihren Laptops tippen oder SMS schreiben oder sich während des täglichen Stand-ups in Zonen aufteilen, haben Sie kein gutes agiles Team. Wenn Ihre Projektmanager alle Scrum-Prozeduren, -Definitionen und -Terminologien durchsetzen, aber jeder nur die Trittfrequenz einhält und Lippenbekenntnisse abgibt, dann ist dies nur eine offensichtliche Farce dessen, was Agile wirklich ist, und dies führt in vielerlei Hinsicht zu Funktionsstörungen und Ineffizienz des Teams , versäumte Termine und gescheiterte Projekte.

Failing Agile ist in vielerlei Hinsicht schlechter dran als ein mäßig erfolgreiches Waterfall-Team und weist wahrscheinlich niedrigere Projekterfolgsraten auf.

Ich weiß das nicht aus persönlicher Erfahrung, aber hypothetisch gibt es viele Umstände, in denen Agilität nicht die beste Option ist.

• Projekte, deren Produkt lebens- oder eigenschaftskritisch ist - Sie möchten zum Beispiel nicht agil arbeiten, um die Software zu entwickeln, die Ihren Schrittmacher ausführt. Warum? Weil Sie eine Fehlertoleranz nahe Null haben. Betrachten Sie ein klassisches Beispiel für einen Programmierfehler in der Medizin in Bezug auf den Therac 25 . Zugegeben, es wurde nicht mit Agilität gebaut, aber der springende Punkt ist: Die Entwicklung eines lebens- oder eigentumskritischen Bereichs ist kein Ort, an dem man sagen kann: "Wir werden das beim nächsten Sprint bereinigen" oder "Wir brauchen keine großen, nur guten genug."

• Projekte mit zu vielen Nachwuchsentwicklern - Agile erwartet ein gewisses Maß an Autonomie innerhalb der teilnehmenden Gruppe. Wenn im Team nicht genügend Erfahrung vorhanden ist, kann diese Autonomie gegen Sie wirken.

• Projekte, die ein höheres Maß an Kontrolle oder Planung erfordern als das, was traditionell mit Agile angeboten wird.

Ich gehe davon aus, dass entweder jemand anderes einspringt und mit besseren Beispielen hilft oder dieses bisschen Kacke, das ich geschrieben habe, ablehnt ;-).

Denken Sie daran, dass jedes Problem wie ein Nagel aussieht, wenn das einzige Werkzeug, das Sie haben, ein Hammer ist. Nicht alle Projekte sind Nägel.