Agile Management

Seit langer Zeit befasse ich mich mit dem Thema "Management" und habe nun mittlerweile auch etwas praktische Erfahrung damit machen dürfen. Es ist immer wieder faszinierend, wie viele unterschiedliche Facetten "Management" hat und wie es von nahezu jedem anders wahrgenommen und verstanden wird. Ursprünglich habe ich mal Informatik studiert und kenne das Thema "Agilität" bereits aus einer anderen Perspektive. Somit war das Thema für mich nicht gänzlich neu, als es mir im Hinblick auf Management begegnet ist.

Aber leider musste ich feststellen, dass die Überführung der Agilität von der Informatik in andere Bereiche - vornehmlich in das Management - doch mit größeren Problemen konfrontiert ist. Ich denke dass einige Probleme damit zusammen hängen, dass die Grundlage der Agilität nicht wirklich beachtet wurde und von manch einem findigen Management-Berater als "goldenes Kalb" durch die Unternehmer-Gemeinde getrieben wurde.

Ursprünglich für die agile Bewegung wird weitgehend die Niederschrift des "Agilen Manifesto" betrachtet. Eine Gruppe von Informatikern waren mit dem sehr starren Vorgehen in einer großen Firma wie IBM nicht wirklich sehr zufrieden. Übermächtige Prozesse behinderten die Kreativität und Schaffensdynamik von Programmierern. Deshalb stellten sie folgende Leitsätze auf:

"Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein." (s. Agile Manifesto)

Es bedeutet nicht, dass die alten Werte und Prozesse über den Haufen geschmissen werden oder gar gänzlich abgelehnt. Es soll lediglich eine Verschiebung des Fokus erfolgen soll. Es war den Initiatoren wichtiger, dass (meiner Meinung nach):

  • Software nicht zum Selbstzweck werden darf und sowohl der Adressat des Produktes als auch die am Entstehungsprozess beteiligten immer Menschen - sogar Individuen - sind. Damit also ein qualitatives Produkt entstehen kann ist es wichtiger, dass die beteiligten Individuen miteinander interagieren und sich nicht nur hinter Prozessen und Werkzeugen verstecken.
  • Eine Software die Funktioniert, und hier denke ich dass damit GUT FUNKTIONIERT gemeint ist, sollte eigentlich keine umfassende Dokumentation benötigen. Hier möchte ich auch auf das Buch "Don't make me think" von Steve Krug  (s. Amazon) verweisen. Ein gutes Design verursacht keine kognitiven Störungen beim Anwender sondern ist so verständlich, dass die Bedienung "natürlich" wird. Und damit ist eine komplizierte Dokumentation ein Indiz für ein verbesserungsfähiges Design.
  • Wie bereits im ersten Punkt wird nochmals auf die Zusammenarbeit bzw. Interaktion Bezug genommen. Es wird aber auf eine Besonderheit der Kommunikation speziell mit dem Kunden hingewiesen. Für ein erfolgreiches Projekt ist es hilfreich wenn Grenzen zwischen Auftraggeber und Auftragnehmer verschwimmen. Sicherlich wird dieses kooperative Zusammenarbeiten vor den aktuellen Strömungen (zumindest in Deutschland) immer schwieriger. Die Aktionen die einige Firmen unternehmen aus der Angst vor der gefürchteten "Arbeitnehmerüberlassung" und der damit verbundenen latenten Möglichkeit, dass sich Menschen in den Mitarbeiter-Status klagen könnten, die man ja gar nicht haben will. Aber ungeachtet dessen ist eine Kooperation immer effizienter und effektiver als eine Konfrontation.
  • Natürlich bin ich als Project Manager davon überzeugt das Pläne wichtig sind. Jedoch ist mir auch durchaus bewusst, dass ein Plan bereits zum Zeitpunkt seiner Aktivierung veraltet ist. Ein Plan darf auch nie den Anspruch erheben eine Vorhersage zu sein, sondern lediglich eine manifestierte Vision. Natürlich sollte ein Plan als Ziel akzeptiert und von allen beteiligten mit einem gewissen Enthusiasmus getragen werden, aber es sollte auch allen klar sein, dass es Situationen gibt, die einen Plan zum scheitern bringen. Natürlich muss ein Projektleiter einen entsprechenden Druck aufbauen, den Plan unter allen Umständen umzusetzen, aber das ist der "Theaterdonner" den es manchmal braucht, damit Personen Höchstleistungen erbringen können. Somit ist ein Plan kein Dogma.

Aus diesen Gründen finde ich einen agilen Ansatz im Management sehr wichtig und meines Erachtens auch unbedingt notwendig. Aus meiner Sicht ist das Hauptproblem im Umsetzen damit begründet, dass viele Menschen in Unternehmen im beruflichen Umfeld immer "unmenschlicher" werden. Agilität kann nur mit der zunehmenden Besinnung auf die gute Zwischenmenschlichkeit in Unternehmen Fuß fassen.