IT- Entwickler arbeiten gerne genau: Jedes Detail muss stimmen, damit das Endprodukt alle Anforderungen erfüllt. Bei der Entwicklung hat gerade der kreative Entwickler gerne noch eine spontane Idee, wie das Produkt noch besser wird - und weil er gerade eh dabei ist, wird die vermeintlich kleine Änderung direkt noch mit programmiert - mehr ist schließlich besser.
Der kaufmännisch orientierte Projektleiter hat dafür wenig Verständnis: Er lebt im Dreieck zwischen Kosten, Leistung und Zeit. Mehr Leistung muss nicht sein, dauert länger und überhaupt muss mehr Leistung mit dem Kunden abgesprochen und bestenfalls vorab bepreist sein. Ein Spannungsfeld zwischen Entwickler und Projektleiter entsteht - was hilft dagegen?
Zieldefinition
Der klassische Projektleiter definiert vor Projektbeginn Ziele oder Anforderungen, Prozesse, Usecases, Customerjourneys etc. - bestenfalls zusammen mit dem Auftraggeber und dem Projektteam. Je länger das Projekt dauert, desto mehr neigen diese initialen Bemühungen zumindest beim Projektteam in Vergessenheit zu geraten. Dazu ist es natürlich hilfreich, die entsprechenden Projektunterlagen auf einem Projektlaufwerk abzulegen und die finale Version dem Team vorzustellen. Jetzt ist jeder formell informiert… Der Stress im laufenden Projekt, Auslastung aus anderen Projekten, mangelndes Verständnis für vermeintlich sinnlose bürokratische Dokumente und weitere Engpässe sorgen jedoch dafür, dass das Projektteam sich nicht mehr damit beschäftigt. Die Ziele können im Projektmeeting wieder herausgekramt und noch einmal verdeutlicht werden - echt jetzt!? Wir versinken hier im Chaos, der Projektleiter fordert Fortschritte ein, alle machen Überstunden, und jetzt wird die Meetingzeit noch auf eine Präsentation von Zielen von vor 6 Monaten verwendet, die eh nicht mehr aktuell ist?
Der agile Projektleiter definiert die Ziele pro Sprint, also in einem kürzeren Zeitraum von 2 bis 4 Wochen. Auch dabei sind die Entwickler nicht vor spontanen Eingebungen sicher - der Entwickler kann beim Daily Standup vergessen, von seiner tollen Idee zu berichten, im Optimalfall stellt er sie am Ende des Sprints vor, im schlimmsten Fall crasht etwas bei einem späteren Sprint. Aus der Rolle des Servant Leaders heraus ist der Scrummaster nicht direkt befugt, den Rückbau einer spontan im Sprint realisierten Idee einzufordern - falls der kreative Programmierer seine Idee vorstellt, das Dev Team sie als gut empfindet und voller Überzeugung dem Product Owner vorstellt, kann es passieren, dass auch der Product Owner überzeugt wird. Dies animiert das Scrumteam natürlich, in weiteren Sprints wieder kreativ zu werden - es besteht die Gefahr, dass der Kunde am Ende etwas in weiten Teilen anderes erhält, als das, was er bestellt hat.
In beiden Systemen, klassisch und agil, ist die Zielverfolgung somit stark von der Selbstdisziplin und Kommunikationsbereitschaft der Projektbeteiligten abhängig, da kein Projektleiter seine Projektmitarbeiter detailliert anleiten und überwachen kann und möchte.
Design Thinking und Design Sprint
Ein zumindest langfristig ausgelegter Besserungsansatz kann im Design Thinking liegen - das hört sich immerhin schonmal modern an und kann daher auch gut verkauft werden. Die aus meiner Sicht in diesem Kontext wesentlichen Kernaspekte (bzw. Ziele) beim Design Thinking und beim Design Sprint sind:
Es soll schnell ein marktfähiger Prototyp entwickelt werden.
Das ist unterm Strich natürlich auch nur alter Wein in neuen Schläuchen - ein kluger klassischer Projektleiter arbeitet auf dieses Ziel natürlich genauso hin wie ein Scrummaster in jedem einzelnen Sprint. Warum also meine ich, dass dieser Ansatz helfen kann?
Die Maxime: “schnell einen marktfähigen Prototypen entwickeln” kann in einem klassischen Projekt als (Ober) Ziel aufgenommen werden. Somit muss sich erstmal kein Projektleiter völlig umgewöhnen. In einem agilen Projekt kann der Satz über dem Taskboard aufgehangen werden und/ oder in jedem einzelnen Sprint verankert werden. Der Formalität ist damit genüge getan.
Der Nutzen dieses einen Satzes kann jedoch wesentlich besser dorthin transportiert werden, wo das Projekt eigentlich stattfindet: In die Köpfe der Projektmitarbeiter bzw. des Scrumteams. Er kann kurz und knackig als Mantra verankert werden und die Menschen somit ohne hohen Zeitaufwand fokussieren. Im klassischen Projekt zu Projektbeginn bei der Vorstellung der Zielhierarchie als ganz wichtiges Ziel betont und fortlaufend in jedem Projektmeeting. Im Daily Standup bei der eingehenden Frage des Scrum Masters: Was wollen wir heute tun, um schnell einen marktfähigen Prototypen zu entwickeln? Das alles kostet sehr wenig Zeit, den einen Satz können sich alle Projektmitarbeiter schnell merken und leichter verinnerlichen als eine eventuell umfangreiche Zielhierarchie oder diverse Taskkärtchen. “Prototyp” ist zumindest noch ein nicht so abgenutztes Wort wie “Ziel” - Ziele haben wir irgendwo alle, Ziele sind weit entfernt und an Zielen muss man ja auch nicht jeden Tag dringend mit vollem Nachdruck arbeiten - das macht man eher langfristig, wenn mal zwischendurch Zeit ist. Ein Prototyp ist fresh, innovativ, spacig und ohne Schnörkel - den geht man doch viel lieber an als ein langweiliges Ziel, oder?
Da auch die Idee des Prototypen mittlerweile schon etwas etablierter ist, wurde schon die nächste Sau gefunden, die durchs Dorf getrieben werden kann: Das Minimum Viable Product (MVP) - ein Minimalprodukt mit Basisfeatures - wieder ein neuer Schlauch für unseren alten Wein. Dieser Anglizismus mitsamt moderner Abkürzung ist jedoch erklärungsbedürftig und dürfte vom durchschnittlichen Projektteam nicht intuitiv verstanden werden - ein “Prototyp” weckt hingegen direkt bildhafte Assoziationen. Somit eignet sich das MVP gut für Berater, um erklärende Präsentationen zu halten und dafür Stunden schreiben können, nicht jedoch für die breite Masse um ein gemeinsames Verständnis zu erlangen.
Konnten Sie bereits ein Projektteam (agil oder klassisch) zu hoher Selbstdisziplin führen? Wie haben Sie es geschafft? Welche Erfahrung haben Sie mit Zieldefinitionen und Design Thinking oder Design Sprints? Welches Modewort sollen wir verwenden, wenn auch der “Prototyp” irgendwann abgenutzt ist? Schreiben Sie ihren Kommentar.
Keine Kommentare:
Kommentar veröffentlichen