Scrum Vorteile: Was zeichnet Scrum aus und welches Potenzial steckt dahinter?

Ursprünglich stammt Scrum aus der Softwareentwicklung. Inzwischen gehört der Ansatz fest zur agilen Projektentwicklung und zum agilen Projektmanagement. Doch obwohl es bei Scrum keine ausufernde Konzeptphase gibt, ist das Vorgehen keineswegs planlos. In diesem Beitrag erfährst Du, was agile Projektentwicklung und agiles Projektmanagement mit Scrum ausmacht: Wichtige Rollen und Tools, die Umsetzung von Scrum in der Praxis, Scrum Vorteile und die Kostenkalkulation von Scrum Projekten.

Scrum: Agile Projektentwicklung aus der Softwareentwicklung

Projekte, die auf klassische Weise angegangen werden, stützen sich auf das Wasserfall-Modell. „Wasserfall“, weil Projektbeteiligte möglichst detaillierte Vorarbeiten mit genauen Arbeitsanweisungen erhalten. Beim Scrum Ansatz sieht das anders aus. Scrum Teams erhalten erst einmal nur genaue Zielvorgaben. Der Weg dorthin ist jedoch nicht definiert, sondern entwickelt sich innerhalb Teams während der Projektarbeit. Scrum ist also nicht planlos. Statt die Art der Umsetzung im Vorhinein angegeben zu bekommen, erarbeitet das Projektteam diese im laufenden Prozess. Gruppendynamik und stetig neue Erkenntnisse fließen so in die Projektentwicklung ein.

Was aber macht Scrum noch aus? Ursprünglich stammt Scrum aus der Softwareentwicklung. In dieser ist es üblich, ein Gesamtprojekt in kleinere Teilprojekte zu splitten. Der Scrum Ansatz nimmt genau dieses Vorgehen auf: Ein Gesamtprojekt, beispielsweise der Launch einer neuen Website, wird in kleinere „Häppchen“ aufgebrochen. Diese Teilprojekte werden nacheinander in Sprints umgesetzt. Das Ziel eines jeden Sprints ist es dabei, den darin bearbeiteten Teilaspekt des Projektes vollständig und funktionsfähig auszuliefern. In der Softwareentwicklung heißt das: Funktionsfähiger und qualitativ hochwertiger Code steht am Ende des Sprints zur Verfügung.

Bleiben wir bei dem Beispiel der Website, könnte das Endergebnis eines Sprints etwa die Website als zentrale Ausgangsseite der Internetpräsenz sein. Die Arbeit mit Scrum benötigt allerdings eines: Akzeptanz. Der Entwicklungsprozess ist nicht vorherzusehen und das muss von allen Projektbeteiligten akzeptiert werden. Wer Scrum als Ansatz für sein agiles Projektmanagement und die agile Projektentwicklung wählt, hat als oberstes Ziel, das bestmögliche Ergebnis unter Berücksichtigung von Kosten, Funktionalität, Zeit und Qualität zu erzielen – der Weg dorthin steht hinten an. Sie wollen mehr zum Einsatz von Scrum lesen? In unserem Beitrag erfährst Du, wie Marketeers Scrum erfolgreich einsetzen – und wann sie es besser lassen sollten.

Drei Prinzipien von Scrum

Der Scrum Ansatz charakterisiert sich durch drei einfache Prinzipien: Transparenz, Überprüfung und Anpassung. Bei der Transparenz gilt es, den Fortschritt, aber auch eventuelle Hindernisse, eines Projektes täglich und für alle sichtbar festzuhalten. Die Überprüfung erfolgt in regelmäßigen Abständen. Dabei werden Funktionalitäten, die das Produkt liefern soll, genauestens hinsichtlich ihrer Qualität beurteilt. Unter dem Prinzip der Anpassung versteht man bei Scrum, dass Anforderungen an das Produkt bzw. das Projektziel nicht ein für alle Mal im Vorfeld festgelegt werden. Mit jedem fertigen Sprint werden die Anforderungen neu bewertet und bei Bedarf angepasst. Wie Scrum die Projektarbeit beeinflusst, kann anhand des Agilen Manifests besser verstanden werden. 2001 haben IT-Verantwortliche zwölf Thesen zum Scrum-Ansatz verfasst, die die Kernaspekte widerspiegeln. Die Thesen sind natürlich auf die Softwareentwicklung bezogen, können aber ebenso auf andere Projekte anwenden. Wir haben die Inhalte der Thesen einmal allgemein für Projekte aller Art übersetzt.

12 Thesen zum Scrum Ansatz

1. Die höchste Priorität ist es, Kund:innen zufriedenzustellen, indem Produkte schnell und qualitativ ausgeliefert werden.
2. Änderungen von Anforderungen, die selbst in späteren Projektphasen entstehen, werden zum Wettbewerbsvorteil für die Kund:innen.
3. Ziel ist es, funktionierende Produkte bzw. Produktkomponenten in regelmäßigen und kurzen Abständen zu liefern.
4. Die Projektbeteiligten müssen während des Projekts täglich zusammenarbeiten.
5. Die Projektbeteiligten sollten alle motiviert sein. Gleichzeitig sollen sie das Umfeld und die von ihnen gewünschte Unterstützung erhalten. Ansonsten heißt es: Vertraue darauf, dass die Projektbeteiligten ihre Aufgabe erledigen.
6. Funktionierende (Teil-)Produkte sind das wichtigste Fortschrittsmaß eines Projektes.
7. Informationen innerhalb des Projekt-Teams zu teilen ist am effizientesten und effektivsten im direkten Gespräch.
8. Agile Prozesse fördern eine nachhaltige Entwicklung. Auftraggeber:innen und Projektbeteiligte sollten daher ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Agilität wird durch ein ständiges Augenmerk auf Funktionalität gefördert.
10. Einfachheit ist zentral. Getane Arbeit soll nicht maximiert werden.
11. Selbstorganisierte Teams schaffen den Raum für die besten Ergebnisse.
12. Das Team reflektiert in regelmäßigen Abständen, wie es Prozesse effektiver gestalten kann, und passt sein Verhalten darauf an.

Scrum Team – drei Rollen, drei Gruppen

Im Scrum Team übernehmen die Projektbeteiligten klassischerweise drei Rollen. Diese bestehen aus dem Product Owner, dem Scrum Master und dem Entwicklungsteam. Jede einzelne Rolle hat spezifische, ihr zugewiesene Aufgaben auszuführen. Hinzu kommen die drei Gruppen Customer, User und Management. Wichtig ist: Auch wenn es einzelne Rollen und Gruppen gibt, steht während des gesamten Projektes immer das komplette Scrum Team im Vordergrund. Dieses gewinnt zusammen und muss auch zusammen auf neu auftretende Herausforderungen reagieren.

Product Owner: Brücke zwischen Kund:innen und Scrum Team

Der Product Owner gibt die Anforderungen und die Projektstrategie mitsamt der Priorisierung von Anforderungen und Tasks vor. Anforderungen und Tasks werden von ihm mit dem Entwicklungsteam innerhalb des Product Backlog als User Stories abgestimmt und erfasst. Die User Stories beschreiben dabei die gewünschten und nötigen Funktionalitäten des Produkts aus Sicht der User. In den Aufgabenbereich des Product Owners fällt zudem die Überprüfung der Ergebnisse am Ende eines jeden Sprints. Er entscheidet über Features, Kosten und Auslieferungszeitpunkt des entwickelten (Teil-)Produkts. Er wird in der Regel vom Auftragnehmer gestellt und fungiert als Brücke zwischen dem Kunden (Customer) und dem Scrum Team.

Scrum Master: Administrator des Teams

Anders als der Product Owner arbeitet der Scrum Master als „Moderator“ des Scrum Projekts. Er verantwortet den Erfolg und führt Scrum Regeln für die Projektdurchführung ein. Der Scrum Master begleitet die Meetings und ist für das Scrum Team der erste Ansprechpartner bei auftretenden Herausforderungen im Scrum Prozess – beispielsweise Kommunikationsprobleme oder das Aufkommen neuer bzw. veränderter Anforderungen an das (Teil-)Produkt. Scrum Master arbeiten dabei zwar eng mit dem Entwicklungsteam zusammen, sind aber kein direkter Teil von diesem, sondern viel mehr die Führungskraft des Entwicklungsteams. Sein Schwerpunkt ist administrativer Natur. Wir zeigen Dir außerdem, warum agile Projekte einen Scrum Master brauchen.

Entwicklungsteam: Umsetzung des Projektziels

Die letzte Rolle im Scrum Team ist das Entwicklungsteam, das je nach Projektgröße meist aus fünf bis sieben Beteiligten besteht und sich selbst organisiert. Diese sind für die Entwicklung des Projektziels (z.B. ein Produkt) verantwortlich und setzt die im Product Backlog geforderten Anforderungen/ Funktionalitäten um. Dabei arbeiten sie interdisziplinär zusammen: Die Übernahme von Testaufgaben gehört ebenso zu ihrem Einsatzgebiet, wie die Entwicklung an sich.

Innerhalb des Scrum Prozesses übernimmt das Entwicklungsteam zudem im ersten Sprint die Überprüfung der gesetzten Anforderungen und diskutiert diese. Das Entwicklungsteam gibt geschlossen Rückmeldung an den Product Owner hinsichtlich der Umsetzung des ersten Sprints und darin enthaltenen Anforderungen. Gleichzeitig verpflichtet sich das Team, die selbst definierten Anforderungen auch zu erreichen, und erarbeitet gemeinsam detaillierte Umsetzungsmethoden. Die Anforderungen werden in User Stories vom Team festgehalten und in die einzelnen Tasks heruntergebrochen – wie oben erwähnt in Zusammenarbeit mit dem Product Owner.

Gruppen: Customer, User und Management

Die Gruppe der Customer umfasst den oder die Kund:innen des Scrum Teams. Der Customer steht im direkten Austausch mit dem Product Owner, nicht aber mit dem gesamten Scrum Team. Als User werden wiederum die späteren Anwender:innen des entwickelten Produkts bezeichnet. User können zugleich Customer sein, müssen es aber nicht. Die User sollten im Scrum Prozess vor allem beim Sprint Planning und den jeweiligen Reviews der einzelnen Sprints einbezogen werden. Denn sie beurteilen das entwickelte Produkt hinsichtlich Funktionalität, Qualität und Usability. Die letzte Gruppe im Scrum Team ist das Management. Dessen Aufgabe besteht darin, die Rahmenbedingungen für ein erfolgreiches Scrum Projekt zu schaffen. Das Management stellt die dazu notwendigen Ressourcen und Unterstützung des Scrum Teams bereit.

Ablauf eines Scrum Prozesses

  Ein agiles Scrum Projekt ist nicht planlos. Das zeigt sich auch wieder im Scrum Prozess selbst. Dieser teilt sich in verschiedene Phasen auf. Am Anfang steht der Product Backlog. Darauf folgen zwei Sprint Planning Meetings, bevor es an die Projektumsetzung innerhalb verschiedener Sprints geht. Hinzu kommen Daily Scrums als Kurzmeetings während der Sprints. Am Ende jedes Sprints erfolgt ein Sprint Review und die Retrospektive. Die einzelnen Projektfortschritt werden dabei in einem Burndown Diagramm festgehalten. Aber zuerst mehr zu den einzelnen Prozessabschnitten.

Product Backlog: Zentrales Element des Scrum Projektes

Der Product Backlog ist der Dreh- und Angelpunkt des Scrum Projektes. Hier werden die Anforderungen vom Product Owner festgehalten und priorisiert. Die Liste ist das Herzstück der Produktentwicklung, da sie alle Aspekte beinhaltet, die das fertige Produkt enthalten muss. Die Anforderungen werden User-orientiert in User Stories erfasst. Das Product Backlog wird im Verlauf des Scrum Projektes weiter vom Product Owner gepflegt und aktualisiert. Wie sieht eine ideale User Story eigentlich aus? Grundsätzlich beantwortet die User Story sieben Fragen: „Wer“, „was“, „wozu“, „wo“, „wann“, „wie“ und „warum“. Ein Beispiel zu den ersten drei Fragen: „Als User möchte ich diese Funktionalität, damit ich folgenden Nutzen habe“.

Sprint Planning Meeting 1: Vorstellung und Diskussion der Anforderungen

Der Product Owner stellt die Anforderungen aus dem Product Backlog dem Entwicklungsteam vor. Idealerweise ist dabei auch ein User dabei, der die gewünschten Funktionalitäten noch einmal aus der eigenen Sicht darlegen kann. Das Entwicklungsteam macht sich während des ersten Sprint Planning Meetings mit den Anforderungen an das Produkt bzw. das Projektziel vertraut und klärt eventuell aufkommende Fragen. Zudem werden am Ende des Meetings die Abnahmekriterien für den anstehenden Sprint definiert. Das Sprint Planning Meeting 1 findet also vor jedem einzelnen Sprint statt und sollte maximal eine Stunde betragen. Die im Sprint Planning Meeting besprochenen Anforderungen und deren etwaige Änderungen werden im Sprint Backlog erfasst.

Sprint Planning Meeting 2: Entwicklungsteam organisiert Umsetzung

Im anschließenden Sprint Planning Meeting 2 klärt das Entwicklungsteam eigenverantwortlich, wie es die zuvor vorgestellten Anforderungen umsetzt. Dazu teilt das Team die einzelnen Anforderungen in Tasks ein, die in der Regel nicht länger als einen Tag in Anspruch nehmen sollten. Diese Tasks werden am Taskboard angebracht, um einen laufenden Überblick zum Projekt, den anstehenden Aufgaben und deren jeweiligem Status zu bekommen. Wie das Sprint Planning Meeting 1 sollte auch das zweite Meeting nicht mehr als eine Stunde betragen. Und wie beim ersten Meeting werden auch die Ergebnisse des zweiten Sprint Planning Meetings im Sprint Backlog festgehalten. Jeder Task wird hier eine der Ausprägungen „Task to Do“, „Work in Progress“ oder „Done“ zugewiesen.

Sprint: Die konkrete Umsetzung beginnt

Auf die beiden Sprint Planning Meetings folgt dann die Umsetzung des ersten Sprints, mit den zuvor definierten und abgestimmten Tasks. Die Bearbeitung erfolgt anhand der im Sprint Planning erarbeiteten Priorisierung. Das Entwicklungsteam geht Task für Task vor und stellt für jede einzelne Aufgabe sicher, dass alle Anforderungen abgearbeitet wurden. So wird vermieden, dass unfertige (Teil-)Ergebnisse abgeliefert werden.

Während eines Sprints konzentriert sich das Entwicklungsteam also ausschließlich auf die für diesen Sprint definierten Anforderungen und Tasks. Der Scrum Master sorgt während des Sprints dafür, dass aufkommende Herausforderungen in der Bearbeitung geklärt und beseitigt werden. Er darf allerdings keine Anweisungen an das Team erteilen, sondern lediglich an die Erreichung der definierten Ziele erinnern. Ein Sprint endet immer gemäß dem angesetzten Zeitplan, der in der Regel zwischen zwei und vier Wochen dauert. Am Ende muss ein funktionierendes (Teil-)Ergebnis des laufenden Projektes verfügbar sein. Der oder die Kund:in entscheidet nach jedem Sprint, ob er dieses (Teil-)Ergebnis bereits produktiv einsetzen will.

Daily Scrum: Tägliches Meeting während des Sprints

Innerhalb eines Sprints stehen Daily Scrums für das Entwicklungsteam an. Das sind maximal 15 Minuten lange Meetings zum aktuellen Stand der Entwicklung, den aktuellen und zuletzt bearbeitete sowie für den Tag anstehenden Tasks. Die Meetings dienen unter anderem dazu, möglicherweise zu große Tasks, die nicht innerhalb eines Tages bearbeitet werden können, in kleinere herunterzubrechen. Ebenso sollen Fragen und Probleme geklärt werden. Ist dies nicht im Kurz-Meeting möglich, werden diese an den Scrum Master übergeben, der solche Aspekte im Impediment Backlog erfasst und bearbeitet.

Sprint Review und Retrospektive: Ergebnisse überprüfen und Sprint evaluieren

Ist der Sprint abgeschlossen, erfolgt das Sprint Review und die Retrospektive. Hier stellt das Entwicklungsteam dem Product Owner (und dem User) das (Teil-)Produkt bzw. (Teil-)Ergebnis vor, das aus den im Sprint Planning Meeting 1 definierten Anforderungen/ Tasks hervorgegangen ist. Der Product Owner entscheidet dann anhand dieser Anforderungen, ob das Ergebnis abgenommen werden kann oder nicht. Die Anforderungen müssen zu 100 Prozent getroffen sein. Ist das nicht der Fall, werden nicht erfüllte Anforderungen vom Product Owner als neue bzw. nochmalige Tasks in das Sprint Planning Meeting für den kommenden Sprint übernommen. Das Gleiche gilt für Ideen oder Anforderungen, die sich im Sprint Review ergeben. Dann gibt der Scrum Master die neuen Anforderungen an den Product Owner zur Erfassung im Product Backlog weiter.

Nach Abschluss des Sprint Reviews trifft sich das gesamte Scrum Team (Product Owner, Scrum Master und Entwicklungsteam) zur Retrospektive. Hier werden eventuelle Probleme, Learnings und Verbesserungsmöglichkeiten diskutiert, die in den nächsten Sprint einfließen. Sofern es sich um Verbesserungen handelt, die das Entwicklungsteam alleine betreffen, werden sie von diesem selbst gelöst. Andere Probleme o.ä. fallen in den Aufgabenbereich des Scrum Masters. Er nimmt diese im Impediment Backlog auf und gibt sie an den Product Owner zur Bewertung für den folgenden Sprint weiter.

Burndown-Diagramm – Aktueller Entwicklungsstand immer im Blick

Der aktuelle Entwicklungsstand wird idealerweise in einem Burndown-Diagramm dargestellt. Dieses zeigt auf einen Blick: Den Zeitaufwand für das Scrum Projekt, die Anzahl bearbeiteter und verbleibender Tasks und den Idealverlauf des Projekts. Hier ein Beispiel eines Burndown-Diagramms: Je nach Abweichung vom Idealverlauf kann sehr schnell beurteilt werden, ob das Entwicklungsteam in time ist oder Verzögerungen bestehen. Auf das Burndown-Diagramm haben alle Projektbeteiligten, also auch der bzw. die Kund:in, Zugriff. das erhält die Transparenz während des Projektes.

Scrum Vorteile im Überblick

Die Vorteile der agilen Projektentwicklung mit Scrum sind vielfältig. Wir liefern Dir eine Übersicht der Scrum Vorteile:

1. Flexibilität: Zum einen arbeiten Teams deutlich flexibler, da ein Großprojekt in kleinere Teilprojekte (Sprints) heruntergebrochen wird diese einzeln nacheinander realisiert werden. Nach jedem Teilprojekt erfolgt ein Review. Die Erkenntnisse fließen dann wieder in die nachfolgenden Teilprojekte ein. Damit können Änderung am Markt oder neue Erkenntnisse und Ideen jederzeit aufgegriffen und in einem der kommenden Sprints berücksichtigt werden.
2. Kurze Kommunikationswege, schnelle Problemidentifikation und geringerer Administrationsaufwand: Durch die klare Einteilung in Rollen werden Kommunikationswege verkürzt. Jeder Projektbeteiligte weiß, mit wem er im Austausch steht und wer für welche Kommunikation zuständig ist. Die klare Aufgabenzuweisung sorgt ebenso dafür, dass der Aufwand für Administration und Dokumentation verringert wird. Gleichzeitig ermöglichen die kleinen Teilprojekte, Probleme schneller zu identifizieren und effektiver auszuräumen.
3. Höchstmögliche Transparenz: Das ist einer der größten Vorteile von Scrum. Alle Projektbeteiligten haben zu jedem Zeitpunkt vollständige Transparenz im Hinblick auf den aktuellen Entwicklungsstand sowie etwaige Hemmnisse. Das ermöglichen der Zugriff auf Backlogs, auf Burndown Diagramme und auf die aktuelle Testumgebung. Hier kann jeweils sehr zeitnah bei Problemen gegengesteuert werden. Böse Überraschungen bleiben somit aus.
4. Kontinuierlicher Verbesserungsprozess: Durch die permanente Diskussion in der Gruppe sowie die Reflektion am Ende eines jeden Sprints werden die Ergebnisse stetig verbessert. Das wirkt sich nicht nur fachlich, sondern auch auf die wirtschaftlichen Belange positiv aus.
5. Motivation und Effektivität durch Selbstorganisation: Aufgrund der „häppchenweisen“ Realisierung arbeiten Entwickler konzentrierter und auch fokussierter. Durch das Arbeiten im Team und den gegenseitigen Ansporn steigt die Motivation. Die Arbeitsergebnisse werden mithilfe von Scrum insgesamt deutlich besser.
6. Zeitnahe Realisation von Projektergebnissen: Der Scrum Ansatz bietet den Vorteil, dass schnell (Teil-)Ergebnisse eines Gesamtprojekts verfügbar sind. Sie können, je nach Wunsch der Kund:innen, sofort eingesetzt werden.
7. Realistische und genaue Aufwandsschätzungen: Anhand der Zerlegung in Teilprojekte können Unternehmen den Aufwand des Scrum Projekts besser einschätzen. Wie die Kostenkalkulation von Scrum durchgeführt werden kann, erfährst Du im folgenden Abschnitt näher.

Nachteile eines Scrum Projekts

Zu den Nachteilen von Scrum gehört, dass es keinen Gesamtüberblick über die komplette Projektstrecke gibt. Weitere Nachteile bilden der Kommmunikations- und Abstimmungsprozess. Denn der Aufwand nimmt trotz kürzerer Kommunikationswege zu. Der Grund: Scrum beinhaltet mehr Abstimmungs- und Review-Schleifen. Auch gibt es nur wenige konkrete Handlungsempfehlungen. Unternehmen müssen dem Scrum Team entsprechend viel Vertrauen für die Projektumsetzung entgegenbringen. Gleichzeitig besteht innerhalb der Task-Bearbeitung die Gefahr eines „Tunnelblicks“. Es ist daher wichtig, das Gesamtziel nie aus den Augen zu verlieren. Bei sehr großen Projekten, die mehrere Entwicklungsteams benötigen, kann die Koordination erschwert werden.

Kostenkalkulation von Scrum Projekten

Die Projekt-Arbeit stellt die Kalkulation je nach Auftraggeber vor Herausforderungen. Viele Unternehmen fordern ein Fixpreis-Angebot. Bei der Projektentwicklung ist dies allerdings nachteilig: Bestimmte Anforderungen und Features lassen sich im Vorfeld nur schwer vernünftig schätzen. Zudem kann es während der Projektphase zu weitreichenden Änderungen kommen, welche die Kalkulation über einen Fixpreis ausstechen. Ein Fixpreis-Angebot zieht vor allem zwei Probleme nach sich: Anbieter:innen kalkulieren in der Regel Unsicherheiten und Unwägbarkeiten ein, was aber deutlich teurer als der tatsächliche Aufwand ausfallen kann. Darüber hinaus sind Nachkalkulationen bei Fixpreis-Angeboten nicht auszuschließen. Oder der Auftragnehmer arbeitet innerhalb des Budgets, dafür aber weniger qualitativ. Diese Faktoren sind Nachteile, die bei der Frage nach Fixpreis-Angeboten berücksichtigt werden sollten. Zumal der Scrum Ansatz Möglichkeiten bietet, Aufwandsschätzungen detailliert durchzuführen. Dazu kann der Product Backlog dienen.

Product Backlog zur ersten Kalkulation

Bei Scrum Projekten hat sich in der Praxis bewährt, den Product Backlog dafür die erste Abschätzung der Kosten hinzuzuziehen. Aufgrund der erfassten Anforderungen können Kund:innen gemeinsam mit dem Product Owner anhand der Sprints eine Kalkulation des Projektumfangs umreißen – und das bereits in einem sehr frühen Stadium. Der Auftraggeber kann dabei die Kosten deckeln und die definierten Anforderungen entsprechend anpassen. Denkbar ist auch, dass der kalkulierte Aufwand als Höchstgrenze angesetzt wird. Diese Grenzen kann das Entwicklerteam dann beim Projekt berücksichtigen. Am Ende geht es also nur um die tatsächlich angefallenen Aufwände. Durch den Zugriff auf Projektmanagement-Tools können Auftraggeber diese Aufwände täglich einsehen und überwachen. So lässt sich mit Scrum sogar ein Projekt mit einem vorab fixierten Budget realisieren. Reicht das Budget dennoch nicht aus, können in Abstimmung mit dem Auftraggeber Funktionalitäten angepasst oder gestrichen werden.

Fazit

Unternehmen sollten sich definitiv beim nächsten Projekt auf das Thema Scrum einlassen. Die Scrum Vorteile lassen sich auch außerhalb von IT-Projekten für die agile Projektentwicklung und das agile Projektmanagement nutzen. Unternehmen gewinnen an Flexibilität und Qualität hinsichtlich der Projektergebnisse. Darüber hinaus schafft Scrum eine weitaus höhere Transparenz für alle Projektbeteiligten. Die Einteilung in kleinere Teilprojekte sorgt dafür, dass die Bearbeitung des Gesamtprojekts effizienter und schneller erfolgt. Das Entwicklerteam kann sich besser auf die einzelnen Tasks fokussieren, was sich in der Motivation und der Qualität der Ergebnisse niederschlägt. Gleichzeitig ermöglicht der Scrum Ansatz eine detaillierte Kostenkalkulation, bei der nur die tatsächlichen Aufwände berechnet werden. Unternehmen sollten jedoch auch beachten, dass der Scrum Ansatz nicht vor Sackgassen in der Projektentwicklung schützt. Er bietet aber eine Möglichkeit, schneller und früher auf solche zu reagieren.