Scrum entstand Anfang der 1990er Jahre und hat Ihren Ursprung in der Softwareentwicklung. Für die Namensgebung wurde eine Formation im Rugby herangezogen, bei der die Stürmer sich zu einer bestimmten Position zusammenschließen, auch SCRUM genannt. Auch heute weist das Projektmanagement nach Scrum noch viele Verbindungen zum Rugby auf, Beispielsweise durch selbst organisierende und crossfunktionale Teams, sowie „überlappende“ Entwicklungsphasen und Wissensmanagement, welche durchaus wichtige und charakteristische Eigenschaften sowohl bei Rugby als auch bei Scrum sind. Zentrales Merkmal von agil durchgeführten Projekten ist es, dass die Arbeit in kleine Einheiten zerlegt wird; die einzelnen Arbeitseinheiten werden dann von einem Team in ständiger Interaktion abgearbeitet. Die Arbeit ist dabei so organisiert, dass die Zusammenarbeit und Interaktion zwischen den beteiligten Personen möglichst reibungslos funktionieren kann: Die agile Arbeitsweise basiert wesentlich darauf, die Beteiligung aller einzelnen Personen wertzuschätzen. Zugleich werden in der Zusammenarbeit die gemeinsamen Ziele kontinuierlich überprüft und angepasst.

Bei einem Scrum Projekt gibt es mehrere, sich im Kreislauf wiederholende Stationen, die solange durchlaufen werden, bis das Ergebnis "Das Increment" final verabschiedet wird. So beginnt man ein agiles Projekt, indem man die Vision definiert, welche das fertige Icrement widerspiegelt. Zur Erreichung der Vision wird die Arbeit in Teilaufgaben unterteilt und im Product Backlog festgehalten, wo alle Aufgaben gesammelt und anschließend in Sprints (fix definierte Arbeitsintervalle zur Ausführung der Aufgaben) abgearbeitet werden. Bevor man einen Sprint startet, wird in einem Sprint- Planungsmeeting die Dauer, das Ziel und die dazugehörigen Aufgaben definiert. Diese werden dann aus dem Product Backlog in den Sprint Backlog übertragen. Ist der Sprint Backlog erstellt, kann man den Sprint starten und das Dev.-Team arbeitet eigenverantwortlich den Sprint ab. Während eines laufenden Sprints gibt es keine Möglichkeiten, noch zusätzliche Änderungswünsche oder Veränderungen des Sprint Backlogs aufzunehmen, da erst am Ende die erstellten Ergebnisse in der Retrospektive zusammen mit dem Kunden besprochen werden. Nach der Retrospektive folgt noch das Review, bei dem das Dev.-Team noch bespricht, was hätte anders oder besser laufen sollen, aber natürlich auch was genau richtig lief.

In einem agilen Scrum Projekt, werden die Projektteilnehmer als ganzes auch Scrum- Team genannt. Dieses setzt sich hierbei erstrangig aus den Rollen: Product Owner, Dev.Team und Scrum Master zusammen. Die Stakeholder nehmen zwar Einfluss auf das Projekt und die Entscheidungen, arbeiten aber nicht aktiv an der operativen Entwicklung mit und zählen somit nicht zum Scrum Team.

Die Rolle der Stakeholder nehmen i.d.R. alle Kunden eines Scrum-Teams ein. Sie stellen die zukünftigen Benutzer/ Entscheider und Abnehmer des zu entwickelnden Produkts dar. Mit dem Input der Stakeholder und der Unterstützung des Product Owners, stellt das Entwicklungsteam das gewünschte Produkt bzw. die gewünschte Dienstleistung her. In einem Scrum Projekt, treten Stakeholder regelmäßig bei der Backlogplanung, Sprintplanung und bei der Retrospektive auf.

Der Product Owner ist bei Scrum dafür verantwortlich, dass sowohl der Produktwert als auch der Wert des Projektteams maximiert werden. Die konkrete Umsetzung der Rolle des Product Owners , hängt oft vom Unternehmen und dem Scrum-Team ab. Die regelmäßige Abstimmung mit den Stakeholdern und die Übernahme der Hauptverantwortung für die Erstellung und Verwaltung des Product Backlogs, liegen dabei vorrangig im Aufgabengebiet des Product Owners. Hierbei sind seine Kernaufgaben die eindeutige Beschreibung der Punkte im Product Backlog, sowie eine Sortierung der verschiedenen Punkte nach Prioritäten. Dadurch soll sichergestellt werden, dass das Entwicklungsteam die Anforderungen und die Punkte aus dem Backlog auch versteht.

In einem Scrum Entwicklungsteam, auch Development Team (Dev.-Team) genannt, finden sich alle Teilnehmer wieder, die mit Ihren Fähigkeiten zur Entwicklung des Vorhabens beitragen können. So sind dies regelmäßig professionelle Grafikdesigner, FrontEnd-/ und BackEnd- Entwickler, IT- Security Officer, Datenschutzreferenten, Texter, Layouter, Projektmanager oder sonstige Projektteilnehmer. Dabei bleibt ein zusammengestelltes Entwicklungsteam meistens für die Dauer des gesamten Projektes zusammen. Dies hat den Hintergrund, dass die Dev.Team- Mitglieder sich im Projekt aufeinander einspielen und die Zusammenarbeit mit der Zeit immer effizienter wird. Darüber hinaus können situativ und außerhalb eines laufenden Sprints weitere Projektteilnehmer mit benötigten Spezialfähigkeiten konsultiert werden.

Ein Scrum Master hat die Aufgabe dafür zu sorgen, dass die Scrum Methodologie über die gesamte Projektdauer beibehalten wird. Ein Scrum Master coacht die Mitglieder des Entwicklungsteams und die Stakeholder in agilen Projektmanagementmethoden, unterstützt den Product Owner bei der Erstellung und Priorisierung des Product Backlogs und sorgt für eine angenehme, produktive Arbeitsatmosphäre im Team. Abgeleitet von der englischen Bezeichnung eines "Servent Leaders" (eines dienenden Führers), nimmt der Scrum Master eine dem Projekt und den Teilnehmern dienende Leitungsfunktion ein.

Ein Scrum Master hat die Aufgabe dafür zu sorgen, dass die Scrum Methodologie über die gesamte Projektdauer beibehalten wird. Ein Scrum Master coacht die Mitglieder des Entwicklungsteams und die Stakeholder in agilen Projektmanagementmethoden, unterstützt den Product Owner bei der Erstellung und Priorisierung des Product Backlogs und sorgt für eine angenehme, produktive Arbeitsatmosphäre im Team. Abgeleitet von der englischen Bezeichnung eines "Servent Leaders" (eines dienenden Führers), nimmt der Scrum Master eine dem Projekt und den Teilnehmern dienende Leitungsfunktion ein.

Im Kontext eines Unternehmens findet agiles Arbeiten auf verschiedenen Ebenen statt. Das fängt bei agilen Teams an, führt über agiles Management bis zu einer komplett agilen Organisation. Eine agile Organisation ist stark vereinfacht die Summe vieler agiler Teams, die sich an einem gemeinsamen Unternehmensleitbild und in Leitungsteams organisieren. Agiles Arbeiten bedeutet nicht etwa “etwas flexibler zu sein” oder “die Arbeit einfacher der schneller zu erledigen”. Agiles Arbeiten ist eine sehr strukturierte Form der Zusammenarbeit, die an vielen Stellen mit traditionellen Organisations- und Projektstrukturen, Hierarchien oder auch der beruflichen Sozialisierung eines jeden Einzelnen kollidiert und im wesentlichen auf klar definierten Säulen aufgebaut ist. (1) Freiwilligkeit: Das Prinzip der Freiwilligkeit ist die wichtigste Säule für erfolgreiche, agile Arbeit. (2) Ein klares Ziel: Agiles Arbeiten erfordert Ziele und Leitbilder, mit denen sich alle Mitglieder des Teams identifizieren können. (3) Kurze Zeitintervalle: Agiles Arbeiten ist ein empirischer Prozess. Das heißt, in regelmäßigen Abständen werden Arbeitsergebnisse begutachtet und neue Anforderungen ergänzt bzw. neu priorisiert. (4) Kundenzentrierung: Agiles Arbeiten bezieht den Kunden mit ein. Das bedeutet Probleme und Bedürfnisse der Kunden zu analysieren, zu verstehen und zu antizipieren. Durch Prototypen wird der Kunden bereits in einem sehr frühen Produktlebenszyklus in die Entwicklung einbezogen. (5) Kleine Teams: Agiles Arbeiten setzt auf kleine, autonome und selbstorganisierte Teams. (6) Wertorientierung: Agiles Arbeiten bedeutet Werte zu schaffen. Das heißt alle Aufgaben haben einen konkreten und messbaren Wertbeitrag.

Üblicherweise werden digitale Projekte in Zusammenarbeit mit Agenturen nach der klassischen Wasserfallmethode gesteuert. Hierbei müssen Kunden, bevor ein Projekt beauftragt wird, im übertragenem Sinne, erst einmal jede Menge Wasser den Berg hinauf tragen. Das heißt, bevor das Projekt überhaupt gestartet wird, werden alle Aufgaben der Reihe nach geplant. Dabei kommt es oft vor, dass die ursprünglich geplante Reihenfolge oder ganze Aufgabensträngte verändert oder sogar verworfen werden. In anderen Worten: bereits im Vorfeld wurde teilweise falsches Wasser den Berg hochgetragen. Wenn der „Wasserfall“ erst einmal plätschert, ist er eine relativ bequeme Sache. Beim Auftraggeber wartet man in Ruhe (oder mit leichter Nervosität) das Ergebnis ab. Zugleich kann die Agentur in Ruhe arbeiten (schmort aber eben auch nur im eigenen Saft). Nicht selten jedoch gibt es dann bei der Vorstellung von ersten Ergebnissen viel Platz für Enttäuschung:

(1) Probleme und Missverständnisse werden erst spät erkannt. Je weiter die Arbeiten am Produkt schon fortgeschritten sind, umso größer wird der Aufwand, die entsprechenden Änderungen vorzunehmen. Dabei ist es ja nur menschlich, dass es zu solchen Missverständnissen kommt! Kein Briefing ist so präzise, dass es keinen Raum für Interpretation mehr ließe. Und kein Briefing ist so allumfassend, dass es wirklich jedes Detail beschreibt.

(2) Änderungen am Projekt lassen sich nur mit deutlichem Mehraufwand noch unterbringen. Das wird inzwischen insbesondere deshalb zum Problem, weil digitale Projekte vom ersten Briefing bis zur Fertigstellung inzwischen leicht ein bis zwei Jahre oder länger dauern können. In der Zeitrechnung des Internets sind das Ewigkeiten, in der sich an den technischen Möglichkeiten viel wandeln kann. Womöglich haben sich aber auch Ihre Anforderungen verändert – und sei es nur, weil ein Mitbewerber sich anders auf dem Markt positioniert hat.

Als moderne und agile Agentur, organisieren wir unsere internen Arbeitsabläufe mit Scrum. Durch die Vielfalt unserer Aufgabenstellungen, gehen wir mit manchen Projektstationen individuell um. Im Nächsten Blogbeitrag: “Scrum in der Praxis. Agile Agentur”, geben wir Einblicke in unseren Agenturalltag und beschreiben wie wir bei blankid mit Scrum umgehen.