Wie geht's, Scrum Master?

Petr Hendl kam im April 2022 als Senior Consultant zu SABO. Im September übernahm er die Aufgaben des Projektmanagers und Scrum Masters für eines unserer zahlreichen laufenden Volkswagen Projekte.

Petr, welche Erfahrungen haben Sie mit agilem Projektmanagement gemacht?

Ich war bereits Mitglied in agilen Teams (sowohl als Entwickler als auch als Tester), aber ich war noch nie als Teamleiter. Ich habe jedoch langjährige Erfahrung mit Projektmanagement. Ich hatte mehrere Monate im SABO, um zu beobachten und zu lernen, und ich muss sagen, ich war überrascht. Positiv überrascht. Agile Projekte sind populär, aber wenn man Unternehmen fragt, sagen sie in der Regel: "Wir machen so etwas wie Scrum, aber wir haben es an unsere Bedürfnisse angepasst.

Finden Sie, dass SABO in Agile gut ist?

Ja, die Prozesse sind die besten, die ich bisher gesehen habe. Und ich habe Teams in großen internationalen Unternehmen gesehen, die teure Coaches bezahlen, aber auch kleine Start-ups, die versuchen, ihren Entwicklungsprozess zu optimieren. Ich habe immer wieder die gleichen Fehler gesehen - überfüllte Boards, verspätete Releases, offene Aufgaben. Entscheidungen, die von Entwicklern getroffen werden, denen der Input der Productowners fehlt. Endlose Pokerrunden, Teams, die sich in der Fehlersuche verlieren, Kunden, die auf Termine drängen, und so weiter.

Sind Productowner wichtig?

Auf jeden Fall. Keine Vorgabe und keine Spezifikation ist perfekt. Das kann gut oder schlecht sein, aber es gibt immer Fragen und Zweifel. Wenn Entwickler Entscheidungen treffen, können sie sich oft irren, weil sie einen anderen Blickwinkel haben. Aber es hilft sehr, wenn Entwickler fragen können und prompt Antworten bekommen, damit sie nicht etwas falsch oder zu kompliziert programmieren. Agile Entwicklung an sich ist nicht schneller, wenn man produzierte Codezeilen oder sonstige Funktionseinheiten verwendet. Nach meinen Beobachtungen gibt es drei Arten von Productownern:

1. POs, die nie wissen, wie sie antworten sollen, haben nur allgemeine Ideen und nehmen alle Fragen, die in der Diskussion auftauchen, mit, um sie später mit einem anderen Team zu besprechen. Sie kommen nie wieder und entscheiden nichts. Das Team wartet in der Regel lange auf eine Antwort und geht dann von Vermutungen aus oder implementiert die komplexeste Lösung.
2. POs, die sich nicht sicher sind, aber nachfragen können und innerhalb weniger Tage mit Antworten zurück kommen. Dies führt zu Verzögerungen in der Entwicklung und zwingt die Entwickler, zwischen den Themen hin und her zu springen, aber zumindest gibt es am Ende immer eine Lösung.
3. POs, die stark in das Geschäft eingebunden sind, den Umfang definieren und das zu entwickelnde System nutzen. Diese können in der Regel sofort antworten, so dass die Entwicklung reibungslos und effizient verläuft. Wenn sie sogar Prioritäten setzen und auf zu komplexe Lösungen verzichten können, haben Sie eine goldene Trophäe gefunden - und den Schlüssel zum Erfolg Ihres Projekts.
   

Ich freue mich sagen zu können, dass wir den 3. Fall in unserem Volkswagen Projekt haben.

Heißt das, der Wasserfall-Projektprozess ist tot?

Meiner Meinung nach nicht. Es gibt immer noch Fälle, in denen es besser passt - meiner Erfahrung nach vor allem große Festpreisprojekte für Behörden oder Unternehmen, bei denen man wissen muss, wann, was und zu welchem Preis geliefert werden soll. Sowie Systeme mit Schnittstellen und Abhängigkeiten, die wegen der Synchronisation mit anderen Systemen und Institutionen langfristig geplant werden müssen.

Auch im Rahmen des Wasserfallprinzips sollten Techniken wie MVP (Minimum Viable Product), kontinuierliche Integration, automatisierte Tests und andere Techniken, die üblicherweise im Zusammenhang mit agiler Entwicklung genannt werden, eingesetzt werden. Beim Wasserfallprozess ist es jedoch wichtig, ein großes Projekt in kleinere Phasen, Meilensteine, Teams usw. zu unterteilen, um den Arbeitsaufwand handhabbar zu machen. Ein gut implementiertes Change Management ist unverzichtbar. Es gilt das Gleiche wie im vorigen Absatz - Entwickler brauchen immer Klärungen und Entscheidungen - auch hier ist die Einbeziehung von Stakeholdern notwendig.

‍

Vielen Dank und viel Erfolg für Ihre Projekte!