Agilität - Die häufigsten Missverständnisse, Teil 4

Richtig: Die Anforderungen an Entwickler sind in agilen Projekten höher

Niklas Schlimm

Im Kontext der Serie „Agilität – Die häufigsten Missverständnisse“ muss man diese Aussage wohl erstmal so stehen lassen. Die Skill-Anforderungen an Mitglieder agiler Projekte sind aus meiner Sicht tatsächlich höher.

Ich beziehe mich hier auf die im zweiten Teil bereits angesprochene X-Y-Theorie. Dort werden folgende Bilder von Mitarbeitern skizziert:

Theorie X – „Der Mensch ist unwillig“

Folgende Attribute prägen dieses Bild: Der Mitarbeiter hegt eine Abneigung gegen Arbeit, deshalb muss er meistens gelenkt und geführt werden. Er muss sprichwörtlich „an die Hand genommen“ werden. Im Normalfall zieht der Mitarbeiter Routineaufgaben vor, strebt nach Sicherheit, scheut sich vor Verantwortung. Der Manager muss jeden Handlungsschritt detailliert vorgeben, energisch anleiten, führen und streng kontrollieren.

Theorie Y – „Der Mensch ist engagiert“

Folgende Attribute prägen dieses Bild: Arbeit hat einen hohen Stellenwert und ist wichtige Quelle der Zufriedenheit. Der Mitarbeiter ist von Natur aus leistungsbereit und motiviert. Er strebt nach Selbstverwirklichung, mehr Selbstbestimmung, größeren Verantwortungsbereichen, flexiblere Organisationsstrukturen, Gruppen- und Projektarbeit etc. Er identifiziert sich mit den Zielen der Organisation. Externe Kontrollen sind deshalb nicht notwendig, denn er wird Verantwortung übernehmen und Eigeninitiative entwickeln.

Theorie Z – „Der Mensch ist je nachdem“

Es wird angenommen, dass eine starke Mitarbeiterbeteiligung zu Engagement und höherer Produktivität führt. Hier spielen folgende Mechanismen eine Rolle: lebenslange Beschäftigung, Beteiligung an Entscheidungsfindung, individuelle Verantwortungsübernahme der Mitarbeiter, Leistungsbeurteilung, Beförderung in langen Zyklen, keine formalisierten Verhaltensregeln, hoher Stellenwert interpersonaler Beziehungen.

In Bezug auf Agilität möchte ich hier die folgende Aussage stark machen:

Agile Vorgehensweisen erfordern engagierte Mitarbeiter oder zumindest solche, die sich „mitnehmen lassen“ und sich dann konstruktiv einbringen.

In agilen Projekten können wir also möglicherweise nur mit Typ Y und Z arbeiten. Warum? Werfen wir einmal einen Blick auf ein paar Eigenschaften von Mitarbeiter Typ X und bewerten diese in Bezug auf das Anforderungsprofil in agilen Projektteams.

  • Zur Erinnerung: Der im ersten Teil der Serie eingeführte Regelkreis verdeutlicht, dass sich das agile Team selbst steuert und organisiert. Der Mitarbeiter vom Typ X hat aber eher eine Abneigung gegen Arbeit. Daher muss er gelenkt und geführt werden. Überträgt man die Führungsverantwortung (für sich) auf ihn selbst (Selbstregulation), muss damit gerechnet werden, dass nichts oder nur wenig passiert.
  • Außerdem zieht Typ X Routineaufgaben vor. Die Idee agiler Projektteams liegt aber gerade darin, der Komplexität des Projektes durch ebenso hohe Komplexität (Varietät) im Problemlösungsverhalten zu begegnen. In einem solchen Umfeld ist Routine nicht der Alltag, sondern Veränderung und Dazulernen.
  • Typ X meidet Verantwortung. Selbstorganisation und Selbstregulation bedeutet dagegen hohe Verantwortung, weil das Entwicklungsvorgehen ja gerade nicht mehr von außen detailliert vorgegeben wird. Der Entwickler muss viel selbst entscheiden, während in konservativen Führungsmodellen durch die Führungskraft entschieden werden sollte.

Ich denke, das reicht aus, um darzustellen, dass die „Mentalität“ von Typ X nicht gerade gut in ein agiles Projekt passt.

Bisher haben wir nur über die Anforderungen an die Grundmotivation der Mitarbeiter gesprochen. Darüber hinaus besteht aber auch eine hohe Anforderung an das „Skill-Niveau“. Wer in Extreme Programming einsteigen will, kann auf Ron Jeffries Seite einiges lernen. Oder man wirft einen Blick in das Inhaltsverzeichnis das Extreme Programming Buch von Kent Beck. Eine gute Referenz ist auch Agile Developer Skills. Und wem das noch nicht reicht, der kann sich noch mit anderen Ideen rund um Agile beschäftigen, zum Beispiel mit Alistair Cockburn oder Jeff De Luca. Eine gute Übersicht über die agilen Muster und Methoden (die allen agilen Vorgehensweisen gemein sind) gibt dieses Buch. Alles zusammen veranlasst mich zu folgender Aussage:

Agile Entwicklung setzt ein hohes Maß an erforderlichen technischen und methodischen Fähigkeiten der Team-Mitglieder voraus. Ohne diese Fähigkeiten wären agile Teams ebenso risikoreich unterwegs wie andere Teams.

Ich nenne nur einige Beispiele der Techniken, die man unbedingt beherrschen sollte:

  • Testgetriebene Entwicklung (insbesondere Unit Tests)
  • Objekt-orientiertes Design und Programmierung inklusive Analyse- und Design-Muster
  • Gemeinsames Planen: User Stories, Release-Planung, Iterationen
  • Versionskontrolle, z.B. mit CVS oder Subversion
  • Detaillierte Kenntnisse der eigenen Entwicklungsumgebung, z.B. Eclipse
  • Continuous Integration
  • Pair Programming

Wer also denkt, agile Softwareentwicklung wäre keine systematische Vorgehensweise, der irrt. Der Unterschied zu anderen „Schwergewichten“ liegt eher in der beschriebenen Betonung der Selbstregulation und -organisation und hier insbesondere bei der Auswahl der agilen Techniken, die zur konkreten Problemlösung eingesetzt werden sollen.

Das funktionsübergreifende Entwicklungsteam darf das tun, was nötig ist, um das Ziel zu erreichen, und es entscheidet selbst, was „das Nötige“ ist.

Noch ein letztes Wort zu Skills: Zu den ganzen harten, erlernbaren Fähigkeiten kommt das erhöhte Maß an erforderlichen „Soft-Skills“ hinzu. Die Fähigkeit und der Wille zur konstruktiven Kommunikation ist wohl das wichtigste Mittel bei der Problemlösung in komplexen dynamischen Projekten. Interaktion zwischen den Menschen hat daher einen sehr hohen Stellenwert. Wir befinden uns nämlich in einem Umfeld, in dem häufig Ad-Hoc-Absprachen stattfinden, um sich z.B. auf geänderte Rahmenbedingungen einzustellen. Außerdem funktionieren Pair Programming oder Daily Standups auch nur dann wirklich gut, wenn der Entwickler gerne und „gut“ kommuniziert.

Niklas Schlimm ist seit über 15 Jahren als Software-Entwickler und Architekt in unterschiedlich großen Projekten tätig. Zurzeit arbeitet er als Gruppenleiter eines Architektur-Teams bei der Provinzial Rheinland Versicherung AG. Seine Schwerpunkte dort liegen im Bereich Agile Software-Entwicklung, Java-EE-Architekturen mit Hostanbindung und Application-Lifecycle-Management.
Geschrieben von
Niklas Schlimm
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.