Es gibt viele Bücher, Kurse etc. zu den Techniken und Tools von Scrum, Kanban & Co. Was aber eher weniger im Blickfeld steht, für den Erfolg von agilen Projekten aber substantiell ist, ist die agile Zusammenarbeit.
Agilität lebt von Flexibilität. Das hört sich aus der Sicht eines Mitarbeiters im agilen Projekt zunächst positiv an: Flexibilität verspricht ein gewisses Maß an Freiheit und das wiederum ist ein Anreiz für diejenigen, die sich in zu starren Organisationen und Projekten nicht wohl fühlen. Falsch eingesetzte Flexibilität kann aber auch zu Problemen führen.
Fehlende oder falsche Kommunikation ist ein Beispiel, wobei das natürlich ein generelles Problem (nicht nur) in der IT-Branche ist und keineswegs ein Problem ausschließlich in agilen Projekten. Aber in Zusammenhang mit Flexibilität können Probleme in der Kommunikation gravierendere Auswirkungen haben als beispielsweise im Wasserfall-Vorgehen, wo es oft umfangreichere formale Vorgaben / Dokumente gibt, auf die man zurückgreifen kann, wenn es an der Kommunikation mangelt. Agiles Arbeiten bedeutet u.a. auch gemeinsame Verantwortung des agilen Teams für den Erfolg, und dazu muss die Kommunikation stimmen, sowohl innerhalb des Teams als auch zwischen Team und dem Rest des Unternehmens.
Flexibilität darf nicht dazu führen, dass die in der agilen Methode vorgesehenen Rollen nicht besetzt werden oder von den mit den Rollen versehenen Mitarbeitern falsch oder unzureichend ausgeführt werden. Die Scrum-Rollen Scrum Master und Product Owner beispielsweise sind sehr wichtige Positionen im Team und sollten mit sachkundigen und mit ausreichend Zeitbudget versehenen Mitarbeitern besetzt sein.
Der Scrum Master ist der Scrum-Experte im Team. Er ist ein Moderator und Berater zu Scrum-Themen und somit der Ansprechpartner, wenn es nicht um operative Projektinhalte, sondern um organisatorische Fragen geht. In vielen Unternehmen wird diese Position bewusst mit externen Mitarbeitern besetzt, um auf diesem Weg auch externe Scrum-Erfahrung ins Unternehmen und in die einzelnen Scrum-Teams zu bringen.
Der Product Owner ist die Schnittstelle zwischen dem Scrum-Team und den Endnutzern. Er priorisiert die Anforderungen und sollte idealerweise tiefes Wissen über das Produkt und die eingesetzten Technologien besitzen, aber auch ausreichend betriebswirtschaftliche Kenntnisse haben, um die Business-Anforderungen rund um das Produkt richtig einschätzen zu können.
Meist wird Scrum zunächst in der IT und dort in vielen Fällen in einem Pilotprojekt ausprobiert. Eine wichtige Frage wird dabei in vielen Fällen (zu) spät beantwortet: Ist das gesamte Unternehmen – also nicht nur der IT-Bereich – „Ready for Agile?“. Manchmal kommt es vor, dass der Wunsch nach agilem Vorgehen aus dem Software-Entwickler-Bereich kommt, teilweise auch in der Form „Auf unsere Stellenausschreibungen melden sich zwar viele Entwickler und fragen dann auch im ersten Vorstellungsgespräch danach, ob und wie agiles Vorgehen bei uns gelebt wird. Wenn wir dann antworten müssen ‚Bisher noch gar nicht‘, dann kommt meist schnell nach dem ersten Gespräch die Absage vom Kandidaten selber“. Wer dann Scrum nur deshalb einführt, um den Entwicklern ihr bevorzugtes Vorgehensmodell zu ermöglichen und vergisst, die Unternehmens- und Projekt-Organisation ebenfalls auf „agil“ umzustellen, der wird schnell in die Stolperfalle „Wie binde ich mein agiles Team in das ansonsten strikt hierarchische Unternehmen ein“ tappen.
In Scrum entscheidet das Team zusammen über den Umfang und den Inhalt von Sprints. Diese gemeinsamen Entscheidungen sind nur dann möglich, wenn alle über einen vergleichbaren Kenntnisstand verfügen. Die in der „Nicht-agilen Welt“ bekannte Konstellation „Der Projektleiter verfügt über alle Informationen zum Projekt/Produkt und gibt nur die Informationen an die Projektmitarbeiter weiter, die diese zwingend für ihre Arbeit benötigen“ führt in der agilen Welt in eine Sackgasse. Nur wenn alle Verantwortlichen im Unternehmen bereit und in der Lage sind, Informationen weiterzugeben und Verantwortung abzugeben, kann der Sprung in die agile Welt gelingen.
Manchmal sind es aber auch vermeintliche „Kleinigkeiten“, die für den Erfolg von agilem Arbeiten mitentscheidend sein können. Als Beispiel sei hier die konsequente Umsetzung des „15-Minuten-Daily-Stand-Up“-Meetings genannt: Wer hat noch nie in einem (zu) langen Meeting gesessen, bei dem frustrierend lange – häufig auch inklusive Überziehung der ursprünglich angesetzten Zeit – über diverse Themen gesprochen wird, die sich im Laufe der Zeit angesammelt haben? Um es im agilen Alltag erst gar nicht so weit kommen zu lassen, sollte man die Bezeichnung „15-Minuten-Daily-Stand-Up“-Meeting zu 100% wörtlich umsetzen: Man trifft sich wirklich an jedem (Arbeits-)Tag zu einer festen Zeit (meist morgens zum Tagesstart) für maximal 15 Minuten. Und wenn dabei wirklich alle stehen bleiben (auch wenn genügend Stühle verfügbar wären), dann beschränkt sich erfahrungsgemäß auch jeder Redner auf das wesentliche, da jeder so schnell wie möglich wieder auf seinen bequemen Bürostuhl zurückkehren will.
Agiles Arbeiten ist nicht nur in aller Munde, sondern hat in vielen Branchen und Projekten schon bewiesen, dass es die Arbeitswelt revolutionieren kann. Mit den genannten Tipps lassen sich Stolperfallen vermeiden und so schneller die Vorteile von agilem Arbeiten für das Unternehmen, aber auch für jeden einzelnen Mitarbeiter genießen.
Auch wir arbeiten agil und beraten Sie gerne mit unseren Erfahrungen.