Montag, 28. November 2016

Vergessende Rollen bei agiler Transition

Ich war jetzt fast 2 Jahre in der agilen Welt der Softwareentwicklung als Scrum Master unterwegs und habe  viel neues gelernt. Dabei bekommt man auch ein gutes Bild über die Chancen, Risiken und Gefahren bei einer agilen Transition. Der Weg von einer klassischen hierarchischen Entwicklungsmodell zu agilen selbstorganisierten Teams  ist schwer und lang, da man hier mit Menschen und Verhaltensänderungen zu tun hat. Man muss hier als  agiler Coach viele verschiedene Dinge im Fokus behalten. Es müssen neue Dinge verbreitet und eingeführt werden, aber auch müssen alte Dinge sinnvoll abgebaut werden. Es fallen  Hierarchen und Rollen weg, aber dahinterstehen aber auch  Menschen, die man nicht vergessen darf.

Als erstes sollte man mal ein Blick auf die klassische Software Entwicklung werfen und man findet in solchen Umfeldern Rollen wie Produktmanager,  Projektleiter, Teilprojektleiter oder auch Gruppenleiter. Des weiteren ergibt es sich zwischen den Rollen eine hierarchische Ordnung. Kommuniziert wird hier oft durch Requierments, die den  Charakter von  Bestellung haben und bestimmte Implementierung fordern. Das Ganze funktioniert gut, soll lange man immer wieder das selbe  tut und genau weis, was  sich hinter der Anforderung verbirgt. Doch das ist selten der Fall und  führt  zu einer starken  Kontrollstruktur und Werkzeuge, um das Problem  wie Termine, Budget und Fehlentwicklung zu minimieren. Je nach Größe des Projekt funktioniert das auch mal mit weniger bis gar kein Erfolg. Was dafür die Ursachen sind und was ein Push-System damit zu tun hat,  überlasse ich hier dem Leser, da es viele Beispiel  und Artikel  im  Netz dazu gibt.

Wenn man das Problem verstanden hat und auch die Ursachen für das menschliche Verhalten erkannt hat, dann ist agile Softwareentwicklung hier ein möglicher Weg. Eines der bekanntesten Framework dazu ist Scrum. Es folgt jetzt aber keine  Einführung  in Scrum, sondern mehr ein paar Erfahrungen, welche Schwierigkeiten mit  alten und neuen Rollen auftreten  können, wenn man sich für Scrum und eine agile Transition entschieden hat. Wer dennoch mehr über Scrum wissen mag,  der kann beim Scrum-Master.de gern vorbeischauen.

Im Grunde gibt es mehre Problem mit Rollen und Hierrchien, da eine agile Softwareentwicklung auf selbstorganisierende Teams setzt, welche Probleme des Kunden End-to-End  selbstständig löst. Das setzt voraus, das das Team erstmal die Probleme des Kunden kennt, versteht und selbst die passende Lösung entwickel kann. Das macht aber ein Kontrollstruktur überflüssig und damit verbundene Rollen, weil die Teams hier  selbst die Verantwortung übernehmen. Dabei sollte man  aber Metriken nicht mit Kontrollstrukturen gleich setzen. Metriken sollen  helfen  Probleme zu erkennen und rechtzeitig Entscheidungen zu treffen. Kontrollstrukturen haben dagenen nur das Ziel, sicher zustellen dasder Plan umgesetzt wird und  dienen weniger dazu den  Plan anzupassen.

Ein gute Praktik ist es die Rolle des Produkt Owners oder Scrum Master durch ein ehemaligen Teilprojektleiter zu besetzen. Denn dieser kennen die Kollegen und somit potentiellen Teammitglieder oft schon sehr gut und hat eine gute Verbindung, was die Grundlage für ein gutes Team ist. Teilprojektleiter sind vertraut mit Abläufen im Umfeld, wie z.B. Produktlebenszyklen. Meist ist es auch so, das die Rolle des Teilprojektleiters schon viele Tätigkeiten eines Produkt Owners oder Scrum Master enthielten, aber eben nicht alle. Was aber hier die Herausforderung ist, ein Teil seiner alten Rolle hinter sich zu lassen. Je nachdem wie man sich entscheidet, ist man mehr für das Team oder das Produkt verantwortlich. Hier ist die Untersützung eines agile Coaches notwendig, weil man die Hilfe brauch sich auf die Aufgaben eines Produkt Owners oder Scrum Master zu konzentrieren und andere Teile der alten Rolle hinter sich zu lassen. Es ist hier leicht für denjenigen sich um alte Aufgaben aus seiner alten Rolle zu kümmern, statt die neuen Aufgaben zu meistern.

Da wo es Teilprojektleiter gibt,  ist  auch ein  Projektleiter vorhanden. Da die Teams selbstständig arbeiten, ist  hier ein Projektleiter als Kontrollor überflüssig. Aber was tut man mit dem Menschen der diese Rolle bekleidet hatte? Das ist eine der größeren Herausforderungen bei einer Transition. Der Mensch muss auf jeden Fall  zeitnah abgeholt und bei Entscheidungen mit eingebunden werden, um zu verstehen, wo er sich selbst sieht in der Zukunft sieht. Auch hier gibt es die Möglichkeit von zwei Wegen. Einmal mehr die des Produktes oder des Teams, wobei hier wohl ein Chief Scrum Master weniger sinnvoll ist als ein  Chief Produkt Owner, der die Kommunikation mit den Stakeholder in Vertretung führt und  einzelne Produkt Owner vertreten kann. Wenn man mehre Scrum Teams  hat, die dazu noch an einem  Produkt arbeiten sollen,  ist eine teamübergreifende Produkt Owner Arbeit sicher nicht falsch und man unterstütz sich gegen seitig, Der Chief Produkt Owner ist hier mehr als Coach und Unterstützer der Produkt Owner zu sehen. Das ist auch der Grund warum ein Chief Scrum Master eher ungünstig ist, weil Scrum Master als agile Coaches sich oft besser selbstorganisieren können. Was aber auf jeden Fall keine Lösung ist, das ein Projektleiter weiter als Projektleiter arbeitet und Chief Produkt Owner und Chief Scrum Master in einer Person ist. Lässt man die Rolle des Projektleiter ganz wegfallen, dann sollte man frühzeitig darauf  hinarbeiten und eine neue Aufgabe für den Menschen mit viel Erfahrung finden.

Gibt es keine Teilprojektleiter, weil das Projekt zu klein ist, dann kann der Projektleiter selbst zum Product Owner oder  ein Scrum Mater werden. Die fehlende Rolle kann dann aus den eigen Reihen des Projektes oder von außen gefüllt werden z.B. ein überflüssig gewordener Projektleiter.

Produktmanager sind oft doch etwas weiter Weg von dem  eigentlichen Entwicklungsprojekt und von daher ist es nicht verkehrt ihn auch nur als Stakeholder zu betrachten. Aber man muss auch hier deutlich einwirken als agiler Coach oder erfahrender Scrum Master, weil sie die Art der Einflussnahme eines Produkt Managers ändert. Auch die Kommunikation zwischen Produktmanager und Product Owner verändert sich und es wird mehr über die Probleme des Kunden gesprochen als über Lösungen, die aus dem Produktmanagement stammen. Das ist eine Herausforderung, weil hier sich das alte Verhalten in der Rolle des Produktmanager verändern muss. Hier kann man  Produkt Owner und Produktmanagement nicht alleine lassen, weil hier Menschen mit einer neuen Rolle und Verhalten aufeinander treffen. Ein  Scrum Master oder agile Coach sollte das am Anfang begleiten. Wenn hier etwas in weniger agile Bahnen läuft, ist der Schaden recht groß und gefährdet eine Transition, da Scrum Teams nur schwer  ihre Stärke ausspielen können. Gerade Stakeholder müssen lernen, wie arbeiten und denken agile Teams, und muss für sich den  Nutzen erkennen mit Problemen und nicht Lösungen zu den Scrum Teams zu gehen. Hier sind einige Coaching- Gespräche notwendig.

Das Aufbrechen von  Hierarchien ist nicht überall möglich oder dauert Zeit. Das betrifft besonderes Management, was von der Entwicklung doch etwas weiter weg ist. Aber man sollte diese Menschen nicht vergessen, weil sie genug Einfluss haben, eine agile Transition zum Scheitern zu bringen. Hier ist es wichtig das Management abzuholen und transparent zu machen was passiert. Sie müssen ein gutes Gefühl bekommen, das die Teams das richtige tun im Sinne des Unternehmens. Eine gute Praktik ist es hier aus den Teams heraus Management Monitore  zu erstellen und sie selbst ständig und regelmäßig zu berichten. Man zeigt den realen Fortschritt und macht auch eine Zielplanung.  Aber Transparenz zu schaffen ist nur der halbe Weg. Die Herausforderung ist hier, das Management zu zeigen, wie man mit der Transparenz richtig umgeht und welche Aktionen man wann einleiten sollte. So schafft man Vertrauen, macht Entscheidung sichtbar und jeder weis, wo wir stehen. Nichts macht mehr ungutes Gefühl als Ahnungslosigkeit und Unwissenheit. Diese Ahnungslosigkeit führt oft  zu ungesteuerten Aktionen.

Abschließen würde ich sagen, man muss jeden mitnehmen und seine Ängste und fragen ernst nehmen. Lass Projektleiter, Produkt- und Topmangement nicht alleine. Sie haben in der alten Welt sehr viel Einfluss und können eine Transition aus Angst und Unwissenheit zum scheitern bringen. Mit ein bisschen Fokus auf diese Gruppen ist das gut vermeidbar.

Keine Kommentare:

Kommentar veröffentlichen