Agile ist ein beliebtes Schlagwort in der Softwareentwicklung. Manche Organisationen und Teams tarnen sich als „agil“, obwohl sie in Wirklichkeit etwas ganz anderes tun. Ich habe es in meiner Karriere als Agile Coach schon oft erlebt: Eine Führungskraft behauptet, agile Werte zu vertreten, managt aber die Entwicklungsteams im Detail und nutzt Agilität, um Entwickler zu Überstunden zu zwingen. Das Ergebnis? Einige Ingenieure in unserer Branche hasse agile Softwareentwicklung weil sie das Gefühl haben, dass es von Leuten außerhalb der Ingenieurswissenschaften vereinnahmt wurde, um sie zu manipulieren und die Softwareentwicklung zu gamifizieren.

In diesem Blogbeitrag beschreibe ich drei „Probleme“, die Ingenieure mit Agile und Scrum haben. Anschließend erkläre ich, warum es sich dabei gar nicht um Probleme handelt, wenn man den „Agile-Unsinn“ durchschaut, den schlechte Akteure und Missverständnisse verbreitet haben.

Bevor wir beginnen, definieren wir „agile BS“:

Agile BS: Verwendung des Begriffs „agil“ in Bezug auf ein Team, Projekt oder eine Organisation, die nicht den Prinzipien und Werten von Agilität entsprechen – z. B. Wasserfall, der sich als Agilität ausgibt oder das Wort „agil“ auf einen Prozess klatscht, der in Wirklichkeit dysfunktional ist.

Um diese Definition in Ihrem Gedächtnis zu verankern, finden Sie hier einige Beispiele für „agile BS“-Signale, die darauf hinweisen, dass ein Team oder eine Organisation nicht agil ist:

• Die Mitglieder des Entwicklungsteams sprechen nicht mit den Benutzern der Software und beobachten sie auch nicht.
• Es gibt kein kontinuierliches Feedback von Benutzern an das Entwicklungsteam
• Die Erfüllung aller Projektanforderungen hat eine höhere Priorität als die schnellstmögliche Auslieferung eines MVP, um frühzeitig Feedback zu erhalten

Weitere Informationen zu „agile BS“ finden Sie im Leitfaden des Verteidigungsministeriums zum Erkennen agiler BS . Es ist wichtig zu beachten, dass agile Prinzipien und Werte geschaffen wurden, um genau die Probleme zu lösen, die Menschen manchmal im Zusammenhang mit Agile äußern, insbesondere die in diesem Beitrag angesprochenen.

Problem 1: Agile bietet Managern zahlreiche Prozesse und Tools, die sie in böser Absicht nutzen können – und nur wenige, mit denen Ingenieure Einfluss auf die Hierarchie nehmen können.

Es stimmt, dass Manager Daily Standups nutzen können, um ihre Teammitglieder im Detail zu managen. Und sie verwechseln die Sprintverpflichtung eines Scrum-Teams oft mit „Garantie“ und drängen die Entwickler zu Überstunden, um ihr Sprintziel zu erreichen (siehe Problem 2). Doch das sind keine Probleme der agilen Softwareentwicklung, sondern Managementprobleme. Und schlechtes Management lässt sich nicht durch agile Softwareentwicklung überwinden. Das weckt falsche Erwartungen an die Ziele agiler Prinzipien und Werte.

Nehmen wir an, eine Organisation verfügt über das richtige Management. Wie kann sie Agilität fördern? Die Organisation muss Agile Prinzipien und Werte leben auf allen Ebenen. Dies erfordert ein Bekenntnis der Führung zur Agilität und kann durch agile Transformationsbemühungen (ggf. mit Unterstützung eines Agile Coaches) erreicht werden. Bei PagerDuty verfügen wir über ein engagiertes Agile Leadership Team, das Systeme, Prozesse und eine Kultur aufbaut und erweitert, die unsere organisatorische Effektivität kontinuierlich verbessert und das volle Potenzial unserer Teams freisetzt.

Eng mit diesem „Problem“ verbunden sind agile Werte Individuen und Interaktionen über Prozesse und Werkzeuge. Was bedeutet das eigentlich?

• Menschen über Prozesse. Die Softwareentwicklung wird von Menschen verwaltet, nicht von Prozessen und Tools.
• Ein Einheitsansatz für Prozesse und Tools funktioniert bei der Softwareentwicklung nicht gut
• Seien Sie vorsichtig bei Prozessen, die keine Abweichungen zulassen, und bei Tools, die Interaktionen behindern. Denken Sie an Anleitung statt Governance.

Wenn Sie über Prozesse und Tools nachdenken, sind hier „agile BS“-Signale, die darauf hinweisen, dass ein Team oder eine Organisation nicht agil ist:

• Prozessüberlegungen wie die Definition of Done werden für Entwicklungsteams von oben nach unten definiert
• Die Teams besitzen ihre Prozesslösungen nicht (z. B. die Auswahl Scrum vs. Kanban )
• Manager nutzen Daily Standups und Sprint Goals als Möglichkeit, ihre Ingenieure im Mikromanagement zu managen.

Problem 2: Agile vermischt absichtlich „Schätzungen“ mit „Verpflichtungen“ und manipuliert so Ingenieure, damit sie Überstunden machen.

Ich werde dieses Problem in zwei Teile aufteilen:

1. Agile vermischt absichtlich „Schätzungen“ mit „Verpflichtungen“

Die richtige Sprache ist besonders wichtig, wenn es um die Team-Engagement geht. Um das Scrum-Konzept des „Sprint Commitments“ zu erklären, hier ein Ratschlag von Mike Cohn , Mitbegründer der Scrum Alliance und der Agile Alliance:

Es ist wichtig, das Engagement des Teams nicht als Garantie zu betrachten. Das Team ist bestrebt, sein Bestes zu geben. Ich würde mir wünschen, dass sie ihr Engagement in 80 Prozent der Zeit einhalten. Sie sollten es ernst nehmen und die meiste Zeit einhalten. Nur so kann das Unternehmen Vertrauen in die Leistung des Teams gewinnen.

Wichtig ist hier, dass Das Engagement eines Teams wird nicht als Garantie angesehen Das Team gibt sein Bestes, reflektiert am Ende jeder Iteration, was es geliefert hat und vergleicht es mit seinem Ziel und passt seinen Prozess entsprechend an.

2. Ingenieure zu Überstunden manipulieren

Überstunden zu machen hat weniger mit Agilität zu tun, sondern eher mit der Unternehmenskultur. Ein Grundsatz des agilen Manifests lautet jedoch: Agile Prozesse fördern nachhaltige Entwicklung . Bedeutet dies, dass Ingenieure nie wieder lange arbeiten müssen? Natürlich nicht.

Für technische Leiter ist es wichtig, mit ihren Teams angemessene Erwartungen an die Arbeitszeiten zu vereinbaren. Ein technischer Leiter könnte seine Erwartungen beispielsweise wie folgt kommunizieren:

Ich erwarte von jedem, dass er 40 bis 50 Stunden pro Woche arbeitet. Das entspricht in der Regel einem 8-Stunden-Arbeitstag und einer Woche Rufbereitschaft pro Monat. Zweimal im Jahr kann ich das Team bitten, Überstunden zu machen. Dies kann ich nur tun, wenn es unbedingt notwendig ist.

Beachten Sie, dass der Manager das Team nicht dazu auffordert, regelmäßig Überstunden zu machen. Er weckt jedoch die Erwartung, dass dies mehrmals im Jahr passieren könnte.

Für die nachhaltige Entwicklung sind hier die „agile BS“-Signale zu finden, die darauf hinweisen, dass ein Team oder eine Organisation nicht agil ist:

• Wenn sich das Engineering-Team zu einem Sprint verpflichtet, ist dies gleichbedeutend mit einer Garantie
• Das Scrum-Team stets erfüllt seine Sprint-Verpflichtungen
• Das Engineering-Team macht regelmäßig Überstunden, um seine Sprint-Verpflichtung zu erfüllen

Problem 3: Das Scrum-Konzept einer „Verpflichtung“ bedeutet, alle zwei Wochen eine bestimmte Menge fertiger Arbeit abzuliefern, was für Ingenieure, die langfristige Entscheidungen über ihre Softwareentwicklung treffen möchten, zu feindselig ist.

Wenn ein Scrum-Team mit der Planung des nächsten Sprints beginnt, berücksichtigt es die Elemente, die für den Kunden die höchste Priorität haben. Langfristige Entscheidungen für ein Team werden im Voraus in der Produkt-Roadmap des Teams geplant. Produkt-Roadmaps sind jedoch keine Einbahnstraße: Ein Product Owner definiert das nächste wichtige Problem, das das Team lösen muss. Die Entwickler des Teams geben Feedback zur Roadmap und können Einspruch erheben, wenn sie der Meinung sind, dass es für das Team wichtigere Aufgaben gibt.

Warum sollten Ingenieure Feedback zu ihrer Produkt-Roadmap geben (oder sie zurückweisen) wollen?

• Für Teams mit Bereitschaftsdienst könnte die wertvollste Arbeit für den kommenden Sprint darin bestehen, Infrastrukturverbesserungen zu priorisieren, wenn der Bereitschaftsdienst in letzter Zeit besonders laut und mühsam war.
• Wenn das Team eine große Menge an technischen Schulden angehäuft hat, muss es möglicherweise seine Roadmap anpassen, um sich darauf zu konzentrieren, bevor es problematischer wird
• Wenn das Team Feedback von einem Benutzer oder Stakeholder erhält, das den Wert, den es liefert, verbessern würde, kann die Anpassung seiner Roadmap, um die Berücksichtigung dieses Feedbacks zu priorisieren, seine wertvollste Arbeit sein.

Wenn Sie über langfristige Entscheidungen nachdenken, sind hier „agile BS“-Signale, die darauf hinweisen, dass ein Team oder eine Organisation nicht agil ist:

• Das Entwicklungsteam erhält vom Product Owner eine Lösung, statt eines zu lösenden Problems.
• Das Entwicklungsteam verfügt nicht über einen Mechanismus, um Feedback zur Produkt-Roadmap zu geben

So sieht Erfolg aus

Eine erfolgreiche agile Softwareentwicklung erfordert die Zustimmung der Organisation auf allen Ebenen, das Engagement der Techniker, die Konzentration auf den Kunden und gegebenenfalls die Einbindung engagierter Agile Coaches.

Sobald eine Organisation echte Agilität angenommen hat:

• Ingenieure können und sollten mithilfe von Mechanismen wie Kennzahlen (z. B. Produktengagement, Auswirkungen auf den Umsatz, Vorhersagbarkeit) Einfluss auf die Organisation ausüben. Team-Gesundheitschecks , Und Team-Retrospektiven
• Gut aufgestellte Scrum- und Kanban-Teams wird darauf vertraut, dass sie ihren Kunden einen vorhersehbaren Mehrwert bieten und gleichzeitig in einem nachhaltigen Tempo arbeiten
• Ingenieure werden ermächtigt Feedback zu geben und ihre Produkt-Roadmap anzupassen, sodass sie immer an den wertvollsten Dingen arbeiten. Um dies weiter voranzutreiben, planen Sie regelmäßig einen HackWeek gibt Ingenieuren die volle Autonomie, an dem zu arbeiten, was ihrer Meinung nach für die Organisation am wichtigsten ist.

Teilen Sie Ihre Erkenntnisse

Haben Sie andere Möglichkeiten bemerkt, wie Organisationen und Teams sich als „agil“ ausgeben, obwohl sie in Wirklichkeit etwas ganz anderes tun? Wir würden uns freuen, von Ihnen zu hören in der PagerDuty -Community .