13Einführung von Scrum in großen Teams

Es gibt immer wieder Situationen, in denen ein ganzes Unternehmen oder ein sehr großesProjektteam auf Scrum umgestellt werden sollen. Häufig sind diese Teams nicht nur groß,sondern auch noch rund um den Globus verteilt (vgl. Eckstein 2009). Eine solche Ein-führung stellt enorm hohe Anforderungen an Sie und alle an der Veränderung beteiligtenFührungskräfte. Sie müssen die Besonderheiten eines solchen Vorhabens kennen und überalle Bereiche sowie Mitarbeiter koordinieren. Fehler wirken sich direkt mehrfach aus.

13.1 Besonderheiten

Je größer ein Team, desto höher ist auch der Kommunikationsaufwand. Zwei Personenhaben beispielsweise zwei Kommunikationswege: von A nach B und wieder zurück. DreiPersonen benötigen bereits sechs Kommunikationswege: von A nach B, von B zu C undvon A zu C, jeweils mit Rückkanal. Bei 20 Teammitgliedern sind es bereits 420 Kommu-nikationsstränge, bei 100 Personen 10.100. Das ist nicht mehr zu managen. Sie werdenvermutlich schon selbst festgestellt haben, dass eine Gruppe von Menschen ab acht biszehn Personen in Subteams zerfällt. Zwar werden sie offiziell noch als ein Team bezeich-net, de facto wird aber in anderen Gruppierungen gearbeitet. Dieses Zerfallen in Unter-gruppen geschieht chaotisch und meist nach fachlicher Gleichheit ausgerichtet, wenn esnicht gesteuert wird. In Softwareprojekten bedeutet das, dass Entwickler einer Software-schicht gemeinsam arbeiten. Die Datenbankexperten bleiben unter sich, die Serverent-wickler schließen sich zusammenund auch die Benutzeroberflächengurus arbeiten separat.Man versteht sich. Einige Firmen haben sogar ihre Aufbauorganisation nach diesem Sche-ma ausgerichtet, in der Hoffnung, dass sich die Schnittstellen leichter managen lassen, alsdie Gesamtheit der Personen. Leider funktioniert auch das nicht effizient: Selbst eine Un-menge an Besprechungen deckt nicht den benötigten Kommunikationsbedarf. Fehler undMissverständnisse werden nicht verhindert, das böse Erwachen kommt in der Regel erst

105D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_13,© Springer-Verlag Berlin Heidelberg 2013

106 13 Einführung von Scrum in großen Teams

bei der Integration aller Softwarebestandteile. Gegenseitige Schuldzuweisungen dominie-ren dann die Beziehungen, anstatt konstruktiv auf eine Lösung hinzuarbeiten.

Bei großen Teams ist Ihre Hauptaufgabe, die Beziehungen zwischen den Personen sozu gestalten, dass diese effizient miteinander arbeiten können. Eine weitere Schwierigkeitbesteht darin, dass mehr Menschen politische oder andere Interessen an dieser Menge vonPersonen haben, als das bei einem kleinen Team der Fall ist. Der Kreis Ihrer Stakeholderwächst also. Diese wollen alle informiert und überzeugt werden. Außerdem hat natürlichjeder eigene Ziele und Interessen, die es zu befriedigen gilt.

Je größer die Organisation, desto schwerfälliger wird sie in der Regel. Die Mitarbeiterhaben sich in ihrer Komfortzone eingerichtet und fühlen sich dort wohl. Dahermüssen Siebei großen Gruppen auch verstärkt damit rechnen, Leute zu verlieren. Das liegt daran, dassder Wandel hin zu Offenheit und Transparenz sehr schmerzhaft sein kann. Teils, weil derWandel als solcher anstrengend ist. Teils, weil die Unzulänglichkeiten der Beteiligten sehrdeutlich zu Tage treten. In solchen Kontexten wird es auch vorkommen, dass Sie Mitarbei-ter nicht in Ihrem Team haben wollen. Das bezieht sich sowohl auf Entwickler als auch aufFührungskräfte, die sich nicht mit den neuen Werten identifizieren. Sie müssen zunächstversuchen, durch die aktive Einbeziehung in die Arbeit der Führungskoalition diese Men-schen für Ihr Vorhaben zu gewinnen. Legen Sie ihnen die Dringlichkeit und die Vorteiledes neuen Ansatzes ans Herz. Bitten Sie um Unterstützung. Helfen Sie den Kollegen dabei,dass sie sich mit den neuen Gegebenheiten zurechtfinden. Wenn all das nichts hilft, müs-sen Sie die Person aus demWandel der Gruppe ausschließen. Wenn das nicht möglich ist,sollte die Person sich einen anderen Arbeitgeber suchen – beim aktuellen wird sie sowiesonicht glücklich, da der Wandel rasch voranschreiten wird.

Eine weitere Besonderheit der Einführung von Scrum in großen Teams ist, dass mitsteigender Größe die Abhängigkeit von globalen Unternehmensprozessen steigt. WährendSie ein Team von sieben Personen noch an den Standardprozessen vorbei manövrierenkönnen, geht das mit hundert Entwicklern nicht mehr. Im Gegenteil: Wahrscheinlich sindSie sogar froh, auf ein paar grundlegende Prozesse zurückgreifen zu können. Leider nichtauf alle: Es gibt immer Abläufe, die ungeeignet für agile Vorgehensweisen sind. Sie könnengemeinsam mit der Führungskoalition versuchen, diese unpassenden Prozesse umzuge-stalten. Wahrscheinlicher ist aber, dass Sie zunächst damit leben und dann im gelebtenProzess beweisen müssen, wo Verbesserungsbedarf besteht. So verschenken Sie Produkti-vität (und damit Geld), aber das ist häufig notwendig. Um Organisationsentwicklung miteiner Analogie aus der Seefahrt zu beschreiben: Einen Tanker können Sie nicht so einfachstoppen und auf offener See umbauen. Sie können kleine Verbesserungen durchführen undihn mit einem Schlepper in eine andere Richtung ziehen, aber all das braucht seine Zeit.Bringen Sie es hingegen in ein Trockendock, verdient das Schiff kein Geld für seinen Ree-der. Das Gleiche gilt für Ihr Unternehmen: Wenn Sie es lahm legen, kommt kein Geld indie Kassen. Damit fehlt auch die Grundlage für Ihr Gehalt . . .

13.2 Direkter Vergleich einer kleinen und einer großen Einführung 107

13.2 Direkter Vergleich einer kleinen und einer großen Einführung

In den vorigen Kapiteln haben Sie schon viel darüber gelernt, wie Sie einenWandelprozessanstoßen und steuern können. Das Gleiche gilt natürlich auch bei großen Teams. Verglei-chen wir die Einführung von Scrum in einem überschaubaren Kontext (sieben Personen)mit einer Einführung in einem großen Kontext (dreitausend Personen). Nennen wir dieseFirmen „Small GmbH“ und „Big AG“.

In der Small GmbH hat der Geschäftsführer die Idee, Scrum einzuführen. Grund ist,dass der Wettbewerb schneller und günstiger liefert und das langfristig zum Problem wird(Dringlichkeit). Er schnappt sich seinen Entwicklungsleiter und den Produktmanager undbespricht die Handlungsalternativen. Heraus kommt ein Plan, wie Scrum eingeführt wer-den soll (Vision und Strategie). Zu dritt (Führungskoalition) gehen sie zum Entwicklungs-team und erklären die Situation (Kommunikation). Die Entwickler werden geschult, einexterner Coach wird an Bord geholt (Mitarbeiter befähigen). Das Ziel ist, in den kom-menden drei Monaten ein Release auszuliefern, was bislang immer ein Jahr gedauert hat(schnelle Erfolge erzielen). Das gelingt, und begeistert werden auch Vertrieb und Produkt-management nach Scrum organisiert (Erfolge konsolidieren und weitere Veränderungeneinleiten). Die Personalerin des Unternehmens entwickelt ein Konzept, das die agilenWer-te bei den Mitarbeitern und neuen Bewerbern prüft. Einstellungen und Beförderungenwerden davon abhängig gemacht (neue Ansätze in der Kultur verankern).

Sie sehen, dass in kleinen Kontexten die Einführung von Scrum relativ einfach ist. Zwarreicht es nicht, einfach loszulegen. Jedoch sind Sie mit den acht Schritten für erfolgreichenWandel relativ schnell in der Erfolgszone. Bei der Big AG ist das nicht so einfach. Im Fol-genden gehe ich von den gleichen Voraussetzungen wie bei der Small GmbH aus. Das istzwar unrealistisch, macht die Beispiele aber vergleichbar.

Der Geschäftsführer der Big AG hat die Idee, Scrum einzuführen. Grund ist, dass derWettbewerb schneller und günstiger liefert und das langfristig zum Problem wird (Dring-lichkeit). Er schnappt sich seinen Entwicklungsleiter und den Chef des Produktmanage-ments und bespricht die Handlungsalternativen. Gemeinsam wird das Problem im Ge-schäftsleitungsausschuss diskutiert. Ein Zwei-Tages-Workshop zur Analyse des Problemsund Erstellung einer Vision wird durchgeführt (Vision). Es werden einige Personen be-stimmt, die sich auch weiter darum kümmern sollen (Führungskoalition). Diese erarbei-ten ein Konzept unter Einbeziehung eines externen Experten und stellen dieses im Ge-schäftsleitungsausschuss vor. Mit ein paar Änderungen wird es akzeptiert (Strategie). IneinerMitarbeiterversammlung werdenDringlichkeit und Strategie kommuniziert. Danachkümmert sich die interne Kommunikationsabteilung um die weitere Informationsweiter-gabe (Kommunikation). Gemeinsam mit den entsprechenden Führungskräften wird einPilotprojekt ausgewählt, das zuerst auf Scrumumgestellt werden soll. AnschließendwerdenMitarbeiter bereitgestellt, die an diesem Projekt arbeiten sollen. Die bereitgestellten Mit-arbeiter erhalten eine Schulung, ein externer Coach wird einbezogen (Mitarbeiter befähi-gen). Für alle nicht direkt beteiligten Mitarbeiter gibt es Informationsveranstaltungen undCrashkurse in Scrum. Das Pilotprojekt wird über eine Dauer von sechs Monaten durch-

108 13 Einführung von Scrum in großen Teams

geführt. Zwar ist dieses erfolgreich (schnelle Erfolge erzielen), doch eine große Anzahlsystemischer Probleme ist aufgefallen. Diese werden von der Führungskoalition aufge-arbeitet und im Geschäftsleitungsausschuss diskutiert. Punktuell werden die gefundenenProbleme gelöst (weitere Veränderungen einleiten). Zur Validierung wird ein weiteres Pi-lotprojekt gestartet. Dieses bestätigt die ersten Beobachtungen. Weitere Veränderungenwerden genehmigt. Jede der Veränderungen muss aufwändig an alle Mitarbeiter kommu-niziert werden. Auch sind Schulungen und Workshops notwendig, um alle Menschen aufdemWeg desWandelsmitzunehmen. Schließlich wird nach zwei Jahren entschieden, einenStandardprozess für Scrumprojekte aufzusetzen. Jedes Projekt soll von nun an die Freiheithaben, zwischen klassischen und agilen Ansätzen zu wählen. Schulungen für Mitarbei-ter werden in das reguläre Weiterbildungsprogramm des Unternehmens aufgenommen.Es werden Statistiken über die Erfolgs- und Zufriedenheitsraten der einzelnen Projektegeführt (virtuelles Scrum Studio). Nach weiteren drei Jahren wird schließlich entschie-den, nur noch in Ausnahmefällen die klassischen Prozesse zuzulassen. Diese Ausnahmenwerden wohl definiert und kommuniziert. Halbjährlich finden Workshops statt, in denendie agilen Werte erarbeitet und gelehrt werden. In Stellenausschreibungen wird ein Satzaufgenommen, der die Bewerber darauf aufmerksammacht, dass Transparenz und Offen-heit Grundwerte des Unternehmens sind. In Assessment-Centern wird das abgeprüft. Indie jährliche Mitarbeiterbeurteilung1 werden diese Kriterien aufgenommen, die dann vonden jeweiligen Vorgesetzten bewertet werden müssen. Im Rahmen eines jährlichen 360°-Feedbacks werden diese Kriterien auch für die Führungskräfte überprüft. Beförderungenfinden nur bei guten Bewertungen statt (Ansätze in der Kultur verankern).

Dieses Beispiel ist stark vereinfacht. In der Praxis treffen Sie auf wesentlich mehr Pro-bleme und müssen wesentlich mehr für die Kommunikation tun. Insbesondere die Ein-beziehung der Mitarbeiter in den Wandel benötigt wesentlich mehr Aufwand. Trotzdemzeigt schon dieses kurze Beispiel, dass in großen Organisationen die Veränderung mehr-stufig erfolgt und schwieriger ist, als in kleinen Kontexten. Außerdem wird deutlich, dassunabhängig von der Größe derWandelbestrebung immer die gleichen Schritte nötig sind –wenn auch in unterschiedlicher Ausprägung. Die Fallstudie in diesem Buch geht etwas ge-nauer auf das ein, was getan werden muss, um Scrum nachhaltig einzuführen.

13.3 Koordination

Wenn Sie einen großen Bereich auf Scrum umstellen, ist Ihre schwierigste Aufgabe dieKoordination. Neben dem Wandel selbst, von dem das ganze Buch handelt, geht es dabeiauch um die Abstimmung der verschiedenen Gruppen untereinander.

Trennen Sie Ihre Projekte nach Produkten auf. Wichtig ist, dass an diesen Produktenmöglichst unabhängig voneinander entwickelt werden kann und trotzdem ein verkaufba-

1 Ein wirklich agiles Unternehmen hat keine jährlichen Beurteilungsgespräche mehr. Passender istin agilen Kontexten kurzfristiges Feedback, am besten täglich.

13.3 Koordination 109

rer Nutzen für das Unternehmen entsteht. Ein Framework-Team, ein Server-Team und einGUI-Team sind eine schlechte Alternative, weil das Unternehmen erst im Zusammenspieldieser Produkte Geld verdient. Teilen Sie Ihre Entwickler besser in Teams auf, die jedes fürsich alle benötigten Fähigkeiten vereinen. Kein Team darf auf ein anderes angewiesen sein,um liefern zu können. Um bei dem obigen Beispiel zu bleiben, müssten also Framework-,Server- und GUI-Experten in jedem Team vertreten sein. Die Größe sollte so gewählt wer-den, dass die Entwickler einerseits problemlos arbeiten können, andererseits aber auchnicht in Subteams zerfallen. Das ist bei einer Größe von drei bis neun2 Personen gegeben.ScrumMaster undProductOwner kommennoch dazu. Bis zu einerGröße von drei Scrum-Teams sind normalerweise keine besonderen Maßnahmen notwendig. Die Teams redenvon sich aus miteinander. Auch sind die Abhängigkeiten nicht so groß, dass man sich aufSchritt und Tritt gegenseitig behindert. Sollten Sie mehr Teams haben, wird es spannend.Wenn Sie es geschafft haben, voneinander unabhängige Produkte zu definieren, sollten Siejedes Produkt für sich betrachten. Da die verschiedenen Produkte sich nicht gegenseitigbeeinflussen, ist auch nur ein geringer Abstimmungsbedarf vorhanden. Ist Ihnen dieseTrennung jedoch nicht gelungen, haben Sie also de facto nur ein einziges großes Produkt,so ist der Abstimmungsbedarf immens. Je drei bis fünf Teams benötigen Sie ein täglichesAbstimmungsmeeting, das „Scrum of Scrums“. In dieser Runde besprechen Teamvertre-ter, was sie bis zum kommenden Tag planen, in welchen Codeteilen gearbeitet wird undwie gemeinsame Probleme gelöst werden sollen. Haben Sie mehr als fünf Teams, müssenSie darüber nachdenken, das Scrum of Scrums zu vergrößern oder ein „Scrum of Scrumof Scrums“ einzuführen. Die Vergrößerung funktioniert nur, wenn Ihre Mitarbeiter dis-zipliniert und erfahren sind, also Code und Prozess gut kennen. Das Scrum of Scrum ofScrums ist eine Abstimmungsrunde, in der je ein Vertreter aus jedem Scrum of Scrumsberichtet, was die Essenz aus den jeweiligen Scrum of Scrums war. Entscheidungen wer-den hier meist nicht getroffen, aber für einen optimalen Informationsfluss zurück in dieTeams muss gesorgt werden. Dieser Overhead3 an Besprechungen ist leider notwendig, daansonsten Fehlkommunikation zu Problemen führt, die in der Regel zu Bugs in der Soft-ware und unzureichende Arbeitsfähigkeit in den Teams zur Folge hat. Je mehr Teams Siehaben, desto größer wird Ihr Overhead. Die dringende Empfehlung lautet, nicht mit mehrals drei bis fünf Teams an einem Produkt zu arbeiten. Investieren Sie Zeit in die TrennungIhrer Produkte, damit die Teams unabhängig voneinander arbeiten können. Der Produk-tivitätsgewinn mit jedem zusätzlichen Team ist bei großen Projekten kleiner als bei derHinzunahme des vorherigen Teams, bis schließlich die Kosten höher werden als der Nut-zen. Im Zweifel haben Sie unterm Strich eine höhere Produktivität, wenn Sie die Anzahl

2 Je nachAufgabe und spezifischer Situation kann Ihr Team auch schon ab sieben Personen zerfallen.Probieren Sie es aus und beziehen Sie Ihre Entwickler mit in die Fragestellung ein.3 Mit „Overhead“ bezeichnet man Unkosten für Verwaltung oder andereThemen, die nichts mit dereigentlichen Entwicklung zu tun haben. An sich sollte jedes Unternehmen bestrebt sein, diese Kostenzu minimieren.

110 13 Einführung von Scrum in großen Teams

der an diesem Produkt beteiligten Entwickler reduzieren. Lassen Sie die übrigen Kollegenbesser an einem anderen Produkt arbeiten.

Neben Ihren Entwicklern müssen sich auch Ihre ScrumMaster und Product Owner ab-stimmen. Bei einem einzelnen Produkt sollten Sie auch nur einen Product Owner haben.Dieser wird in großen Projekten aber überfordert sein und Unterstützung benötigen. Häu-fig wird dabei auf Proxy Product Owner4 zurückgegriffen. Alternativ kann es auch einenChief Product Owner geben, der mit den normalen Product Ownern zusammenarbeitet.Bei einem großen monolithischen Produkt wird dies aber nicht funktionieren, da den Pro-duct Ownern dann jeder Entscheidungsspielraum genommen wird und sie im Endeffektdoch nur als Proxies fungieren. Egal welches Modell auf Sie zutrifft, Ihre Product Ownermüssen täglich ihre Informationen zusammentragen, damit der Produktfortschritt trans-parent wird und gesteuert werden kann.Das funktioniert analogwie zumScrum of Scrumsund nennt sich Scrumof ProductOwners (Scrumof ScrumMasters für die ScrumMaster).Darüber hinaus kann es nötig werden, dass bestimmte Spezialisten aus den Teams zusätzli-chen Abstimmungsbedarf haben. Häufig ist das bei Architekten und GUI-Entwicklern derFall. Diese kommen dann in fachspezifischen Runden zusammen, um sich auszutauschen.Das geschieht nicht immer täglich und nicht immer während der gesamten Projektlaufzeit.Im Endeffekt müssen die Entwicklungsteams selbst feststellen, welchen Abstimmungsbe-darf sie haben und diesen angemessen decken. Denken Sie aber daran, einen ScrumMasterzur Moderation bereitzustellen – das verkürzt die Besprechungszeiten erheblich.

Zu Beginn einer Scrumeinführung kann es sinnvoll sein, allen Teams den bis ins Detailgleichen Prozess überzustülpen. Das schließt Tools undDokumentemit ein. Auf dieseWei-se lernen alle, auf die gleicheWeise vorzugehen. Sind Ihre Teams bereits erfahren, sieht dasanders aus. Hier ist es ganz normal, dass jedes Team leicht abgewandelte Tools und Pro-zesse einsetzt. Es ist auch normal, dass nicht alle Teams Scrum machen. Wartungsteamsarbeiten zum Beispiel lieber mit Kanban, einfache Projekte lassen sich auch effektiv mitklassischen Ansätzen lösen. Wichtig ist jedoch, dass die Grundregeln von Scrum von je-dem Team eingehalten werden, das Scrum einsetzen möchte. Sie sollten auch undefinierteProzesse aus Ihrem Portfolio verbannen. Sonst baut sich jeder Projektmanager seinen eige-nen Prozess, der möglicherweise für ihn unangenehme Transparenz vermeidet. Seien Sieversichert, dass Scrum genug Spielraum für jeden kreativen Kopf beinhaltet. Die Eckpfei-ler5 von Scrum sind aber unverrückbar.

4 Ein Proxy Product Owner ist ein Informationsrelais des Product Owners. Er verfügt nicht über Ent-scheidungsbefugnisseund leitet nur Informationenweiter. Dabei gehen auch Informationen verlorenoder werden verfälscht. Kein erstrebenswerter Zustand.5 Der Scrumguide definiert die Spielregeln von Scrum. Auf diesen sechzehn Seiten stehen die Eck-pfeiler. www.scrum.org/scrumguides.

13.4 Zeitpunkt 111

13.4 Zeitpunkt

Wann ist der richtige Zeitpunkt für eine Scrumeinführung im Großen? Diese Frage isteinfach zu beantworten: wenn Sie Ihre Hausaufgaben hinsichtlich des Wandelprozessesgemacht haben und bereits über fundierte Erfahrungen mit Scrum verfügen.

Die Hausaufgaben haben Sie dann gemacht, wenn Dringlichkeit, Vision und Strate-gie klar sind und ständig kommuniziert werden. Eine Führungskoalition muss sich umden Wandel kümmern. Sie müssen sich im Klaren darüber sein, wie Sie Ihre Mitarbeiterbefähigen wollen, den Wandel mitzutragen und selbst Teil eines Scrumprojektes zu wer-den. Erste Erfolge im Sinne von abgeschlossenen Pilotprojekten müssen allen Mitarbeiternzweifelsfrei beweisen, dass Scrum gut für sie ist. In diesen Piloten können Sie sich auch IhreExpertise in Scrum erarbeiten.

Wenn auch nur eines dieser Kriterien nicht erfüllt ist, sollten Sie es erst im Kleinenversuchen. Die Wahrscheinlichkeit zu scheitern ist sonst sehr hoch. Besonders tückisch istdabei, dass Sie vermutlich nicht sofort scheitern, sondern erst nach ein bis zwei Jahren –davor spielen Ihre Mitarbeiter das Spiel auch dann mit, wenn sie nicht davon überzeugtsind.

13.5 Das sollten Sie sichmerken

Die Einführung von Scrum in großen Kontexten unterscheidet sich im Ablauf nicht er-heblich von der Einführung in kleinen Projekten. Allerdings sind der Aufwand und diegenaue Ausgestaltung der einzelnen Schritte fundamental verschieden. Haben Sie es miteiner großen Anzahl Personen zu tun, die nach Scrum organisiert werden sollen, so solltenSie diese Punkte bedenken:

1. Große Gruppen zerfallen in Subteams. Meist geschieht das, sobald die Gruppe siebenbis neun Personen übersteigt.

2. Je größer Ihr Kontext der Scrumeinführung ist, desto mehr wächst auch Ihr Kreis derStakeholder.

3. Gerade in großen Unternehmen werden Leute gehen. Das liegt an den Schmerzendurch das Verlassen der Komfortzone und der durch Scrum erzeugten Transparenz.

4. Je mehrMenschen betroffen sind, desto größer ist ihre Abhängigkeit von globalen Un-ternehmensprozessen.

5. Trennen Sie Ihre Projekte nach Produkten. So reduzieren Sie die Anzahl der Personen,die sich bei der Arbeit an einem Produkt im Wege stehen.

6. Jedes Teammuss für sich allein arbeitsfähig sein. Das schließt aus, dass Sie Ihre Teamsnur an einzelnen Schichten der Software arbeiten lassen.

7. Ein Entwicklungsteam besteht aus drei bis neun Personen. ScrumMaster und ProductOwner kommen noch hinzu und machen das Scrum-Team komplett.

112 13 Einführung von Scrum in großen Teams

8. Sollten Sie drei Teams oder weniger Ihr Eigen nennen, brauchen Sie keine besonderenMaßnahmen zur Koordination.

9. Je mehr Teams Sie haben, desto mehr Overhead ist notwendig.10. Nutzen Sie das Scrum of Scrums zur Koordination mehrerer Teams. Analoge Kon-

strukte funktionieren für sehr viele Teams, die ScrumMaster oder die Product Owner.11. Nutzen Sie am Anfang in allen Anfängerteams den gleichen Prozess. Stellen Sie es er-

fahrenen Teams frei, ihren eigenen Prozess zu wählen. Achten Sie jedoch darauf, dassdie Grundregeln von Scrum eingehalten werden, sofern das Team Scrum einsetzenmöchte.

12. Führen Sie Scrum nur dann für viele Teams ein, wenn Sie Ihre Hausaufgaben hinsicht-lich des Wandelprozesses gemacht haben und bereits über fundierte Erfahrungen mitScrum verfügen.

Literatur

Eckstein J (2009) Agil mit verteilten Teams. dpunkt.verlag, HeidelbergSchwaber K, Sutherland J (Hrsg) (2011) Scrumguide. www.scrum.org/scrumguides. Zugegriffen:25.11.2012