"Agile ist tot." Die Leute sagen das die ganze Zeit. Aber sie fügen unbedingt hinzu: "Wir scherzen nur." Sie bedeuteten, dass
Sie so falsche und dumme Praktiken hatten, dass Agile für
Sie tot
ist . Aber der "echte" Agile ist nicht tot. Es ist nur so, dass jeder es falsch macht. Also wurde mir klar: Das wahre Agile ist
theoretisch Agile. Sogar ich habe es implementiert. Und weißt du was? Ich habe es satt.
Kürzlich habe ich in meinen Artikeln dieselbe alte Verteidigung gesehen: "Aber-aber-aber, das Problem ist der Wasserfall, das Gedränge und die falsche Umsetzung von Agile, die Nichtbeachtung des Manifests ... bla bla bla." Dann sagte mir Bob Marshall die Wahrheit. Er sagte: „Halt die Klappe, Charles. Das Agile Manifest ist der Krug, den wir füllen. “ Er machte einige Kommentare, denen ich zustimmen musste. Ich habe darüber nachgedacht. Das Ergebnis war dieser Artikel.
Hier ist ein Test für Sie. Wie beginnt die erste Zeile eines agilen Manifests? Nicht gucken. Weiß nicht Alles ist in Ordnung. Es spielt keine Rolle. Es heißt: "Wir entdecken fortschrittlichere Softwareentwicklungsmethoden ..." Stop. Beachten Sie, es heißt: "Software-Entwicklung." Es heißt nicht: "Ihre Organisation ziehen", "Schulden für die Transformation abbezahlen", "sie mit diesem Befehls- und Kontrollscheiß ausschneiden", "sich auf Ergebnisse konzentrieren und die Eröffnungsarbeit verbessern", "Ihr mittelalterliches Budgetierungssystem reparieren" oder was auch immer Fortgeschrittener Mehrwert, den die Leute zu investieren versuchten. Tatsache ist jedoch, dass wenn Leute sagen, dass Agile sich auf die gesamte Organisation bezieht, es Revisionismus ist. Das ist nicht Fair.
Beachten Sie auch, dass es beginnt "Wir
entdecken ..." Er sagt nicht: "Wir haben von oben erhalten ..." Glauben Sie nicht, dass wir etwas von 2001 gelernt haben? Ich meine, ja, die meisten großen Organisationen stecken 1987 noch fest, aber okay, Sie. Entgegen der landläufigen Meinung stammt das Foto unten nicht wirklich aus der Unterzeichnung des Manifests. Können wir endlich aufhören, so zu tun?
Das Manifest diente einem bestimmten Zweck, führt Sie jedoch nicht dorthin, wo Sie es benötigen. Beginnen Sie also Ihr Studium. Unser Wissen hat ein Ablaufdatum und nicht so lange wir denken. Jeder hat Kollegen (normalerweise Chefs), die behaupten, dass sie "keine Zeit zum Lernen haben". Sie selbst wissen, dass sie in ihrem Wissen zu selbstbewusst sind. Finden Sie also eine gute Liste von Büchern. Bleiben Sie mit guten Blogs auf dem Laufenden. Hier ist ein Anfang: Wenn Sie
Sense & Respond ,
Lean Enterprise ,
Ein Platz am Tisch und
Jeder ist ein Change Agent nicht gelesen haben, sollten Sie dies sofort tun. Und an deine Vorgesetzten.
Lesen Sie Beiträge von John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica Hall, Neil Killick und denen, auf die sie sich beziehen. Stimmen alle miteinander (oder mit mir) überein? Nein, aber sie sind schlau und machen dich auch schlauer. Fangen Sie an zu lesen und ermutigen Sie andere. Laut Fast Company liest der durchschnittliche CEO 60 Bücher pro Jahr. Wie viele Bücher lesen Ihre Führer? Und was lesen sie? (HBR-Artikel, Gartner-Berichte und Romane von Maeve Binchi zählen nicht). Denn seien wir ehrlich: Wenn Ihre Führungskräfte Scrum-Meister sind, dann stecken Sie fest in den 80ern und 90ern fest.
Fahren wir mit kontinuierlichem Lernen fort und hören auf, so zu tun, als sei Agile eine Art Heilmittel. Dies muss gesagt werden:
Agile ist und war immer eine lokale Optimierung für eine leichte Steigerung der Systemeffizienz . Nur Agile hat ein Team von Softwareentwicklern zu Unrecht unter die Lupe genommen. Dies erhöht nicht die organisatorische Flexibilität. NEIN. Interessanterweise war Agile laut Ken Schwaber (siehe „Unsicher bei jeder Geschwindigkeit“) ein Versuch, „den durch den Wasserfall verursachten Schaden zu kompensieren“, gab Organisationen jedoch nie eine ganzheitliche, tragfähige Alternative zum Wasserfall. Weil es einen Unterschied zwischen Theorie und Praxis gibt. Die Arbeit an einem Produkt ist eher eine Praxis. Wenn wir uns über AINO (Agile In Name Only) beschweren, sind wir uns selbst gegenüber nicht ehrlich.
Theorie versus Praxis, erinnerst du dich? Wir müssen pragmatisch sein. Agil in der Praxis ist fast immer AINO. Es scheint ein Problem mit der Bewegung selbst zu sein, oder? In jedem Fall gibt es wichtigere Dinge zu lernen, einschließlich (aber nicht beschränkt auf) Lean UX, Lean Enterprise, Jenseits des Budgets, Theorie der Einschränkungen, Durchsatzrechnung, Design Thinking, DevOps, Marshall-Organisationstherapie usw.
Sie fragen sich vielleicht, warum Lean UX ganz oben auf der Liste steht? Aufgrund der Tatsache, dass Lean UX das Konzept der Ergebnisorientierung
im Wesentlichen populär macht. Denken Sie: Wenn Sie nicht wissen, welche Art von Verhaltensänderung Sie erstellen möchten, werden Sie Ihre Handlungen nicht verstehen. Wenn Sie kein klares Schwenksignal haben, können Sie nicht mehr flexibel sein. Das ist es, was Agile schließlich dreht. Einige mögen Einwände erheben: "Nein-nein-nein, prüfen und anpassen!" Natürlich. Theorie versus Praxis, erinnerst du dich? Ich sehe keine flexiblen Teams, die testen und sich anpassen. Ich sehe agile Teams, die versuchen aufzuholen, mit Jira und Rally herumspielen und so arbeiten, als würden sie auf Befehl eine Mauer bauen.
Agile tendiert tatsächlich dazu, das Hauptproblem zu maskieren - dies ist ein systemischer, bidirektionaler Mangel an vertikalem Vertrauen. Die Agile Coachis gehen und verschlechtern die Situation: Sie hinterlassen schweinesprechende Manager und ein Entwicklungsteam, das zu Esperanto gewechselt ist. Die Teams sind der Ansicht, dass das Management kaputt ist, und das Management ist der Ansicht, dass das Hauptaugenmerk weiterhin auf Volumen, Zeitplan und Effizienz liegen sollte, wobei ignoriert wird, dass Zeitpläne willkürlich sind und Zeitschätzungen eine
Form der Verschwendung darstellen . (Wissen Sie, welche Story Points tatsächlich erfunden wurden,
um die Zeit zu
verbergen und das Problem selbst zu lösen? Auch hier gab es unangenehme Konsequenzen, richtig? Theorie und Praxis).
Ratet mal, wer gewinnt? Zwei Lager mit zwei radikal unterschiedlichen Perspektiven. Wo bekommt ein Lager Bewertungen vom anderen? Wenn Teams wie blinde Menschen sind, die einen Elefanten fühlen und mit dem, was er ist, nicht einverstanden sind, dann ist Führung wie blinde Elefanten, die Menschen angreifen und zustimmen, dass sie alle flach sind. Die Lösung besteht darin, zu erkennen, dass das System
ein Team ist. Beenden Sie bereits mit lokalen Optimierungen und stellen Sie fest, dass Vertrauen das Hauptproblem ist. Hören Sie auf, Entwickler unfair unter die Lupe zu nehmen, damit andere sich in einer Blackbox verstecken können. (Warum interessiert uns nicht, wie strategische Entwicklungsteams arbeiten? Oder wie sind die Systembeschränkungen älterer Architekten?)
Und während wir dies tun, sollten wir aufhören, die Entwicklungsteams so zu behandeln, als würden sie in einer Fabrik arbeiten. Wir stempeln keine Plastikschalen. Wir erstellen Software. Sie müssen aufhören, sich so zu verhalten, als würden wir
eine Pizzeria servieren . Hier sind die anderen Regeln. Wir verwenden nicht das gleiche bewährte Rezept. Wir
entwickeln Rezepte . Wenn Sie es noch nicht verstanden haben, ist dies eine Eröffnungsarbeit, nicht nur eine Lieferung. Die Vernachlässigung der Entdeckung führt zu massiven Verlusten: ungenutzte Funktionen und andere Arbeiten, die keine Ergebnisse erzielen. Dies zeigt einen weiteren tiefen Fehler von Agile. Er schlägt vor, dass Benutzer als Meerschweinchen betrachtet werden können: „Hey, benutze einfach dieses beschissene Produkt, dann werden wir es verbessern.“ Nur dass das beschissene Produkt normalerweise so bleibt, nicht wahr? Zukünftige Verbesserungen werden zu unnötigen „Kosten“.
Aber-aber-aber, Agile konzentriert sich wirklich auf Forschung! Richtig? Wir werden ehrlich sein. Theorie versus Praxis, erinnerst du dich? Wenn Sie Ihren Lebensunterhalt mit Entwerfen oder Forschen verdienen, beantworten Sie diese Frage. Wie denkst du normalerweise über die Arbeit mit flexiblen Teams? Werden Sie zunächst als Wert angesehen und gebeten, beim „Testen und Anpassen“ zu helfen? Oder werden Sie gebeten, "Ihren Wert zu beweisen"? Wie Alan Cooper sagte, wird Ihnen klargestellt, dass Sie sich in einem System befinden, das Sie nicht wertschätzt, wenn Sie aufgefordert werden, "Ihren Wert zu beweisen". Bitte beachten Sie, dass sie einen einzelnen Teilnehmer bitten, seinen Wert zu beweisen - sie fragen nicht, wie sehr ihr Code die Indikatoren tatsächlich in die richtige Richtung lenkt. Mit anderen Worten, sie konzentrieren sich immer noch auf Menschen,
nicht auf die Arbeit selbst . Sie konzentrieren sich wahrscheinlich immer noch auf Knochen, nicht auf Werte, und ignorieren Bereiche, in denen ein erheblicher Teil des Werts tatsächlich wegfließt.
Wenn Sie mit flexiblen Teams arbeiten, versuchen Sie dies, wenn Sie das nächste Mal aufgefordert werden, „Ihren Wert zu zeigen“. Stellen Sie
ihnen zunächst Fragen. Wissen sie, was der Preis für Verspätung ist? Mit welchen Übungen bewerten sie diesen Parameter? Welche konkreten Ergebnisse versuchen sie zu erzielen? Welcher Anteil ihres Produkts erreicht tatsächlich seine Leistung? Wissen sie es nicht? Wenn es schnellere und billigere Möglichkeiten gibt, herauszufinden, was zu entwickeln ist, als nur den Code freizugeben, sind sie dann am Lernen interessiert? Was ist ihre Flusseffizienz? Wie schlimm ist es Wie viel Zeit verbringen sie in Besprechungen? Wenn es Designer-Spiele und vereinfachte Aktionen gibt, die in viel kürzerer Zeit zu besseren Lösungen führen, sind sie dann am Lernen interessiert? Weil ich Ihnen nicht nur meinen Wert zeigen werde - ich werde Sie lehren,
bei allem, was Sie tun , mehr Wert zu schaffen.
Dies ist eine andere Denkweise. Das ist Meta. Das ist strategisch. Wie Austin Gowella bemerkt, konzentrieren sich sowohl Agile als auch der Wasserfall auf die
Entwicklung . Design ist ein
Test . Wenn sie nicht interessiert sind, können Sie gehen. Wenn sie einfach den Kopf senken, um ein Produkt herauszubringen, das sich auf die Kosten konzentriert, werden sie nie genug wissen, um zu verstehen, dass Sie normalerweise mehr bekommen, als Sie sich konzentrieren (ähm, Knochen). Dies ist eine Feature-Factory. Gegenseitige Verantwortung. Sie geben vor, Plastikgeschirr herzustellen. Sie haben wichtigere Dinge zu tun. Weil realer Wert durch Optionen bereitgestellt wird, die durch
Forschung generiert werden. Je mehr Optionen Sie erstellen und je flexibler Ihr Ansatz ist, desto mehr mögliche Pfade und bessere Ergebnisse. Was versuchen sie zu erreichen? Haben sie drei bis fünf Wege erkundet, um dies zu erreichen? Dies wird zu einer besseren Entscheidungsfindung für die Zukunft führen. Eine Option ist keine Wahl. Zwei ist ein Dilemma. Drei - jetzt haben Sie etwas erreicht.
Schon mal was von dem notwendigen Gesetz der Vielfalt gehört? Die Komponente mit den meisten Optionen
steuert das System . Wende es auf den dummen Machtkampf von Agile vs. Waterfall an. Sie hatten Führungskräfte, die versuchten, die Kontrolle über das System von oben zu behalten, und flexible Teams, die versuchten, den Wert näher an die Quelle zu bringen (echte Benutzer und Kunden). Der Weg aus einem bedeutungslosen Bürgerkrieg besteht darin, den Menschen beizubringen, wie sie Optionen
auf allen Ebenen generieren können. Der Weg nach vorne ist nicht agil gegen einen Wasserfall. Dies ist eine intelligente strategische Top-Down-Arbeit (Wasserfall) mit empirisch orientierten Bottom-Up-Taktiken. Design und Discovery helfen in beiden Fällen.
Also ... was ist die Lösung? Dies ist ein vernünftiger Fokus auf klare Ergebnisse, nicht auf die Lieferung, mit geplanten Ergebnissen anstelle von geplanten Noten, nicht mit dem Projekt, sondern mit zuverlässigen Produktteams, die befugt sind, Annahmen zu überprüfen und den kürzesten Weg zum Wert zu finden.
Jetzt zum Training (angepasst basierend auf John Cutler Diagramm).
Also ... bedeutet das, dass Agile geht? Natürlich nicht. Dies ist nur ein dummer Blog-Beitrag. Ich habe keine Macht. Und selbst wenn es so wäre, würde Agile immer noch nicht verschwinden.
Die Agile Bewegung hat viele dieser Konzepte ermöglicht . Darüber hinaus wurden agile Praktiken entgegen der landläufigen Meinung von der agilen Bewegung nicht erfunden. Sie erschienen Jahrzehnte zuvor.
Also nein, ich möchte nicht, dass Agile geht.
Ich möchte nur, dass wir ehrlicher sind.