Agile ist ein beliebtes Schlagwort in der Softwareentwicklung. Manche Organisationen und Teams geben sich als „agil“ aus, obwohl sie in Wirklichkeit etwas ganz anderes tun. Ich habe das in meiner Karriere als Agile Coach schon oft erlebt: Ein Leiter behauptet, agile Werte zu vertreten, verwaltet aber die Entwicklungsteams im Detail und nutzt Agilität als Mittel, um die Entwickler zu Überstunden zu manipulieren. Das Ergebnis? Einige Ingenieure in unserer Branche hasse agile Softwareentwicklung weil sie das Gefühl haben, dass die Software von Personen außerhalb der Ingenieursbranche missbraucht wird, um sie zu manipulieren und die Softwareentwicklung zu spielerisch zu gestalten.

In diesem Blogbeitrag werde ich drei „Probleme“ beschreiben, die Ingenieure mit Agile und Scrum haben. Anschließend werde ich erklären, warum das überhaupt keine Probleme sind, wenn man den „Agile-Blödsinn“ 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 der agilen Vorgehensweise entsprechen – z. B. Wasserfallmodelle, die sich als agil ausgeben oder das Wort „agil“ auf einen Prozess kleben, der in Wirklichkeit nicht funktioniert.

Um diese Definition in Ihrem Gedächtnis zu verankern, sind 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 diese auch nicht.
• Es gibt kein kontinuierliches Feedback von Benutzern an das Entwicklungsteam
• Die Erfüllung sämtlicher 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 jene, die in diesem Beitrag angesprochen werden.

Problem 1: Agile bietet Managern zahlreiche Prozesse und Tools, die sie in böser Absicht verwenden können – und nur wenige, mit denen Ingenieure Einfluss auf andere ausüben können.

Es stimmt, dass Manager Daily Standups dazu nutzen können, ihre Teammitglieder im Detail zu managen. Und Manager können die Sprintverpflichtung eines Scrum-Teams mit „Garantie“ verwechseln und Ingenieure dazu drängen, lange zu arbeiten, um ihr Sprintziel zu erreichen (siehe Problem 2). Aber das sind keine Probleme der agilen Softwareentwicklung, sondern Managementprobleme. Und schlechtes Management kann man nicht mit agiler Softwareentwicklung überwinden. Das weckt die falschen Erwartungen an das, was agile Prinzipien und Werte erreichen sollen.

Nehmen wir also an, eine Organisation verfügt über das richtige Management. Wie kann sie Agilität umsetzen? 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. Im Fall von 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 verbunden mit diesem „Problem“ sind agile Werte Individuen und Interaktionen über Prozesse und Werkzeuge. Was bedeutet das eigentlich?

• Menschen sind wichtiger als Prozesse. Die Softwareentwicklung wird von Menschen gesteuert, nicht von Prozessen und Tools.
• Ein Einheitsansatz für Prozesse und Tools ist für die Softwareentwicklung nicht geeignet.
• Seien Sie vorsichtig bei Prozessen, die keine Varianz zulassen, und bei Tools, die Interaktionen behindern. Denken Sie an Anleitung statt Governance.

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

• Prozessüberlegungen wie die Definition von „Erledigt“ 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 zur Mikroverwaltung ihrer Ingenieure

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

Ich werde dieses Problem in zwei Teile aufteilen:

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

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

„Es ist wichtig, dass das Engagement des Teams nicht als Garantie betrachtet wird. Das Engagement des Teams besteht darin, sein Bestes zu geben. Ich möchte, dass sie ihr Engagement vielleicht 80 Prozent der Zeit einhalten. Es sollte etwas sein, das sie ernst nehmen und die meiste Zeit einhalten sollten. Das ist notwendig, damit das Unternehmen Vertrauen in das gewinnen kann, was ein Team verspricht.“

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. Manipulation von Ingenieuren, damit diese Überstunden machen

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

Es ist wichtig, dass technische Leiter mit ihren Teams angemessene Erwartungen an die Arbeitszeiten festlegen. Ein technischer Leiter könnte seine Erwartungen beispielsweise folgendermaßen kommunizieren:

Ich erwarte von jedem, dass er 40 bis 50 Stunden pro Woche arbeitet. Das bedeutet im Allgemeinen einen 8-Stunden-Arbeitstag und eine Woche Bereitschaft im Monat. Zweimal im Jahr kann ich das Team bitten, Überstunden zu machen. Ich kann das nur tun, wenn es unbedingt nötig 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.

Im Hinblick auf eine nachhaltige Entwicklung sind die folgenden „agile BS“-Zeichen dafür relevant, 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 Sprintverpflichtungen
• Das Engineering-Team leistet regelmäßig Überstunden, um seine Sprintverpflichtungen zu erfüllen.

Problem 3: Das Scrum-Konzept einer „Verpflichtung“ bedeutet, alle zwei Wochen eine bestimmte Menge fertiger Arbeit abzuliefern, was Ingenieuren, die langfristige Entscheidungen über ihre Softwareentwicklung treffen möchten, gegenüber übermäßig feindselig ist.

Wenn ein Scrum-Team mit der Planung seines nächsten Sprints beginnt, zieht es die Elemente heran, 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. Es liegt an den Ingenieuren des Teams, Feedback zur Roadmap zu geben und Einwände zu erheben, wenn sie der Meinung sind, dass es für das Team etwas Wertvolleres gibt, an dem gearbeitet werden sollte.

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

• Wenn die Bereitschaftsarbeit von Teams in letzter Zeit besonders laut und mühsam war, könnte die wertvollste Arbeit für den nächsten Sprint darin bestehen, Infrastrukturverbesserungen zu priorisieren.
• 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 von ihm gelieferten Wert verbessern würde, kann die Anpassung seiner Roadmap zur Priorisierung der Bearbeitung dieses Feedbacks seine wertvollste Arbeit sein.

Wenn Sie über langfristige Entscheidungen nachdenken, sind die folgenden „agile BS“-Zeichen dafür, 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

Für eine erfolgreiche agile Softwareentwicklung sind die Zustimmung aller Ebenen der Organisation, das Engagement der Entwicklungsabteilung, Kundenorientierung und möglicherweise die Einbindung engagierter Agile Coaches erforderlich.

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) einen positiven 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 befähigt Feedback zu geben und ihre Produkt-Roadmap anzupassen, damit sie immer an den wertvollsten Dingen arbeiten. Um dies weiter zu treiben, planen Sie regelmäßig einen HackWeek gibt Ingenieuren die volle Autonomie, an den Dingen zu arbeiten, die ihrer Ansicht nach für die Organisation am wichtigsten sind.

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 PagerDuty Gemeinschaft .