Wie agil ist agil genug?

Wieviel Agilität benötigt agiles Arbeiten?

Agiles Arbeiten hilft Unternehmen dabei, sich den Herausforderungen und Veränderungen des Marktes anzupassen. In der Praxis gilt es dabei allerdings, einige grundlegende Aspekte zu beachten, die über Erfolg und Misserfolg entscheiden können. Der IT-Dienstleister Avision zeigt, dass mehr Agilität nicht immer sinnvoll ist.

Anzeige

Viele Führungskräfte haben bereits erkannt, dass klassische Unternehmensstrukturen und Entscheidungsprozesse nicht mehr den Anforderungen des modernen Markts und den Ansprüchen der Kunden genügen. Die mittlerweile angestaubten Top-Down-Ansätze und unflexiblen Hierarchien sind spätestens mit Einsetzen der Digitalisierung zu einem Problem geworden. Eine mögliche Lösung: das Konzept des agilen Arbeitens. Hierbei treffen Mitarbeiter Entscheidungen vermehrt in selbstorganisierten Teams, definieren wichtige Ziele und konzentrieren sich auf die Wünsche des Kunden. Was verlockend klingt, kann bei der Umsetzung oftmals zu Problemen führen. Avision zeigt, welche Faktoren ein erfolgreiches Projekt ausmachen, welche Stolpersteine lieber von Anfang an zu meiden sind und dass nicht jedes agile Projekt auch wirklich komplett agil sein muss.

  • Selbstorganisierte Teams: Nicht alle Mitarbeiter sind gleich. Einige wollen keine Führungsaufgaben übernehmen, andere wollen sich nicht in Teams organisieren oder sperren sich gegen neue Arbeitsmethoden. Wieder andere brauchen mehr Zeit, um sich an agile Arbeitsweisen zu gewöhnen. Es eignet sich daher nicht jeder Mitarbeiter gleich gut, um in einem agilen Projekt zu arbeiten. Unternehmen sollten außerdem beachten, dass die Umstellung auf neue Konzepte sowohl Zeit als auch Unterstützung benötigt. Sollte die Zusammenarbeit nicht funktionieren, muss es für selbstorganisierte Teams die Möglichkeit geben, Mitarbeiter zu einem anderen Projekt wechseln zu lassen. Hier gilt: Wenn es die personelle Besetzung erfordert, ist weniger Agilität manchmal sogar besser.
  • Product Owner und Scrum Master: Für die fachliche beziehungsweise Kundenperspektive sind Product Owner in einem agilen Projekt unerlässlich. Sie treffen Entscheidungen und bringen richtungsweisende Ideen mit in die Teamarbeit. Für eine selbstorganisierte und strukturierte Arbeit sorgt wiederum der Scrum Master, der die optimalen Rahmenbedingungen schafft und, wenn nötig, Probleme zur Führungsebene eskaliert.
  • Das Budget: Agile Projekte sind per Definition in Umfang und zeitlichem Rahmen flexibel, Anforderungen können sich ändern und einen festgelegten Kostenprozess gibt es nicht. Das Budget ist daher nur schwer planbar. Dieser Umstand fällt bei Kundenprojekten noch deutlicher ins Gewicht als bei internen – aber auch hier gibt es bewährte Ansätze: Bei einem Time-and-Materials-Ansatz stellt der Kunde das nötige Budget bis das Projekt beendet ist. Dem gegenüber steht ein Festpreismodell. Beide Ansätze haben Vor- und Nachteile, die im speziellen Anwendungsfall zu bewerten sind.
  • Gescheiterte Projekte: Agilität bedeutet auch, ein Scheitern zu akzeptieren. Für den Fall, dass ein Projekt nicht mehr zielführend oder wirtschaftlich sinnvoll ist, können die Beteiligten es früh genug abbrechen. Bei der Aufarbeitung sollten Unternehmen analysieren, ob der agile Ansatz wirklich der richtige war oder ob ein anderes Konzept erfolgreicher gewesen wäre.

„Agiles Arbeiten ist längst kein Trend mehr, sondern hat sich als Konzept etabliert“, erklärt Nadine Riederer, CEO von Avision. „Unternehmen sollten sich aber unbedingt die Frage stellen, wie agil ein Projekt wirklich sein muss. Denn auch wenn das Konzept viele Vorteile mitbringt, ist es in der Praxis nicht immer problemlos umzusetzen. Aus diesem Grund sind auch viele agile Projekte nicht zu 100 Prozent agil, sondern nur zu dem Maß, das für das Unternehmen Sinn ergibt und den Mitarbeitern die bestmöglichen Rahmenbedingungen liefert.“

www.avision-it.de

Weitere Artikel

Jetzt die smarten News aus der IT-Welt abonnieren! 💌

Mit Klick auf den Button “Zum Newsletter anmelden” stimme ich der Datenschutzerklärung zu.