Scrum: Agiles Pro­jekt­ma­nage­ment – modern & flexibel

Wenn Teams heute ein Projekt anfangen, starten sie nicht einfach unbedacht mit der Arbeit. Denn ins­be­son­de­re größere Aufträge benötigen ein funk­tio­nie­ren­des Projekt- oder Pro­dukt­ma­nage­ment. Agiles Vorgehen ist heut­zu­ta­ge in vielen Un­ter­neh­men gang und gäbe. Der Fokus liegt dabei auf flexiblen Ar­beits­wei­sen, in­kre­men­tel­len Ent­wick­lun­gen und trans­pa­ren­ten Vorgängen. Im Dunst­kreis des agilen Pro­jekt­ma­nage­ments begegnet einem immer häufiger auch der Begriff „Scrum“. Ur­sprüng­lich für die Software-Ent­wick­lung gedacht, ist das Modell in­zwi­schen auch in vielen anderen Bereichen beliebt. Was genau sich hinter dem Buzzword verbirgt, erklären wir Ihnen in diesem Artikel.

Die Ge­schich­te von Scrum geht bis in die 1980er-Jahre zurück – in seiner heutigen Form ist es aber erst seit 1995 in Umlauf. In dem genannten Jahr haben Ken Schwaber und Jeff Su­t­her­land, die beide ur­sprüng­lich getrennt von­ein­an­der einander ähnelnde Modelle in ihren Un­ter­neh­men ein­ge­setzt hatten, ein ge­mein­sa­mes Paper her­aus­ge­bracht. Dabei ging es ihnen darum, Arbeit pro­duk­ti­ver zu gestalten und gleich­zei­tig möglichst wenige Re­gu­la­ri­en ein­zu­füh­ren, die die Pro­duk­ti­vi­tät ein­schrän­ken könnten.

Um das zu er­mög­li­chen, legt Scrum ein Rah­men­werk (Framework) fest, das man auf ver­schie­de­ne Si­tua­tio­nen anwenden kann. Das geschieht mit dem Zweck, sowohl die Ar­beits­wei­se als auch das Produkt fort­wäh­rend zu ver­bes­sern. Teil des Frame­works sind daher fest­ge­leg­te Rollen, Er­eig­nis­se, Artefakte und Regeln. Innerhalb dieser Be­gren­zun­gen sollen Scrum-Teams möglichst effizient Er­geb­nis­se erreichen, die dem Kunden das best­mög­li­che Produkt bescheren. Kunden be­zie­hungs­wei­se Auf­trag­ge­ber und Nutzer nehmen daher bei Scrum eine wichtige Position ein: An ihren An­for­de­run­gen ori­en­tiert sich die Ent­wick­lung.

Hin­sicht­lich der Arbeit mit Scrum spielen zwei Schlüs­sel­be­grif­fe immer wieder eine Rolle:

• Iterativ: Bei Scrum wird ein Produkt laufend wei­ter­ent­wi­ckelt. Die Arbeit be­schreibt somit einen Zirkel, der von der Planung über Ent­wick­lung und Testing zur Eva­lua­ti­on kommt und von da aus wieder in die Pla­nungs­pha­se übergeht. Somit befasst sich Scrum nicht nur mit der initialen Her­stel­lung, sondern auch mit künftigen Wei­ter­ent­wick­lun­gen.
• In­kre­men­tell: Scrum basiert auf der Vor­stel­lung, dass ein Produkt schritt­wei­se erstellt wird. Diese Schritte stellen Zwi­schen­zie­le dar. Damit wendet man sich von einer Ar­beits­wei­se ab, die auf ein einziges großes Ziel am Ende der Ent­wick­lung abzielt. Um sich größere Fle­xi­bi­li­tät zu erhalten, un­ter­teilt man große Projekte in mehrere kleinere.

Kom­bi­niert man beides, bedeutet ein iterativ-in­kre­men­tel­les Vorgehen also, dass es sich bei der Ent­wick­lung um einen schritt­wei­sen und an­dau­ern­den Prozess handelt. Damit wird zum einen der Prozess an sich sehr viel trans­pa­ren­ter, da häufiger Über­prü­fun­gen der Arbeit vor­ge­se­hen sind (re­sul­tie­rend aus der klein­schrit­ti­ge­ren Vor­ge­hens­wei­se), und zum anderen ver­bes­sert man auch die Qualität des Produkts, da dessen Funk­tio­na­li­tät fort­wäh­rend geprüft wird.

Scrum entstammt ur­sprüng­lich der agilen Software-Ent­wick­lung. Dort setzt man auf Agile Scrum, um kon­ti­nu­ier­lich die Arbeit an Pro­gram­men zu ver­bes­sern. Aber auch bei anderen Produkten – zum Beispiel bei der Her­stel­lung von Hardware – ist Scrum ein wirksames Modell. Doch am Ende eines Scrum-Projektes muss nicht zwingend ein Produkt im ei­gent­li­chen Sinne stehen: Jedes er­geb­nis­ori­en­tier­te Projekt kann von Scrum pro­fi­tie­ren. So wird das Modell zum Beispiel auch bei der Or­ga­ni­sa­ti­on von Mar­ke­ting­teams oder Ver­wal­tungs­or­ga­nen sowie beim Ent­wi­ckeln von Dienst­leis­tun­gen ein­ge­setzt.

Aus­gangs­punkt von Scrum sind aber immer kleine Teams – wobei „klein“ ein relativer Begriff ist: Für große Ar­beits­grup­pen eignet sich das flexible Modell al­ler­dings weniger. Häufig ist es aber möglich, eine große Gruppe in mehrere kleinere Teams zu un­ter­tei­len. Scrum eignet sich nämlich auch bestens dafür, Teams un­ter­ein­an­der zu vernetzen. Teamwork hat in diesem Modell nämlich einen hohen Stel­len­wert: Innerhalb eines Scrum-Teams sollen sich die einzelnen Mit­glie­der mit ihren un­ter­schied­li­chen Fä­hig­kei­ten ge­gen­sei­tig ergänzen.

Scrum versteht sich weniger als feste Methode oder konkrete Ar­beits­tech­nik, sondern ist vielmehr nur ein Rah­men­werk, das den Teams feste Be­zugs­punk­te für ihre Arbeit bietet. In diesem Framework gibt es bestimmte Rollen, Er­eig­nis­se und Artefakte.

Innerhalb eines Scrum-Teams gibt es drei feste Rollen: das Team, den Product Owner und den Scrum Master. Beim Team handelt es sich um die ei­gent­li­chen Ent­wick­ler des Produktes. Die Gruppe ist so auf­ge­stellt, dass sie sich selbst or­ga­ni­sie­ren kann. Sie legt dabei auch selbst fest, wie sie zu einem ver­ein­bar­ten Ziel gelangt. Bei Scrum gibt es innerhalb des Teams zudem keine Hier­ar­chien mehr. Zwar ist es selbst­ver­ständ­lich, dass jeder Mit­ar­bei­ter seinen eigenen Auf­ga­ben­be­reich hat, beim ab­schlie­ßen­den Review müssen aber alle gemeinsam Re­chen­schaft über das Produkt ablegen. Die Größe des Teams ist nicht konkret fest­ge­legt: Man sollte so auf­ge­stellt sein, dass man schnell und flexibel agieren kann, aber auch leis­tungs­fä­hig bleibt. Also nicht zu groß und nicht zu klein. Schwaber und Su­t­her­land schlagen zwischen 3 und 9 Mit­glie­der pro Team vor. Bei Scrum ist der Product Owner für die Qualität des Produkts und der Arbeit zuständig. Somit nimmt diese Person eine Kon­troll­funk­ti­on ein. Product Owner or­ga­ni­sie­ren den Product Backlog, eine Liste, die die An­for­de­run­gen an das Projekt festlegt (mehr zum Product Backlog erfahren Sie unter dem Punkt Scrum-Artefakte.) Zu seinen Aufgaben gehört auch, die Ziele in eine sinnvolle Rei­hen­fol­ge zu bringen und diese ver­ständ­lich zu do­ku­men­tie­ren. Der Product Owner ist eine au­to­ri­tä­re Rolle: Zwar legen die Teams selbst fest, wie sie die im Backlog for­mu­lier­ten Ziele erreichen, aber die Fest­le­gung der Ziele liegt im Ermessen des Product Owners. Und dies darf auch von niemandem an­ge­zwei­felt werden: Um maximale Pro­duk­ti­vi­tät zu ge­währ­leis­ten, muss das Team den Ent­schei­dun­gen des Product Owners vertrauen. Dennoch kann man nicht von einer Füh­rungs­per­son sprechen: Product Owner und das Team haben un­ter­schied­li­che Auf­ga­ben­fel­der und sind in diesen maß­geb­lich. So wie das Team nicht den Backlog in Frage zu stellen hat, mischt sich der Product Owner auch nicht in den Ent­wick­lungs­pro­zess ein. Der Scrum Master fungiert im Vergleich zu den anderen beiden Rollen als Art Mediator. Scrum Master sind dafür ver­ant­wort­lich, Scrum in den Ar­beits­ab­lauf zu in­te­grie­ren und durch­zu­set­zen. Das bedeutet auch, dass diese Rolle für die Or­ga­ni­sa­ti­on der Scrum-Er­eig­nis­se zuständig ist: Sie legt somit Meetings fest und moderiert diese auch. Darüber hinaus steht der Scrum Master sowohl dem Team als auch dem Product Owner helfend zur Seite. Dabei greift er aber nie in den ei­gent­li­chen Ent­wick­lungs­pro­zess ein. Seine Funktion besteht lediglich darin, den an der Pro­duk­ti­on be­tei­lig­ten Mit­ar­bei­tern die Ar­beits­ab­läu­fe zu ver­ein­fa­chen und somit Pro­duk­ti­vi­tät und Krea­ti­vi­tät zu steigern. Als An­sprech­part­ner sorgt der Scrum Master dafür, dass alle Be­tei­lig­ten die Abläufe richtig verstehen: Er gibt Tipps zum Erstellen von Backlogs oder zur Or­ga­ni­sa­ti­on des Teams und versucht allgemein, Hin­der­nis­se aus dem Weg zu räumen. Der Scrum Master hat also unter anderem die Funktion eines Coachs. Für diese Rolle ist es ent­schei­dend, Scrum ge­nau­es­tens zu kennen. Deshalb kann man sich auch als Scrum Master zer­ti­fi­zie­ren lassen. In­zwi­schen gibt es mehrere Zer­ti­fi­zie­rungs­stel­len, die auch ent­spre­chen­de Trainings anbieten. Sowohl die Scrum Alliance als auch Scrum.org wurden von Ken Schwaber gegründet und bieten die Zer­ti­fi­ka­te Certified Scrum Master bzw. Pro­fes­sio­nal Scrum Master an.

Or­ga­ni­siert man Ar­beits­ab­läu­fe nach dem Prinzip von Scrum, gibt es bestimmte Er­eig­nis­se, die re­gel­mä­ßig ein­tref­fen. Da es sich bei Scrum um einen ite­ra­ti­ven Prozess handelt, vollzieht sich die Arbeit in wie­der­ho­len­den Zyklen: Jedes Ereignis findet bei jeder Wie­der­ho­lung erneut statt. Die Häu­fig­keit der Scrum-Er­eig­nis­se bewirkt, dass au­ßer­plan­mä­ßi­ge Meetings selten bis gar nicht statt­fin­den. Alle Er­eig­nis­se haben zudem einen festen Zeit­rah­men.

Den Zyklus selbst nennt man Sprint. Dieser be­schreibt den Zeitraum einer Ent­wick­lungs­pha­se. Am Ende eines Sprints wird vom Ent­wick­ler­team ein fertiges Pro­dukt­in­kre­ment aus­ge­lie­fert. Das heißt, die Ent­wick­lung muss zu einem Produkt geführt haben, das po­ten­zi­ell aus­ge­lie­fert werden kann. Somit hat jeder Sprint eine konkrete Mission, die man am Ende als „fertig“ kenn­zeich­net. Der Zeit­rah­men für einen Sprint wird im Vorfeld fest­ge­legt, sollte aber nicht mehr als 30 Tage betragen. Bei der Fest­le­gung der Zeit­span­ne sollte man folgende Faktoren be­rück­sich­ti­gen: Ein Sprint darf weder ver­län­gert noch verkürzt werden, und auch die kommenden Sprints des Projekts sollten die gleiche Dauer haben.

Sprints werden bewusst kurz gehalten, damit man bei der For­mu­lie­rung der Ziele nicht zu kom­pli­ziert denkt. Die kurze Dauer sorgt auch dafür, dass min­des­tens einmal im Monat eine Über­prü­fung der Ent­wick­lung statt­fin­det. Nur in wenigen Aus­nah­me­fäl­len darf ein Product Owner (und auch nur dieser) einen Sprint abbrechen. Möglich ist der Abbruch zum Beispiel, wenn das Ziel nicht mehr erreicht werden muss, weil das Un­ter­neh­men in­zwi­schen eine andere Ziel­set­zung hat. Grund­sätz­lich sollten Sprints aber nicht ab­ge­bro­chen werden, weil dies die Pro­duk­ti­vi­tät stark mindert.

Ein Sprint beginnt mit dem Sprint Planning: An diesem Ereignis sind alle Rollen des Scrum-Teams beteiligt. Während eines maximal acht Stunden an­dau­ern­den Meetings be­spre­chen die Be­tei­lig­ten das an­ste­hen­de Pro­dukt­in­kre­ment: Was soll im Inkrement enthalten sein und wie möchte man das Ergebnis erreichen? Aus­gangs­punkt für die Planung ist der Product Backlog. Das Ent­wick­ler­team und der Product Owner ver­stän­di­gen sich gemeinsam darauf, welche Ziele im kommenden Monat erreicht werden können. Daraufhin bespricht das Ent­wick­ler­team, wie die Aufgaben be­wäl­ti­gen werden soll. Am Ende des Meetings sollten die Ent­wick­ler ihren Plan mit dem Product Owner und dem Scrum Master be­spre­chen können.

Innerhalb des Sprints findet jeden Tag ein Daily Scrum statt – immer zum gleichen Zeitpunkt und am gleichen Ort, denn das spart Or­ga­ni­sa­ti­ons­auf­wand. Bei dem 15-minütigen Meeting bespricht das Ent­wick­ler­team, welche Aufgaben an diesem Tag anstehen und was man am ver­gan­ge­nen Tag erreicht hat. Auch die Ent­wick­ler be­ur­tei­len den all­ge­mei­nen Fort­schritt des Projekts: Wie weit ist man bei der Ab­ar­bei­tung der Backlog-Einträge vor­an­ge­kom­men? Der tägliche Abgleich stellt sicher, dass alle Be­tei­lig­ten die Ziele im Blick behalten, wodurch letztlich auch die Pro­duk­ti­vi­tät ge­stei­gert wird.

Der Scrum Master sorgt zwar dafür, dass ein Daily Scrum statt­fin­det, den Ablauf des Meetings machen aber die Ent­wick­ler un­ter­ein­an­der aus. Sie legen fest, welche Themen be­spro­chen werden. Solange es in­halt­lich um die Er­rei­chung des Sprint-Ziels geht und die 15 Minuten nicht über­schrit­ten werden, mischt sich der Scrum Master nicht ein. Er achtet auch darauf, dass andere Personen, die dem Daily Scrum beiwohnen, die Ent­wick­ler nicht bei ihrer Arbeit stören.

Wenn ein Sprint zu Ende ist, folgt ein Sprint-Review: Dabei wird das Pro­dukt­in­kre­ment überprüft. Gemeinsam mit Personen, die nicht Teil des Scrum-Teams sind, aber dennoch ein wichtiges Interesse an dem Produkt haben, wie zum Beispiel Un­ter­neh­mens­ei­gen­tü­mer oder Kunden (bei Scrum gesammelt als Stake­hol­der be­zeich­net), werden die Er­geb­nis­se aus­ge­wer­tet. Dabei spricht man auch über den Ar­beits­pro­zess als solchen, geht auf Probleme bei der Ent­wick­lung ein und tauscht sich über Her­aus­for­de­run­gen aus. Dies hat auch Einfluss auf die weitere Planung, denn der Product Owner nutzt die Ge­le­gen­heit, auf den Fort­schritt des Backlogs ein­zu­ge­hen. Die Er­kennt­nis­se des Sprints be­ein­flus­sen die Prognose für die kommenden Leis­tun­gen.

Einfluss auf den Backlog hat auch die jeweilige Markt­si­tua­ti­on: Ins­be­son­de­re bei lang­fris­ti­gen Projekten können sich im Laufe der Zeit Prio­ri­tä­ten ver­schie­ben und Budgets ändern. Auch solche Themen werden im Sprint-Review beachtet und verändern die zu­künf­ti­ge Vor­ge­hens­wei­se. Bei einem ein­mo­na­ti­gen Sprint sollte man für das Review nicht mehr als vier Stunden einplanen.

Auf das Sprint-Review folgt ein weiter Rückblick: die Sprint-Re­tro­spek­ti­ve. Innerhalb eines maximal drei­stün­di­gen Meetings setzt sich das gesamte Scrum-Team (also inklusive Product Owner und Scrum Master, aber ohne Stake­hol­der) für eine Feedback-Runde zusammen. Während beim Review vor allem das Produkt und das Vor­an­schrei­ten des Projekts im Zentrum stehen, geht es bei der Re­tro­spek­ti­ve über­wie­gend um die Team­ar­beit. Ziel dieses zweiten Rück­blicks ist es, die Arbeit un­ter­ein­an­der zu ver­bes­sern und interne Probleme aus dem Weg zu schaffen. Sobald ein Sprint beendet ist, beginnt der nächste erneut mit dem Sprint Planning.

Ge­gen­stän­de, die bei Scrum eine wichtige Rolle spielen, werden Artefakte genannt. Dazu gehören bei­spiels­wei­se auf der einen Seite Product Backlog und Sprint Backlog und auf der anderen Seite das ab­ge­schlos­se­ne Inkrement.

Bei Scrum ist Trans­pa­renz ein wichtiger Faktor. Alle be­tei­lig­ten Personen sollen jederzeit alle In­for­ma­tio­nen möglichst leicht erhalten können. Deshalb achtet man bei der Ge­stal­tung der Scrum-Artefakte darauf, dass diese einfach und ver­ständ­lich for­mu­liert sind. Beim Product Backlog ist dafür der Product Owner zuständig: Bei dem Backlog handelt es sich um eine sortierte Liste aller für das Produkt ent­schei­den­den Elemente. Zu diesen gehören sowohl die Funk­tio­na­li­tä­ten des Produkts als auch Feh­ler­be­he­bun­gen oder Ver­bes­se­run­gen.

Die Arbeit am Product Backlog findet andauernd statt: Die Liste wird dynamisch geführt – neue Er­kennt­nis­se fließen jederzeit ein und sorgen dafür, dass Einträge stärker aus­dif­fe­ren­ziert werden, neue Aufgaben hin­zu­kom­men und die Sor­tie­rung angepasst wird. Am Anfang steht dem Product Owner bei der Er­stel­lung meist der Scrum Master zur Seite. Denn die Master wissen aufgrund ihrer Erfahrung, wie das Dokument for­mu­liert sein muss, um den An­sprü­chen der Trans­pa­renz und Ef­fek­ti­vi­tät zu genügen. Einträge sollten sich generell an den An­for­de­run­gen des Kunden ori­en­tie­ren. Neben einer Be­schrei­bung des ge­for­der­ten Features enthält das Dokument auch einen Vermerk zum Ar­beits­auf­wand sowie einen Eintrag zur Prio­ri­täts­stu­fe.

Neben dem Product Backlog gibt es noch den Sprint Backlog, wobei sich letzterer aus dem ersten generiert. In den Sprint Backlog kommen alle Einträge des Product Backlogs, die beim Sprint Planning für den kommen Sprint aus­ge­wählt wurden. Damit stellt dieser Backlog alle Schritte bis zum Ziel des je­wei­li­gen Sprints dar. Während des täglichen Daily Scrums wird anhand des Sprint Backlogs der Fort­schritt beurteilt. Auch diese Liste kann während des Sprints ak­tua­li­siert werden, damit sie den An­sprü­chen und Her­aus­for­de­run­gen des Teams ent­spricht. Deshalb liegt es auch in der Ver­ant­wor­tung der Ent­wick­ler, Än­de­run­gen im Sprint Backlog vor­zu­neh­men. Weder Product Owner noch Scrum Master dürfen die Liste verändern.

Am Ende eines Sprints prä­sen­tiert das Ent­wick­ler­team das Inkrement – also das Ergebnis der Ent­wick­lungs­pha­se. In einem Inkrement sollen alle Einträge des Sprint Backlogs sowie alle In­kre­men­te vor­he­ri­ger Sprints enthalten sein. Ein Inkrement muss zumindest po­ten­zi­ell immer direkt aus­lie­fer­bar sein. Es sollte ein­satz­be­reit sein, selbst wenn gar nicht geplant ist, das Pro­dukt­in­kre­ment auch tat­säch­lich aus­zu­lie­fern. Im Sprint Review stellt das Team das Inkrement vor und Product Owner und Stake­hol­der können das Ergebnis be­gut­ach­ten.

Scrum bietet einige Vorteile – sowohl im Vergleich zu anderen agilen Verfahren als auch zu tra­di­tio­nel­le­ren Pro­jekt­ma­nage­ment-Methoden. Diese liegen vor allem in der klein­schrit­ti­gen Vor­ge­hens­wei­se und den wenigen Regeln, die das Scrum-Team ein­schrän­ken:

• Kom­mu­ni­ka­ti­on: Gutes Pro­jekt­ma­nage­ment kann nur funk­tio­nie­ren, wenn alle Team­mit­glie­der auf dem gleichen Stand sind. Scrum liegt viel Wert darauf, dass Mit­ar­bei­ter viel mit­ein­an­der kom­mu­ni­zie­ren. Deshalb sind die Scrum-Er­eig­nis­se relativ hoch getaktet. Das tägliche Meeting zum Ta­ges­be­ginn sorgt dafür, dass kein Ent­wick­ler an den anderen vor­bei­ar­bei­tet und in der ab­schlie­ßen­den Re­tro­spek­ti­ve werden auch Probleme innerhalb des Teams an­ge­spro­chen.
• Fle­xi­bi­li­tät: Bei Scrum setzt man relativ kurze Sprints an. Da maximal ein Monat zwischen zwei Pla­nungs­mee­tings liegt, kann man das Projekt auch kurz­fris­tig ändern und an neue An­for­de­run­gen anpassen.
• Trans­pa­renz: Die stetige Kom­mu­ni­ka­ti­on aller Team­mit­glie­der sowie die Ge­stal­tung der Scrum-Artefakte sorgen für eine hohe Trans­pa­renz. Backlogs sind so for­mu­liert, dass jeder Be­tei­lig­te sich darin leicht zu­recht­fin­det und die be­nö­tig­ten In­for­ma­tio­nen zum Projekt findet.
• Qua­li­täts­kon­trol­le: Durch das iterative Prinzip von Scrum ist eine stetige Kontrolle des Produkts gegeben. Feh­ler­be­he­bun­gen gehören genauso zum Product Backlog wie Wei­ter­ent­wick­lun­gen. Beim Sprint Review prä­sen­tiert das Ent­wick­ler­team zudem ein fertiges Inkrement. Product Owner und Stake­hol­der haben dabei Ge­le­gen­heit, sich von der Qualität zu über­zeu­gen. So kann deutlich schneller auf Fehler in der Ent­wick­lung reagiert werden, als wenn man erst ganz am Ende eines Projekts eine feh­ler­haf­te Funktion fest­stellt.
• Krea­ti­vi­tät: Scrum geht von der Selbst­or­ga­ni­sa­ti­on des Teams aus. Statt von oben herab die Ar­beits­wei­se vor­zu­ge­ben, gehen die Ent­wick­ler mit eigenen Ideen ans Werk. Da das Framework von Scrum zudem ver­gleichs­wei­se offen ist und wenige Regeln hat, können einzelne Team­mit­glie­der freier Ideen ein­brin­gen.
• Ef­fek­ti­vi­tät: Im Vergleich zu klas­si­schem Pro­jekt­ma­nage­ment herrscht bei Scrum eine sehr viel geringere Do­ku­men­ta­ti­ons­pflicht. Im Fokus soll das funk­tio­nie­ren­de Produkt stehen und nicht eine lü­cken­lo­se Do­ku­men­ta­ti­on, die Zeit und Res­sour­cen kosten. Statt­des­sen kann sich das Team während des Sprints voll auf die Ent­wick­lungs­ar­beit kon­zen­trie­ren und diese so ausführen, wie es das für sinnvoll hält.

Trotz der über­zeu­gen­den Vorteile eignet sich Scrum nicht für jeden Betrieb glei­cher­ma­ßen. Aufgrund folgender Nachteile ist Scrum für einige Un­ter­neh­men nicht die ideale Lösung:

• Man­geln­der Überblick: Was für das eine Team ein großer Vorteil sein kann, ist für das andere eher ein Nachteil: Die sehr kurz­schrit­ti­ge Planung kann dafür sorgen, dass man das große Ganze bei um­fas­sen­de­ren Projekten aus den Augen verliert.
• Auf­wen­di­ge Kom­mu­ni­ka­ti­on: Scrum-Er­eig­nis­se sind fest ein­ge­tak­tet. Doch für manche Teams und Projekte kann ein solch hohes Maß an Kom­mu­ni­ka­ti­on unnötig sein. Die täglich statt­fin­den­den Daily Scrums hindern in solchen Fällen eher die Pro­duk­ti­vi­tät. Man verwendet zu viel Zeit auf Or­ga­ni­sa­ti­on und Kom­mu­ni­ka­ti­on statt auf die ei­gent­li­che Arbeit am Produkt.
• Ver­un­si­che­rung hin­sicht­lich Planung und Zu­stän­dig­keit: Scrum sieht vor, dass Teams sich selbst or­ga­ni­sie­ren. Das kann durchaus vor­teil­haft sein, doch in einigen Bereichen und Branchen kann solch flache Hier­ar­chie auch zur Ver­un­si­che­rung bei der Planung und Un­klar­hei­ten hin­sicht­lich der Zu­stän­dig­keit führen.
• Nicht in­te­grier­bar: In manche Un­ter­neh­mens­struk­tur lässt sich Scrum nur durch starke An­pas­sun­gen in­te­grie­ren. In solchen Fällen stellt sich die Frage, ob man nicht mehr Ef­fek­ti­vi­tät verliert, als man durch Scrum hin­zu­ge­winnt.

Ob sich Scrum auch für Ihr Un­ter­neh­men eignet, müssen Sie also letztlich selbst be­ur­tei­len und abwägen, ob die flachen Hier­ar­chien und die re­gel­mä­ßi­ge Kom­mu­ni­ka­ti­on in Scrum-Teams auch in Ihrem Betrieb zu einer Pro­duk­ti­vi­täts­stei­ge­rung und einer höheren Arbeits- und Pro­dukt­qua­li­tät führen.