In der heutigen Arbeitswelt wird gerne mal über agiles Arbeiten gesprochen.

  • Agilität ist die Zukunft!
  • Ohne Agilität ist man nicht mehr wettbewerbsfähig!
  • Wir müssen schnell agil werden!

Woher kommt der Begriff des agilen Arbeitens?

Hier lohnt sich ein Blick in die Vergangenheit, um die Herkunft dieses Begriffes und seine Bedeutung zu ergründen. Agiles Arbeiten wurde als neuer Ansatz in der Softwareentwicklung im Jahr 2001 erstmals zusammenfassend in der Methode SCRUM und dem begleitenden „Agile Manifesto“ von Softwareentwicklern beschrieben.

Die Ziele waren schnellere Entwicklungszyklen mit absoluter Fokussierung auf kunden- oder anwenderrelevante Funktionalität/Nutzen. Klassische Entwicklungszyklen sollten aufgebrochen werden, um eine schnellere Anpassung an die sich ändernden Anforderungen des Marktes zu erzielen. Auch war bekannt, dass bei den meisten Softwareentwicklungen von einem Großteil der Anwender nur ca. 20 % der Funktionalität tatsächlich benutzt wurden. Nichtsdestotrotz wurden neue Versionen erst freigeschaltet, wenn das Gesamtpaket fertig war. Dies führte zu langen Entwicklungszyklen und jeweils großen Versionswechseln. Mit dem neuen, agilen Ansatz wurden in jedem kleinen Entwicklungszyklus, der je nach Thema und Team ein bis maximal vier Wochen dauerte, jeweils fertige und lauffähige Mini-Module (minimal viable product) produziert. Dies steigerte die Effizienz der Entwicklung enorm.

Und was bedeutet agiles Arbeiten nun genau?

Bleiben wir beim Beispiel der Softwareentwicklung und des Roll-outs, gehört zum Ansatz des agilen Arbeitens, dass diejenigen Teams, die die operative Umsetzung gestalten, eigenverantwortlich arbeiten. Der Einzelne und die Zusammenarbeit stehen hier über wohl definierten Abläufen. In jedem dieser Teams müssen alle Rollen besetzt sein, um für diese Software den Aufwand zu schätzen und diese zu designen, zu programmieren und zu testen. Dabei arbeitet das jeweilige Team völlig eigenverantwortlich. Im Allgemeinen steigen die Produktionsgeschwindigkeit oder der funktionale Output solcher Teams mit wachsender Erfahrung.

Nur sind diese eigenverantwortlich arbeitenden Teams nicht das einzige, was sich vor dem Hintergrund erfolgreichen agilen Arbeitens dem Prozess anpassen bzw. diesen neu gestalten muss. Es gibt eine Seite (Product owner), die dem Kunden oder dem Markt zugewandt ist und dort sehr präzise die gewünschten Funktionalitäten aus Kunden- oder Endanwendersicht beschreibt und in regelmäßigen Zyklen diese Anforderungen neu priorisiert. Dazu werden unterstützend „Agile Coaches“ eingesetzt, die zum einen die umsetzenden Teams im Prozessrahmen unterstützen, zum anderen Probleme aufnehmen, im Unternehmen ansprechen und beseitigen sowie die regelmäßigen Austauschrunden organisieren und moderieren.

Es gibt noch diverse andere agile Ansätze, die eines gemeinsam haben: Das Umsetzen erfolgt in freiheitlich und eigenverantwortlich arbeitenden eigenständigen Teams. Auch hat sich das Thema des agilen Arbeitens längst in anderen Bereichen außerhalb der Softwareentwicklung etabliert.

Welche Kompetenzen müssen vorhanden sein, um sich in solch einem Umsetzungsteam wohlzufühlen?

Zum einen muss ich natürlich gerne im Team arbeiten. Der tägliche Austausch und die Abstimmung untereinander sind ein wichtiger Erfolgsfaktor.

Auch muss ich bereit sein, für meine Arbeit und für das Team Verantwortung zu übernehmen. Innerhalb solch eines Teams treten alle Themen, die auch unter „normalen Arbeitsbedingungen“ relevant sind, ebenfalls auf und wollen geklärt werden:

  • Wie planen wir unsere Urlaubstage?
  • Was machen wir, wenn jemand kurzfristig erkrankt?
  • Wie gehen wir mit einem Teammitglied um, das nicht die gleiche Leistung bringt wie wir anderen oder die erforderliche Leistung bringt?
  • Was machen wir, wenn jemand neu dazu kommt oder ausscheidet?
  • Wie gehe ich mit steigenden Überstunden um?

Ich muss also über den Tellerrand meiner Fachkompetenz blicken wollen.

Ein Kern der agilen Entwicklung ist es, auch noch sehr spät im Entwicklungsprozess auftretende signifikante Veränderungsanforderungen mit aufzunehmen und zu realisieren. Hier muss ich persönlich auch offen für Veränderungen sein: „Was der Kunde oder Anwender wünscht, ist der Auftrag, dem ich gerne und immer wieder neu folge.“

Ein ganz wichtiger Faktor ist auch die Eigenverantwortung. Traue ich mich, realistische Schätzungen abzugeben, auch wenn der Auftraggeber Druck macht? „Ich habe die drei letzten Nächte fast durchgearbeitet und bräuchte dringend mal eine Pause, aber die Deadline ruft. – Finde ich hier den Mut, dies auch offen zu kommunizieren?“ Ich muss meine Arbeit also selber einteilen. Fällt mir das leicht?

Welche Kompetenzen braucht das Unternehmen?

Hier sind vor allem die früher voll verantwortlichen Führungskräfte gefragt, ihre Bereitschaft, agil arbeitende Teams zuzulassen:

  • Kann ich meinen Mitarbeitern so viel Verantwortung übergeben?
  • Reicht mein Vertrauen in sie?
  • Habe ich die Disziplin, mich aus dem Entwicklungsprozess herauszuhalten?
  • Kann ich Teambeschlüsse akzeptieren, auch wenn ich selber anders entscheiden würde?
  • Kann ich den Prozess zu Sammlung und Priorisierung der fachlichen Anforderungen so gestalten, dass er klar und in der operativen Umsetzung weitgehend autark läuft?
  • Kann ich damit leben, dass sich meine Umsetzungsteams nicht so schnell entwickeln wie ich es mir wünsche?
  • Kann ich ein Umfeld aufbauen, das auf dem höchsten technischen Niveau ist, um meine Entwickler bestmöglich zu unterstützen?

Agilität basiert auf kleinen, autonom und selbstorganisiert arbeitenden Teams. Dies müssen Führungskräfte „aushalten“ und aktiv unterstützen, damit gewinnbringend, effektiv und effizient Leistung erbracht werden kann.

Fazit

Insgesamt ist der Einsatz agiler Umsetzungsmethoden eine Entscheidung, die in einem größeren Kontext getroffen werden muss. Immerhin bricht agiles Arbeiten an vielen Stellen mit traditionellen Organisations- und Projektstrukturen und wagt Neues. Dabei muss nicht das ganze Unternehmen agil werden, aber wenn ich Bereiche agilisieren möchte, dann müssen die Abläufe und Verantwortlichkeiten klar definiert werden.

 

Wenn agil – dann richtig!