Was ist nun besser? Agile oder Hierarchie? Schließt das Eine das Andere aus? Handelt es sich um eine Modeerscheinung oder eine neue Form der Zusammenarbeit?

Vorweg muss ich festhalten, dass ich u.a. seit über 20 Jahren in der IT Branche tätig bin und somit die Anfänge von Agilität in der Softwareentwicklung miterlebt habe. Seit nunmehr ca. 15 Jahren beobachte ich die verschiedenen Ansätze und Gehversuche dazu. Ich würde sagen, agile Arbeitswesen sind am Weg. Das Ziel ist noch nicht erreicht, möglicherweise auch noch gar nicht einheitlich festgelegt.

Für all jene, die jetzt gar nicht wissen, worum es hier geht: In der klassischen Softwareentwicklung definiert man ein Pflichten- oder Lastenheft, wo die Anforderungen an eine Software festgelegt und beschrieben sind. Auf Basis dessen wird ein Preis und ein Termin vom Dienstleister genannt, wann die Software für den Käufer zur Verfügung steht. Bei größeren Aufträgen kann es sich hier um Jahre Entwicklungszeit handeln. Der Kunde kauft also etwas, das erst programmiert werden muss und zum festgelegten Zeitpunkt fertig werden soll.

Im besten Fall hat der Dienstleister genau verstanden, was der Kunde möchte und liefert die Software pünktlich. Dann beginnt der Kunde mit den Abnahmetests und startet mit dem Einsatz der neuen Software. Es kann jedoch auch passieren, dass der Dienstleister nicht das Gleiche verstanden hat, was der Kunde im Dokument gemeint hat. Dies wird dann erst erkennbar, wenn die Software fertig ist und zieht aufwändige Änderungen nach sich.

Wenn der Entwicklungszeitraum sehr lange dauert, kann es auch sein, dass sich die Anforderungen des Kunden ändern und, wenn er nicht Change Requests beauftragen würde, er am Ende eine Software bekommen würde, die er so gar nicht verwenden kann. Und nun kommen wir zu einem der Vorteile der agilen Vorgehensweise: Änderungen sind kurzfristig möglich. Wie funktioniert also Agilität in der Softwareentwicklung?

Der Kunde hat ein festgelegtes Gesamtbudget und eine grobe Vorstellung, was die Software am Ende können soll. Zwischen dem Kunden und dem Dienstleister werden Entwicklungszeiträume festgelegt, sogenannte Sprints, die meist zwischen zwei und vier Wochen dauern. In diesen Sprints werden immer kleine Teile der Software programmiert, getestet und vom Kunden geprüft. Diese Teile sind in sich geschlossen und meist nicht zwingend abhängig von anderen Entwicklungen. Der Kunde legt am Beginn eines solchen Sprints immer gemeinsam mit dem Dienstleister fest, welche Teile (User Stories) er umgesetzt haben möchte.

Das bedeutet, dass der Kunde von Sprint zu Sprint seine Meinung über die perfekte Software für sich ändern kann. Er kann so auf unvorhersehbare Anforderungen besser reagieren. Selbstverständlich dauert es immer eine gewisse Zeit bis genügend einzelne Teile geschaffen wurden, um mit einer Version 1 der Software für den User starten zu können.

So ein agiles Entwicklungsteam hat – und hier hängt es von den verschiedenen Modellen (z.B. SCRUM, KANBAN) ab – verschiedene Rollen im Team. Es gibt beispielsweise einen Software-Architekten, einen Entwickler, einen agilen Coach, einen Product Owner (der für die Wertmaximierung des Produkts und die Arbeit des Entwicklungsteams verantwortlich ist) sowie einen Projektleiter. Es geht im agilen Team nicht um Hierarchie, sondern um die rollenbasierten Verantwortungen.

Und das macht es nun wieder spannend, wie man agile Teams in eine Organisation integriert. Es gibt verschiedenste Ansätze und viele Konflikte. So kann man z.B. eine hierarchisch geprägte Organisation hernehmen und den Teamleitern oder Abteilungsleitern ein oder mehrere agile Teams zuweisen. Die Verantwortungen der agilen Rollen überschneiden sich zum Teil mit den hierarchischen Rollen. Manchmal übernehmen auch Teamleiter in Personalunion die Funktion des Product Owners oder Scrum Masters, was zu inneren Konflikten der Person mit den verschiedenen Rollen führen kann.

Andere wiederum versuchen hierarchische Organisationsrollen zu eliminieren und sich auf reine agile Rollen und Teams zu fokussieren. Hier fehlt oftmals die Klammer- und Steuerungsfunktion über das gesamte Unternehmen hinweg. Jedes agile Team fühlt sich für sich selbst und seine Ergebnisse verantwortlich, interessiert sich aber nicht für die Ziele des Nachbarteams oder gar die Unternehmensziele.

Damit es hier nicht zum Chaos kommt ist es essentiell, dass man das Wesen einer agilen Organisation erkennt. Es geht nicht darum, über Positionen zu führen, die sich vor allem durch ein entsprechendes Kästchen im Organigramm widerspiegeln. Sondern man fokussiert sich auf Rollen, die stärkenorientiert sind und funktional führen. Eine Führungskraft, die inhaltlich nicht weiß, was sie tut, gibt es in einer agilen Welt nicht.

Führung bedeutet in der agilen Welt die Richtung zu weisen und vor allem Hindernisse für die Teammitglieder aus dem Weg zu räumen. Führung wird am Ergebnis festgemacht und der Erfolg wird nicht einer einzelnen Person oder Rolle, sondern dem gesamten Team zugerechnet. Es ist ein respektvoller Umgang miteinander auf Augenhöhe. Übrigens genau das, was die Generation Z in der Arbeit erwartet. (Lesen Sie hierzu mein Buch: „Die junge Generation Z in der Arbeitswelt: Tipps & Tricks für Führungskräfte und Kollegen“)

Die Rollen können übrigens temporär für spezifische Situationen übernommen werden. Sie können jedoch auch in Vollzeit oder zu einem bestimmten Prozentsatz der Arbeitszeit ausgefüllt werden. Wichtig ist für die Führung in agilen Teams die psychologische Sicherheit, die man als Teammitglied empfindet, und dass man einen großen Wert auf die zwischenmenschlichen Komponenten legt.