Verbotene Frucht

Martin Lederer
Solutions Architect
Mehr erfahren

Agile Teams sind eine eingeschworene Gemeinschaft, deren Mitglieder alle an einem Strang ziehen? Mitnichten. Die Rahmenbedingungen machen es nicht leicht, Mitarbeiter mit einer eigenen Agenda zu identifizieren und wieder auf Spur zu bringen.

Egal, wie gewachst und poliert die Äpfel in der Obstschale ausliegen, wie frisch und knackig sie daherkommen: Man ist nie davor gefeit, beim beherzten Biss in den Braeburn oder den Boskoop einem verdorbenen Kerngehäuse auf den Leim zu gehen, dessen bitterer und hartnäckiger Nachgeschmack so gar nicht zur Erwartung passen will. Von diesem Vergleich aus könnte man in viele Bereiche der Software-Wirtschaft einstechen: Vertriebsversprechen und Lieferüberraschung, grüne Tests und Bugs im Live-System, Senior-Sätze und Junior-Performance.

verbotene-frucht

Egal wie poliert und gewachst die Äpfel ausliegen, man ist nie vor einem verdorbenen Kerngehäuse geschützt (Quelle: Adobe Stock / Wirestock Creators).

Agile Teams, agiles Miteinander

Zuwenden wollen wir uns allerdings dem bunten Fruchtkorb, der die Teamgestaltung und das Miteinander darstellt. Agilität bedeutet nicht zuletzt Konzentration auf das Wesentliche. Wie in vorhergehenden Beiträgen bereits herausgearbeitet, bedeutet dies auch, dass Menschen als „Teammitglied“ wahrgenommen und bestimmte Eigenschaften als gegeben angenommen werden. Dazu gehören im größeren Rahmen des rationalen Verhaltens beispielsweise:

  1. ein belastbares Interesse am Projekterfolg,
  2. die Motivation, unterwegs Probleme zu lösen, und
  3. die Bereitschaft, mit allen Projektteilnehmer*innen zielführend zu kommunizieren.

Eigentlich erscheinen diese Punkte in gewisser Weise selbstverständlich, und man möchte sie schon leichtfertig abhaken, bis man die eigenen Erfahrungen Revue passieren lässt. Leise, aber sicherlich nicht ohne Grund, ist „Respekt“ gegenüber den agilen Werten, den Values, nachträglich hinzugefügt worden… Der Rahmen aus Gesetzen, Gepflogenheiten und der Unternehmensorganisation selbst lässt zudem eine „natürliche“ Entstehung von Teams kaum zu. Das ist so weit kaum tragisch, man will ja selten mit den Kollegen den Urlaub verbringen, und der Minimalkonsens, auf den man sich intrinsisch und unausgesprochen einigt, legt eine professionelle – im besten Fall sogar wohlgesonnene und freundliche – Zusammenarbeit fest.

Der faule Apfel im agilen Korb

Was, aber wenn jemand nicht mitspielt? Wenn er oder sie vielleicht die eigene Arbeit nach Vorschrift erledigt, aber sich sonst als Bad Apple entpuppt?

Ein paar Beispiele :

  • Ein Softwareentwickler behauptet, man mache keine Code-Kommentare mehr, das sei nicht mehr Stand der Zeit. Nach einigem hin und her schreibt er Kommentare, aber sie sind bestenfalls unnütz.
  • Ein Entwickler als Reviewer schickt den zu prüfenden, neuen Code eines Tasks ein ums andere Mal zurück. Immer ist es irgendetwas anderes: Mal hat er keine Zeit, mal versteht er den Code nicht, warum etwas wie gemacht wurde, dann muss er weg. Aus Tasks werden Stories, die sich über mehrere Sprints anhäufen. Schließlich, nach etlichen Wochen, passe die ganze Story fachlich nicht und müsse völlig überarbeitet werden.Der „geprüfte“ Entwickler hat keine Handhabe dagegen – dem Betrachter erscheint sein „Prüfer“ bestenfalls als sorgfältig und engagiert.
  • Ein anderer gibt falsche Anweisungen und Anleitungen, was, wie und wo im Code zu tun sei. Bei der Abnahme des Tasks stellt sich der Fehler heraus, und er behauptet, dies nie gesagt zu haben; wieso sollte er etwas Verkehrtes, Sinnloses beauftragen? Was natürlich wiederum richtig ist.
  • Die Entwickler beschließen „öffentlich“, Anfang kommender Woche gemeinsam einen neuen Task zu beginnen, da es ja wohl schon einige Unstimmigkeiten gegeben habe. Am Montagmorgen im Daily Standup verkündet einer, er habe die Kernfunktionalität am Freitag und am Wochenende bereits abschließen können. Aber, er habe natürlich wie abgemacht, noch etwas für den Anderen übrig gelassen: Dieser könne die Tests schreiben. Der Code ist buggy, irreführend und so geschnitten, dass er kaum zu testen ist. Was soll der andere Entwickler nun tun? Das Team ist positiv überrascht, da der Task anscheinend schon erledigt ist.

Aber wie verschlimmert ein agiles Vorgehensmodell diese Sachverhalte? Nun, es gibt keine klare Hierarchie und keine harte Verantwortlichkeit im engeren Sinn. Die Vorgesetzten der „schlechten Äpfel“ sind weit weg, und sie würde das Fehlverhalten ihres Untergebenen nicht verstehen können. Ein gesundes Team könnte das leisten, aber mehr dazu gleich. Man kann das Problem auch gar nicht besprechen, weil der Rest des Teams ebenso wenig versteht, wo das Problem liegt!

Code-Erfahrung ist dünn gesät

Möglich ist dies, weil das handwerkliche Wissen um Softwareentwicklung – die tatsächliche Umsetzung von Anforderungen in Code – nur sehr dünn beziehungsweise punktuell in den Teams konzentriert ist. Von belastbarer Erfahrung in diesem Bereich gar nicht zu reden. Man verfügt über Entwickler für zwei Teams, bildet daraus vier und füllt die Lücken mit Business-Analysten und Produktmanagern auf, so dass die Entwickler mehr Zeit „fürs Tippen“ haben. Eine Spezialisierung dieser Art, der „alten Art“, war aber nie vorgesehen. Niemand hat noch Zeit, die Probleme aufzuklären; in der Regel sind die wenigen und daher wertvollen Entwickler eng getaktet – ein straffer Zeitplan, den es so in agilen Projekten auch nicht geben sollte.

Ein gesundes agiles Team

Wenn in einem gesunden, agilen Team tatsächlich fünf oder sechs Entwickler arbeiten würden (nicht zwingend als Entwickler), könnten sie die Probleme aufklären und eventuell einen schlechten Mitarbeiter sogar entfernen. Oder ihn zumindest so einbinden, dass er weniger Schaden anrichten kann. In einem Setup mit nur zwei Entwicklern ist das nicht möglich. Ein weiterer, eher weicher Faktor ist, dass Führungskräfte, so sie denn in Erscheinung treten, kaum noch Konflikte schlichten.

Überhaupt einen offenen, zutiefst menschlichen Konflikt auszutragen, kommt in der Welt der Sitzsäcke, Nerf Guns und bunten Zettelwände kaum vor. Und wenn sich der Konflikt nicht mit einem Mehr an Kommunikation vermeiden lässt, wie dann? Dem agilen Projektverfahren fehlt es hier an Methoden – und vor allem leider auch an Bewusstsein. Vielleicht sollte man die Instrumente aus der hierarchischen Organisation nicht rundherum ablehnen, sondern im unteren Fach des „agilen Werkzeugkastens“ für den selektiven Einsatz verwahren. Die Verantwortlichkeit einer disziplinarischen Führungskraft kann eventuell die internen Probleme schneller und vor allem nachhaltiger lösen als eine weitere Gesprächsrunde im Team.

Einen weiteren spannenden Beitrag zur Agilität im Bezug auf Projekten, finden Sie hier.

Erfahren Sie mehr über die metafinanz Leistung „Agile Enterprise“.

Quelle Titelbild: AdobeStock/ M.studio

Martin Lederer
Solutions Architect
Mehr erfahren

Weitere Beiträge

Risk & Security

Cybersecurity im Automobilbereich: die neue ISO 21434

Weiterlesen
Risk & Security

Messenger-Security-Check: Wie sicher sind die täglichen Begleiter?

Weiterlesen
Human & Relations

Vielfalt als Chance: Diversity macht stark

Weiterlesen