In der heutigen Arbeitswelt ist Agilität das Thema überhaupt. Schneller, effizienter, qualitativ hochstehender muss es werden – und ganz nebenbei wird auch noch dazu gelernt. Wie schnell aber das Gegenteil eintritt, konnte ich selbst miterleben. Warum und was ich aus dieser Zeit lernte, möchte ich mit diesem Beitrag weitergeben.
Ausgangslage
Nach dem Elektrotechnik-Studium trat ich meine erste Stelle bei einer Firma an, die unter anderem eine Vielfalt von Elektronikprodukten entwickelt. Wir waren 18 Personen, bestehend aus Hardwareentwicklern, CAD-Fachleuten und Softwareentwicklern. Die Projekte wurden nach dem Wasserfallprinzip entwickelt. Das funktionierte gut, mit den üblichen Problemen wie Budget- und Zeitmanagement.
Im Softwareteam gab es den Wunsch, an der Projektumsetzung etwas zu ändern. Der Normalfall war, dass ein Entwickler in mehreren Projekten tätig war. Das war kein Problem, solange der Zeitplan stimmte. Trotzdem waren die Kontextwechsel zeitraubend und strapazierten je nach Setup auch die Nerven.
Scrum schlägt mit voller Wucht zu
Das Vorhaben, etwas zu ändern, wurde aber von niemandem vorangetrieben. Rückblickend ein gutes Zeichen, denn für das Team war alles in Ordnung und es funktionierte. Das Verhältnis zu den Kunden war gut, welche dank des Wasserfallprinzips eine hohe Planungssicherheit hatten.
Eine Anfrage eines Kunden löste dann Aufbruchstimmung aus: Der Kunde wollte das Projekt im Rahmen von Scrum durchführen. Das hiess für uns, wir müssen für das uns zugeteilte Software-Teilprojekt ein Scrum-Team stellen. Für uns und besonders für mich war das Neuland. Das Thema sagte uns zu, die Konzepte sind spannend und passen gut zu uns. Es wurde beschlossen, dass wir es probieren und erhielten den Auftrag.
Von da an arbeiteten wir also in einem Scrum-Team. Wir hatten keinen Fahrplan mehr, sondern ein Backlog. Schliesslich sind wir agil. Alle machen alles – wir sind ja agil. Was im nächsten Sprint gemacht wird, entscheidet zu einem grossen Teil der Kunde – denn wir sind ja agil. Bald bestand das Scrum-Team nur noch aus mir und meinem Teilprojektleiter – aber wir sind weiterhin agil.
Der Kunde machte zunehmend Druck, weil der Output nicht mehr stimmte, die Qualität und Zuverlässigkeit der Software abnahm und das von ihm geforderte automatisierte Testen und Integrieren noch nicht einmal angedacht war.
Was daran ist nun agil?
Haben Sie bis hier etwas gelesen, das mit Agilität zu tun hat – ausser dem Wort Scrum? Stimmt, es steht nichts weiter. Der Anfang vom Ende begann, als wir beschlossen haben, es einmal zu probieren.
Unser «probieren» hat dazu geführt, dass sich niemand ernsthaft mit Scrum oder mit agilen Ansätzen auseinandersetzte. Nach und nach fehlte auch die Zeit dazu. Das ganze Softwareteam geriet aus dem Gleichgewicht. Eifersucht entstand, weil ein Projekt mehr priorisiert wurde als andere, man hatte nicht das gleiche Verständnis von Scrum und fing schlussendlich damit an, den Scrum-Prozess immer wieder anzupassen. Es war weiterhin nur ein Probieren, wie man es denn machen könnte.
Die Überzeugung und der Wille müssen da sein
Agil sind wir nicht, weil wir es sein möchten oder der Kunde es verlangt. Wir müssen Agilität im Unternehmen leben und schulen, die Prinzipien vermitteln und ihnen folgen.
Das Team muss wissen, wohin der Schritt von traditionellen Projekten zu agilen Projekten führt. Es braucht ein gemeinsames Verständnis von dem, was einem fehlt und was man will. Eine neue Kultur muss etabliert werden. Die Transformation verlangt zu Beginn viel Selbstdisziplin von jedem Einzelnen, aber auch vom Team selbst.
Eine erfolgreiche Transformation gelingt nur, wenn man alle ins gleiche Boot holt, die Leute schult, und wenn nötig auch offen ist für externe Coachings. Mit Probieren geht’s nicht oder wie Yoda schon sagte:
«Do or not do, there is no try»
