Change

Mitarbeiter befähigen, statt nur Prozesse zu verändern

In den letzten Jahren habe ich selbst als Teil-Projektleiter und Projektleiter in – in guten Fällen klassisch nach Wasserfall oder nach agilen Methoden organisierten, in weniger guten und weitaus häufigeren Fällen chaotisch ausgerichteten Projekten – gearbeitet und mit Mühe und Not versucht, in einer schnelllebige Welt mit sich stetig ändernden Kundenanforderungen zurecht zu kommen und in ein chaotisches Umfeld Struktur zu bringen.

Agile Softwareentwicklungsmethoden wie Scrum versprachen mehr Transparenz, kurze strukturierte Iterationen und damit eine gute Gelegenheit, frühzeitig einzugreifen wenn Probleme auftreten. Die Aufgaben im Projektmanagement, die früher der Projektleiter selbst bzw. alleine in der Hand hatte, wurden in Scrum nun in drei Rollen aufgeteilt. Die Probleme sollten da gelöst werden, wo sie entstehen und Entscheidungen sollten diejenigen treffen, die per Definition der entsprechenden Verantwortlichkeiten die Aufgaben hatten.

Irgendwann aber glaubte man, dass Scrum viele Vorteile bringe, aber vielleicht nicht immer geeignet sei, weil Anforderungen zu flexibel seien, und zu unvorhersehbar aufkämen. Also versuchten wir, einen Teil der Aufgaben – die sich nicht in langfristigeren Projekten abbilden ließen – mittels eines Kanban-Boards zu strukturieren. Aber auch hier lief nicht alles rund, Termine wurden nicht gehalten, Qualität stimmte nicht immer. Teams und deren Mitarbeiter organisierten sich auch nach mehr als einem Jahr gemeinsamer Arbeit nicht wirklich selbst, Micromanagement-Aufgaben rutschten immer wieder zurück zu den Projektleitern, die sich in ihren Rollen als Scrummaster oder Productowner versuchten und hier ihren Aufgaben und Verantwortlichkeiten oft mehr schlecht als recht gerecht wurden.

 

Bei all den Erfahrungen in den letzten Jahren mit unterschiedlich stringent durchgeführten Prozessen zwischen Scrum, Scrumbut, Scrumban und Kanban wird vor allem eins deutlich: ein Prozess ist maximal so gut wie die Leute, die ihn leben und nur weil man Dinge transparent macht oder Verantwortlichkeiten im Management neu verteilt, werden die Ergebnisse nicht zwangsläufig besser. Zusätzlich zur Tatsache, dass alle lernen und man verschiedene Dinge ausprobieren muss um ein für das jeweilige Team guten Prozess zu finden, der sich nahe am Alltag und den zu bewältigenden Aufgaben orientiert, ist es entscheidend, dass die Rollen in einem Prozess klar sind und die Personen, die sie erledigen sollen, befähigt und bevollmächtigt werden, ihren Verantwortlichkeiten gut gerecht zu werden.

Wenn Aufgaben nicht gut erledigt werden wird schnell der Prozess geändert, weil man glaubt, er passe nicht zu den Rahmenbedingungen und wäre damit der Grund des Übels. Auf einen „falschen Prozess“ als „Grund des Übels“ einigt man sich gerne, denn für Probleme im Prozess ist niemand verantwortlich, hier kann man ändern, schrauben und verbiegen, wie man will und immer wenn es nicht zum gewünschten Ergebnis führt, hat man nur noch nicht den geeigneten Prozess gefunden. Der wirkliche Grund, wieso häufig trotz eines (vermutlich)  guten Prozesses das Ergebnis nicht stimmt (egal ob das Projektergebnis nicht in Time oder In Budget oder In Quality abgeliefert wurde) sind die fehlenden Fähigkeiten der Projektbeteiligten in ihren Rollen. In Scrum ist das zum Beispiel ein Scrummaster, der sein Team nicht betreut, ein Productowner, der sein Produkt nicht beschreibt und priorisiert und ein Team, das nicht für die eigene Qualität sorgt. Termin- und Prozesstreue, Priorisierung und Qualität sind aber wichtige Punkte für Softwareprojekte, egal mit welchem Prozess sie angegangen werden. Es hilft wenig, ein Wasserfall-Vorgehen durch einen Scrum-Prozess und ein Scrum-Prozess durch ein Kanban-Board getauscht werden, wenn wichtige Aufgaben nicht oder nicht gut erledigt werden.

 

Wenn die unterschiedlichen Rollen und deren Aufgaben nicht allen Projektbeteiligten klar sind und diese Aufgaben und Verantwortlichkeiten nicht zuverlässig erfüllt werden, dann werden Projekte scheitern unabhängig vom Prozess. Dabei bin ich überzeugt davon, dass die Transparenz und Nähe zum Menschen in agilen Vorgehensmethoden mit einer größeren Wahrscheinlichkeit zum Projekterfolg führen und dass das Arbeiten in solchem Umfeld mehr Spaß macht – aber auch hier müssen gute Mitarbeiter ihren Aufgaben gerecht werden und dafür befähigt und bevollmächtigt werden. Die größte Stärke von agilen Vorgehensmethoden wie Scrum oder Kanban ist am Ende die Transparenz die die Möglichkeit gibt, in einen Prozess der kontinuierlichen Verbesserung zu kommen – aber ohne eine kontinuierliche Verbesserung vor allem in den Fähigkeiten der Mitarbeiter, kommt man in keinem Prozess weiter.

One Comment

Leave a Comment

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert