Seit drei Wochen finde ich mich jetzt in meine neue Rolle ein.
Dadurch dass ich aktuell kein Projekt als Entwicklerin habe, kann ich mich voll darauf konzentrieren. Für den Anfang ist das unglaublich wertvoll. Wenn mich jetzt noch zusätzlich in ein Projekt als Entwicklerin einarbeiten würde, wäre das zuviel Neues auf einmal.
Von daher ist meine Empfehlung an den nächsten Kollegen, der in diese Doppelrolle Entwickler und Prozessbegleiter einsteigen möchte, das ähnlich zu machen und erstmal den Prozessbegleiter Crash Kurs zu durchlaufen, bevor man in die Doppelrolle übergeht.
Maximal könnte ich mir vorstellen, parallel dazu zu 50% in einem Projekt zu arbeiten, in dem man bereits Routine hat.
Der Alltag als Prozessbegleiter ist anders, als ich ihn mir vorgestellt habe.
Es ist mir schwerer gefallen, als ich gedacht hätte, die Prozessbegleiter-Brille aufzusetzen und mich inhaltlich nicht in Diskussionen einzumischen. Und diese Zurückhaltung ist anstrengend, weil ich trotzdem die Diskussionen permanent aufmerksam verfolgen muss, um im richtigen Moment dem Team zu helfen, die Fäden zusammen zu halten, und Fragen so zu stellen, dass sichergestellt ist, dass die Teilnehmer nicht aneinander vorbei reden.
Das nächste, was ich anstrengend finde, sind die vielen Kontextwechsel. Gerade jetzt im Crash Kurs habe ich Meetings für geplant drei - auf Grund von Krankheitsvertretung zwischendurch vier - Teams. Ich muss darauf achten, dass ich mich rechtzeitig auf Meeting-intensive Tage vorbereite und jeden Tag an jedes Team denken.
Das wird nach der Einarbeitung anders werden, aber ich kann jetzt sehr gut nachvollziehen, warum unsere beiden Prozessbegleiter Bedarf sehen, diese Aufgaben auf mehr Schultern zu verteilen.
Der Vorteil daran, dass ich zunächst so viele Teams betreue, ist, dass ich zügig Erfahrungen sammeln kann, gerade was Retros angeht. Und es hilft mir auch, dass ich in jedem Team aktuell die gleiche Rolle habe.
Die spannendste Erkenntnis ist für mich, dass jedes Team bei uns anders ist. Ich hatte erwartet, dass sich die Teams in ihrer Arbeitsweise nicht so stark unterscheiden, aber selbst die Scrum Teams sind alle unterschiedlich in ihren Prozessen, abgesehen von den Regeln, die Scrum vorgibt.
Das hängt von vielen Faktoren ab: den Teammitgliedern, den Product Ownern, den UX Designern, der Projektlaufzeit, der Teamgröße, usw.
In jedem Team sind Product Owner und UX Designer unterschiedlich involviert, je nach Vorlieben, Fähigkeiten und Projektanforderungen.
Die Anzahl und Dauer der Meetings, auch von Retros, und auch die Code Review und Pairing Prozesse sind von Team zu Team unterschiedlich. Aus diesen Unterschieden erwachsen dann auch wieder andere Team Regeln und Erfahrungen.
Die Fragen, die mich dabei beschäftigen, sind:
Welche Individualität hilft dem Team seine Effizienz zu verbessern und welche Erfahrungen und Regeln könnte es sich von anderen Teams leihen, um noch besser zu werden?
Gibt es vielleicht sogar welche, die man zum mindmatters Standard erheben könnte, um weniger Abstimmungs-Aufwand zu haben, gerade wenn Teammitglieder wechseln?
Oder haben wir bereits genug Standards und würden uns weitere nur darin einschränken, so gut wie möglich auf den Kunden einzugehen?
Wie viel zeitlichen Aufwand hat man so als Prozessbegleiter?
Wir waren ja davon ausgegangen, dass man mit ca. 80% bis 90% Entwickler sein kann, und mit ca. 10% bis 20% Prozessbegleiter. Dazu muss ich sagen, dass wir von fakturierter Zeit sprechen und bei mindmatters nur 80% der Arbeitszeit fakturiert wird, in meinem Fall 32 Stunden.
Hier kommt der Realitätscheck der letzten zwei Wochen:
Zu fakturierende Arbeitszeit: 64h
Davon ....
- Prozessbegleitung allgemein: 24,25h (ca. 38%)
- Prozessbegleitung Team A: 2,5h (ca. 4%)
- Prozessbegleitung Team B: 3h (ca. 5%)
- Prozessbegleitung Team C: 4h (ca. 6%)
- Prozessbegleitung Team D: 2,25h (ca. 3,5%)
Prozessbegleitung allgemein buche ich, wenn ich im Tandem mit dem anderen Prozessbegleiter bin und er im Driver Seat. Wenn man diese auf die vier Projekte verteilt, kann man noch ca. 10% fakturierte Zeit auf jedes Projekt aufaddieren.
Damit benötigt man ca. 13,5% bis 16% der fakturierten Zeit pro Projekt als Prozessbegleitung. Die Doppelrolle Entwickler und Prozessbegleiter ist also in der angenommenen Verteilung realistisch.
Dadurch dass ich aktuell kein Projekt als Entwicklerin habe, kann ich mich voll darauf konzentrieren. Für den Anfang ist das unglaublich wertvoll. Wenn mich jetzt noch zusätzlich in ein Projekt als Entwicklerin einarbeiten würde, wäre das zuviel Neues auf einmal.
Von daher ist meine Empfehlung an den nächsten Kollegen, der in diese Doppelrolle Entwickler und Prozessbegleiter einsteigen möchte, das ähnlich zu machen und erstmal den Prozessbegleiter Crash Kurs zu durchlaufen, bevor man in die Doppelrolle übergeht.
Maximal könnte ich mir vorstellen, parallel dazu zu 50% in einem Projekt zu arbeiten, in dem man bereits Routine hat.
Der Alltag als Prozessbegleiter ist anders, als ich ihn mir vorgestellt habe.
Es ist mir schwerer gefallen, als ich gedacht hätte, die Prozessbegleiter-Brille aufzusetzen und mich inhaltlich nicht in Diskussionen einzumischen. Und diese Zurückhaltung ist anstrengend, weil ich trotzdem die Diskussionen permanent aufmerksam verfolgen muss, um im richtigen Moment dem Team zu helfen, die Fäden zusammen zu halten, und Fragen so zu stellen, dass sichergestellt ist, dass die Teilnehmer nicht aneinander vorbei reden.
Das nächste, was ich anstrengend finde, sind die vielen Kontextwechsel. Gerade jetzt im Crash Kurs habe ich Meetings für geplant drei - auf Grund von Krankheitsvertretung zwischendurch vier - Teams. Ich muss darauf achten, dass ich mich rechtzeitig auf Meeting-intensive Tage vorbereite und jeden Tag an jedes Team denken.
Das wird nach der Einarbeitung anders werden, aber ich kann jetzt sehr gut nachvollziehen, warum unsere beiden Prozessbegleiter Bedarf sehen, diese Aufgaben auf mehr Schultern zu verteilen.
Der Vorteil daran, dass ich zunächst so viele Teams betreue, ist, dass ich zügig Erfahrungen sammeln kann, gerade was Retros angeht. Und es hilft mir auch, dass ich in jedem Team aktuell die gleiche Rolle habe.
Die spannendste Erkenntnis ist für mich, dass jedes Team bei uns anders ist. Ich hatte erwartet, dass sich die Teams in ihrer Arbeitsweise nicht so stark unterscheiden, aber selbst die Scrum Teams sind alle unterschiedlich in ihren Prozessen, abgesehen von den Regeln, die Scrum vorgibt.
Das hängt von vielen Faktoren ab: den Teammitgliedern, den Product Ownern, den UX Designern, der Projektlaufzeit, der Teamgröße, usw.
In jedem Team sind Product Owner und UX Designer unterschiedlich involviert, je nach Vorlieben, Fähigkeiten und Projektanforderungen.
Die Anzahl und Dauer der Meetings, auch von Retros, und auch die Code Review und Pairing Prozesse sind von Team zu Team unterschiedlich. Aus diesen Unterschieden erwachsen dann auch wieder andere Team Regeln und Erfahrungen.
Die Fragen, die mich dabei beschäftigen, sind:
Welche Individualität hilft dem Team seine Effizienz zu verbessern und welche Erfahrungen und Regeln könnte es sich von anderen Teams leihen, um noch besser zu werden?
Gibt es vielleicht sogar welche, die man zum mindmatters Standard erheben könnte, um weniger Abstimmungs-Aufwand zu haben, gerade wenn Teammitglieder wechseln?
Oder haben wir bereits genug Standards und würden uns weitere nur darin einschränken, so gut wie möglich auf den Kunden einzugehen?
Wie viel zeitlichen Aufwand hat man so als Prozessbegleiter?
Wir waren ja davon ausgegangen, dass man mit ca. 80% bis 90% Entwickler sein kann, und mit ca. 10% bis 20% Prozessbegleiter. Dazu muss ich sagen, dass wir von fakturierter Zeit sprechen und bei mindmatters nur 80% der Arbeitszeit fakturiert wird, in meinem Fall 32 Stunden.
Hier kommt der Realitätscheck der letzten zwei Wochen:
Zu fakturierende Arbeitszeit: 64h
Davon ....
- Prozessbegleitung allgemein: 24,25h (ca. 38%)
- Prozessbegleitung Team A: 2,5h (ca. 4%)
- Prozessbegleitung Team B: 3h (ca. 5%)
- Prozessbegleitung Team C: 4h (ca. 6%)
- Prozessbegleitung Team D: 2,25h (ca. 3,5%)
Prozessbegleitung allgemein buche ich, wenn ich im Tandem mit dem anderen Prozessbegleiter bin und er im Driver Seat. Wenn man diese auf die vier Projekte verteilt, kann man noch ca. 10% fakturierte Zeit auf jedes Projekt aufaddieren.
Damit benötigt man ca. 13,5% bis 16% der fakturierten Zeit pro Projekt als Prozessbegleitung. Die Doppelrolle Entwickler und Prozessbegleiter ist also in der angenommenen Verteilung realistisch.
Keine Kommentare:
Kommentar veröffentlichen