cartoon_findingtherighttimeNachdem ich im letzten Beitrag ein paar Gedanken (wieder einmal) zur Einführung von Scrum im Unternehmen niedergeschrieben habe, möchte ich mich heute zur Abwechslung einmal mit den sehr praktischen Dingen beschäftigen. Was macht man eigentlich genau in den ersten Tagen bei der Umstellung im Team? Die Literatur gibt da natürlich viele Hinweise, oft sind diese jedoch sehr allgemein gehalten.

Worin sich alle einig sind, ist die Schaffung einer günstige Raumsituation. Für uns ist das vielleicht sogar der erste praktische Schritt mit den Teams, da diese Dinge gelegentlich einige Zeit in Anspruch nehmen können. Natürlich möchten wir, dass Entwickler, Product Owner und Scrum Master in einem Raum zusammen sitzen können, damit wir die Komunikationswege so kurz wie möglich halten, allerdings gibt es noch weitere Einflussfaktoren, die wir berücksichtigen sollten.

So geschieht es häufiger, dass ein Scrum Master für zwei Teams zuständig ist. Vielleicht ist es in diesem Fall sinnvoll, diese Teams in benachbarten Räumen unterzubringen. Ich hoffe sehr, dass bei Ihnen nicht ein Product Owner mit zwei Teams zusammenarbeitet. Dann wären benachbarte Räume vielleicht auch die beste Lösung, aber das Setting an sich ist sehr schwierig und in keiner Weise zu empfehlen.

Beschränken wir uns aber nicht nur auf die drei Scrum-Rollen. Jedes Team hat (sehr oft zumindest) weitere Personen, die es in seiner Nähe braucht. Das können Tester, UX-Designer, Business Analysten oder Admins sein. Auch hier sollten wir darauf achten, der Kommunikation keine Hürden in den Weg zu legen. Diese weiteren Personen müssen nicht zwingend in einem Raum mit der Entwicklermannschaft untergebracht sein, es ist aber für alle Beteiligten sehr angenehm, wenn man einfach nur durch eine Tür gehen und nicht das Gebäude wechseln muss. Je größer die Kommunikationshürde ist, desto weniger spricht man miteinander. Das klingt banal, ist aber ungemein wichtig. Besonders dann, wenn einzelne Kollegen sehr viel telefonieren müssen, dann rate ich sogar dazu, diese von den Entwicklern zu trennen und vielleicht in einem angrenzenden Raum unterzubringen. Das häufige Sprechen kann auf Dauer sehr störend sein.

Ich weiß nicht, was Sie in Ihrem Unternehmen tun müssen, um die Raumsituation aufzulösen, oder ob das überhaupt möglich ist. Unser Ziel ist das Idealbild. Können wir das nicht umsetzen, müssen wir so lange Abstriche machen, bis wir zur Umsetzung kommen. Wir fragen also nicht, was wir bekommen können, wir haben eine komplette Wunschliste, und unser Gegenüber muss uns sagen, was wir davon nicht bekommen können. Das ist ein erheblicher Unterschied.

Während dieses Vorgangs ist für uns auch der Zeitpunkt gekommen, mit den Entwicklern die Frage zu klären, wie wir in Zukunft arbeiten möchten. Stehen Dinge wie Continuous Integration und Development auf dem Plan? Welchen Einfluss hat das auf das weitere Vorgehen? Müssen neue Server angeschafft werden? Für diese Fragen müssen wir alle ins Boot holen. Je kleiner die Gruppe ist, desto einfacher wird es. Mit zwei, drei und vier Entwicklungsteams potenziert sich der Diskussionsbedarf. Viel mehr Personen haben Meinungen, die Bedürfnisse der Teams sind nicht deckungsgleich.

Anstatt mit allen gleichzeitig sprechen zu wollen, was in einer großen Gruppe sowieso nicht funktioniert, ist es immer ein gutes Vorgehen, wenn jedes Team einen oder zwei Repräsentanten schickt. So können wir in kleineren Gruppen diskutieren und das weitere Vorgehen beschließen. Diese Repräsentanten tragen die gewonnenen Erkenntnisse und Beschlüsse in ihre Teams zurück.

Wir befinden uns noch immer in der Vorbereitung. Noch ist der erste Sprint nicht gestartet. Zwar besteht selbstverständlich auch die Möglichkeit, diese Dinge erst nach dem eigentlichen Startschuss anzugehen, aber ich bin eher ein Freund davon, wenn wir uns dann schon auf die (Weiter-)Entwicklung des Produkts konzentrieren können, anstatt uns noch mit organisatorischen Dingen zu beschäftigen. Davon wird es sowieso genug geben. Bemühen wir uns also darum, so viel wie möglich schon im Vorfeld abgearbeitet zu haben, damit wir den eigentlichen Start reibungsloser gestalten können.

Der nächste Punkt auf unserer Liste, und damit schon sehr nah am eigentlichen Startschuss, ist die Frage nach den Sprintlängen und Terminen. In der Literatur werden Sie finden, dass ein Sprint zwischen einer und vier Wochen lang sein kann. Sehr häufig hat man sich auf zwei Wochen verständigt, weil das ein guter Kompromiss zwischen kurzen Intervallen und weniger Meetingoverhead zu sein scheint. Das ist jedoch ein Trugschluss.

Zum einen rate ich bei Projektstart grundsätzlich zu einwöchigen Sprints, da die Unsicherheiten so groß und zahlreich sind, dass sie kaum in zwei Wochen planen können. Lassen Sie sich auch nicht davon täuschen, dass sie wöchentlich Review, Retrospektive und Planning durchführen müssen. Der scheinbare Zeitverlust wird durch das »knackige« sehr fokussierte Vorgehen in einer Woche im allgemeinen mehr als aufgehoben.

Letztendlich entscheidet das Team jedoch selbst. Als Scrum Master machen Sie einen Vorschlag und liefern die Argumente. Dabei wägen Sie ab, was sie sich von kürzeren Intervallen versprechen. Es spricht nichts dagegen, mit einwöchigen Sprints zu starten und nach einiger Zeit auf einen Zwei-Wochen-Intervall zu wechseln. Sie sollten in Ihre Überlegungen auch einfließen lassen, dass sowohl Scrum als auch das Agile Vorgehen für Ihre Kollegen neu sein können. Der kurze Wochenrhythmus ist hilfreich dabei, sich an diese Dinge zu gewöhnen.

Der ganze Themenkomplex »Wie wollen wir vorgehen?« umfasst viele Dinge, die wir (soweit möglich) bereits vor dem Startschuss angehen sollten. Kernpunkt ist dabei unser Backlog, das wir ebenfalls bereits jetzt anlegen und initial füllen. Dazu gehört auch die Frage nach einer »Definition of Done« und einer »Definition of Ready«, also der Frage, wann eine Anforderung abgeschlossen ist, und wann eine Anforderung in das Sprint-Backlog übernommen werden kann.

Zu einer DoD kann z.B. zählen, dass ein Feature getestet und in den Master gemerged wurde, eine DoR kann sich am INVEST-Prinzip orientieren (zu dem ich vielleicht im nächsten Beitrag ein paar Worte verlieren werde.

Für Sie als Scrum Master beginnt jetzt eine sehr intensive Zeit, da Sie sehr wahrscheinlich sowohl den Product Owner als auch das Team intensiv begleiten müssen. Dazu gehört die Beantwortung vieler Fragen, die Vorstellung der Artefakte und Zeremonien und auch die beginnende praktische Arbeit am Backlog. Ich rate Ihnen ganz besonders während dieser Phase zur Unnachgiebigkeit. Die Umstellung der Arbeitsweise ist mit vielen Neuerungen verbunden, die manchmal auch unbequem sein können. Wenn wir jetzt Nachlässigkeiten und Ungenauigkeiten zulassen, werden wir diese nie wieder los. Das kann zu Konflikten führen. Sie werden vielleicht Dinge hören wie »Das haben wir schon immer so gemacht, und es hat gut funktioniert. Ich sehe nicht, warum wir es jetzt anders machen sollten.« Als Scrum Master sollten sie darauf vorbereitet sein, den Sinn der Artefakte, Zeremonien und der sich daraus ergebenen Details gut erklären zu können.

Bitte entschuldigen Sie, dass ich auf einen so wichtigen Punkt wie die initiale Befüllung des Backlogs nicht weiter eingehe. Allein das erfordert viel Arbeit und Vorbereitung. Auch diesem Punkt werde ich einen weiteren Beitrag in naher Zukunft widmen.

Die Frage »Wie wollen wir vorgehen?« hat neben den ganz praktischen Dingen noch eine weitere Ebene, die manchmal sehr viel schwerer zu beantworten ist: Wie weit möchte das Team an der Planung teilhaben? Ich sehe sehr oft Teams, in denen der Product Owner komplett allein entscheidet, was wann getan wird. Das Team entscheidet dann lediglich noch über das Wie und die Menge, die es in einem Sprint schafft. Andere Teams entscheiden auch über Storyschnitt und Priorisierung im Backlog gemeinsam. Wieder andere Teams interpretieren den Product Owner eher als Vordenker und weniger als Entscheider. In einem solchen Setting entscheiden alle gemeinsam über Roadmap und Leistungsumfang des fertigen Produkts.

Dies sollten Sie keinesfalls auf die leichte Schulter nehmen. Wenn das Team sehr viel mehr möchte als es darf, dann führt das irgendwann zu Problemen. Wenn von den Entwicklern mehr verlangt wird als sie zu geben bereit (oder in der Lage sind), dann führt auch das zu großen Problemen. Sprechen Sie dieses Thema offen an, und lassen Sie alle gemeinsam entscheiden, wie die einzelnen Rollen gelebt und wie Entscheidungen getroffen werden.

Wenn das Backlog gefüllt ist, wenn die wichtigsten Fragen beantwortet sind, wenn alle Rahmenbedingungen geschaffen sind, dann steht dem Start nichts mehr im Weg. Legen Sie gemeinsam einen Termin für den ersten Sprint fest, und vermeiden Sie einen »sanften« Start, in dem Sie versuchen, nacheinander einzelne Aspekte einzuführen. Nur in der Gesamtheit ergänzen sich die einzelnen Artefakte und Zeremonien zu einem sinnvollen Ganzen.

Besonders spannend wird für Sie die erste Retrospektive sein. Erwarten Sie nicht, dass Sie vom ersten Tag an alles richtig machen. Die richtige Anwendung von Scrum ist ein andauernder Lernprozess. In den ersten Wochen ist zu erwarten, dass die Dinge noch nicht richtig laufen. Lassen Sie sich davon nicht entmutigen. Wir alle müssen uns erst an neue Dinge gewöhnen.

Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr