Agiles Arbeiten bei GFE Media

Arbeiten mit dem Projektmanagement-Framework SCRUM

GFE Media arbeitet seit einiger Zeit aus Basis des Projekt­management-Frameworks „Scrum“. Was bedeutet der Einsatz von Scrum? Was waren für GFE Media die Gründe für den Umstieg? Die Antworten finden Sie im folgenden White Paper.

Management Summary

Der nachfolgende Essay befasst sich mit der Einführung des agilen Projektmanagement-Frameworks Scrum, bei welchem die Mitarbeiter vollständig in die Planung und Umsetzung von Projekten einbezogen sind. Gemeinsam wird entschieden, wie man von der Planung bis zur Abgabe vorgehen möchte, es entscheiden genau diejenigen, die eine Aufgabe auch lösen sollen.

Scrum-basiertes Projektmanagement bedeutet eine Absage an herkömmliches Wasserfall-basiertes Projektmanagement und bekannte Befehls- und Kontroll-Organisation. Mitarbeiter erhalten unter Scrum keine möglichst genauen Arbeitsanweisungen, dafür aber klare Zielvorgaben, für deren Umsetzung sie als gesamtes Team zuständig sind.

In der Praxis der Software-Entwicklung bei GFE Media und anderswo bedeutet der Einsatz von Scrum u. a. das Arbeiten mit den Rollen des Product Owners, des Entwicklungsteams und des Scrum Masters. Der Product Owner ist verantwortlich für die Definition der Anforderungen an ein Produkt, die er entsprechend priorisiert und deren Umsetzung er am Ende eines „Sprints“ abnimmt. Der Scrum Master stellt sicher, dass das Team operativ und produktiv arbeiten kann und räumt möglichst alle Hindernisse aus dem Weg. Das Entwicklungsteam organisiert sich selbst und ist verantwortlich für die Erreichung der selbstgesteckten Sprint-Ziele. Wie sich herausstellen sollte, passt Scrum nicht nur optimal zu den konkreten Arbeitsanforderungen bei GFE Media, sondern fügt sich auch nahtlos in die bislang gepflegte Unternehmenskultur.

I. Agility Requirements

Aktuelle Anforderungen an Agilität

Die Scrum-Geschichte bei GFE Media nimmt ihren Ausgangspunkt im Frühjahr des Jahres 2018, als wegen zunehmend komplexer Anforderungen bei mehreren parallel laufenden Softwareprojekten die bisherige Organisation und Projektplanung in personeller und technischer Hinsicht an ihre Grenze gestoßen waren und das Unternehmen vor der Aufgabe stand, deutlich flexibler, reaktiver, schneller, beweglicher und auch resilienter, kurz „agil“ zu werden.

Agiler hinsichtlich der allgemein üblichen Arbeitsplanung in Gantt-Diagrammen¹ nach dem Wasserfallverfahren, agiler hinsichtlich großvolumiger Vorausplanungen in Wandzeitungs-großen Poject-Ausdrucken, Riesen-Excels und epischen „Pflichten-Büchern“. Agiler auch hinsichtlich des Schnürens von großen Arbeitspaketen mit mehreren 100 Stunden durch Mitarbeiter, die dann die Aufgabe oft gar nicht selbst bearbeiteten und agiler schließlich auch hinsichtlich solipsistischen Abarbeitens solcher Aufgaben durch einzelne Experten.

Alles Änderungsanforderungen, die sich nicht zuletzt auch aus dem Wandel der Firma von einer klassischen Web-Agentur zum Web-Software-Entwickler und Systemintegrator ergaben, welcher zu neuen Komplexitäten und Skalierungsanforderungen geführt hatte und genau die genannten Änderungen in Sachen Agilität erforderte. Durch entsprechende Beschäftigung mit neuen Arbeitsmethoden stellte sich bald „Scrum“ (scrum engl. „Gedränge“) als mögliches Projektmanagement-Verfahren heraus.

II. Scrum Concept

Scrum-Grundlagen und -Prinzipien

Die Befassung mit dem von Jeff Sutherland und Ken Schwaber entwickelten Projektmanagementverfahren oder Vorgehensmodell Scrum², welches im Kontext von Software-Entwicklung, aber auch für industrielle Anwendungen z. B. bei Toyota entwickelt worden war, ergab interessante Perspektiven, hinsichtlich höchst plausibler Verfahrens­ansätze ebenso wie hinsichtlich wichtiger unternehmenskultureller Axiome. Ziel des Einsatzes von Scrum ist die effektive Entwicklung anspruchsvoller Software-Systeme, die nicht durch die Aufstellung detaillierter Lasten- und Pflichtenhefte erfolgt, sondern durch eine inkrementelle und empirische Planungs- und Umsetzungs-Methode, welche die gewünschten Merkmale und Funktionen in einem gemeinsamen Prozess zwischen den Stakeholdern und den Entwicklern Stück für Stück hervorbringt.

Inkrementelle Entwicklung

Inkrementelle Entwicklung steht hierbei für eine Ablaufplanung, in der verschiedene überschaubare Teile eines möglicherweise auch hochkomplexen Software-Systems in unterschiedlichen Teilen und Zeitfenstern entwickelt und in das Gesamtsystem integriert werden. Diese Vorgehensweise basiert auf der Erfahrung, dass viele Entwicklungsprojekte einfach zu komplex sind, um vorab in einen präzisen Ablauf-Plan gefasst zu werden, vor allem deswegen, weil wesentliche Teile einer gewünschten Lösung zu Beginn allen Beteiligten noch völlig unklar sind. Diese anfängliche Unklarheit wird durch die Erstellung von funktionsfähigen Teillösungen Stück für Stück reduziert, indem während der Arbeit fehlende Anforderungen festgestellt und notwendige Lösungstechniken leichter gefunden werden können als dies in einer abstrakten Klärungsphase vor Beginn der Entwicklungs­arbeiten möglich wäre.

Deshalb wird in Scrum nicht nur das Produkt selbst, sondern auch die Produktplanung inkrementell erstellt, wobei die längerfristige Planung (Product Backlog) fortlaufend verfeinert und optimiert wird, während der Detailplan (Sprint Backlog) nur für die jeweils nächste Arbeitsphase und damit den nächsten Sprint erstellt wird.³. Damit wird durch den Einsatz von Scrum natürlich nicht die Komplexität eines Projektes reduziert, dieses aber in kleinere und weniger komplexe Bestandteile, die Inkremente, zerlegt und damit leichter fassbar und handhabbar gemacht.

Empirische Arbeitsweise

Die Anforderung an eine empirische Arbeitsweise wird dadurch sichergestellt, dass der jeweilige Fortschritt wie auch alle Hindernisse eines Projektes regelmäßig und für alle sichtbar festgehalten werden (Transparenz), dass Projektergebnisse (Inkrements) und ablauffähige Funktionalitäten regelmäßig implementiert und bewertet werden (Überprüfung) und dass alle Anforderungen an das Produkt und an die Vorgehensweise nicht von vornherein festgeschrieben, sondern kontinuierlich angepasst werden (Anpassung).

Sprint und Sprint Planning

Eine zentrale Rolle spielt hierbei der so genannte Sprint und damit ein Arbeitsabschnitt, in dem in einem interdisziplinären Team ein Inkrement mit einer bestimmten Produkt­funktionalität entwickelt und umgesetzt wird. Ein typischer Sprint umfasst ein Zeitfenster von ein bis vier Wochen und beginnt immer mit einem Sprint Planning zur Erstellung des sogenannten Sprint Backlogs. Die konkrete Frage lautet: Was genau kann im kommenden Sprint durch das Entwicklerteam entwickelt werden? Wie wird im Detail vorgegangen, welche Tasks müssen zum Erreichen des Sprint-Ziels und zur Lieferung der vorgesehenen Product-Backlog-Einträge definiert und bewältigt werden. Sprint Planning erfolgt durch das Entwicklungsteam, der Product Owner steht für Rückfragen an das Product Backlog zur Verfügung. Ergebnis ist wie erwähnt das Sprint Backlog und damit ein genauer Fahrplan für den nächsten Sprint, während dem keine Änderungen erlaubt sind, die das Sprint-Ziel beeinflussen und gefährden können.⁴

Den Abschluss einer solchen Sprint-Phase, die von allen Beteiligten gemeinsam verantwortet wird, bildet stets ein Sprint Review und eine Sprint-Retrospektive. Beim Sprint Review wird das aktuelle Inkrement durch das Team vorgestellt und auf die zugesagten Eigenschaften hin überprüft. Wurde das zu Beginn gesteckte Ziel erreicht, muss das Product Backlog eventuell angepasst werden? Die bei diesem Event anwesenden Stakeholder besprechen die Ergebnisse mit dem Team. Bei der Sprint-Retrospektive überprüft das Scrum Team gemeinsam und ohne die Anwesenheit von Stakeholdern seine bisherige Arbeitsweise, um diese in Zukunft noch besser zu gestalten. Jetzt ist vor allem auch der Scrum Master gefragt, der das Scrum Team darin unterstützt, Verfahrensweisen und Verbesserungen zu finden, die beim nächsten Mal umgesetzt werden können.

Konventioneller Projektablauf im Gegensatz zu einem Scrum-Projekt

Abildung nach Jens Richterich⁵.

III. Scrum Values and Procedures

Scrum-Wertehorizonte und -Verfahren

Was sind nun die Key Values bei der Scrum-Arbeitsweise? Nach dem Scrum-Verfahren zu arbeiten, bedeutet, die Mitarbeiter umfänglich in die Planung und Umsetzung von Projekten zu involvieren und diese demokratisch und partizipativ in sämtliche Abläufe zu integrieren. Gemeinsam wird entschieden, wie man vorgeht, von der Planung bis zur Abgabe an den Kunden. Diejenigen, die eine Aufgabe lösen sollen, die entscheiden auch, wie sie gelöst werden soll. Es entscheiden also immer Teams und nicht Einzelne. Und was ein solches Team einmal entschieden hat, das hat zu gelten und kann z. B. im Falle von Sprint-Zielen auch durch das Management nicht geändert werden. Was also zählt, sind die Scrum Teams und nicht mehr irgendwelche Einzelstars, jeder hat seine Stimme im Team und jeder wird gleich behandelt. Teams und Teamarbeit formen die Organisation des Betriebes bei voller Transparenz.

Scrum-basiertes Projektmanagement bedeutet damit die Absage an autoritäre Führung in der Software-Entwicklung, Befehls- und Kontroll-Organisation und an klassisches Top-Down-Management. Mitarbeiter erhalten hier gerade keine möglichst genauen Arbeits­anweisungen, dafür aber klare Zielvorgaben, für deren Umsetzung sie als Team zuständig sind. Innerhalb interdisziplinär besetzter Teams bekommen die Mitarbeiter den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial selbständig zu entfalten. Auf diese Weise können die 2001 innerhalb des sog. „Agilen Manifestes“ von Ken Schwaber, Jeff Sutherland und anderen formulierten Werte agiler Software-Entwicklung umgesetzt werden:

• Menschen und deren Austausch untereinander sind wichtiger als Prozesse und Werkzeuge.
• Funktionsfähige Software ist wichtiger als maximale Dokumentation.
• Vertrauensvolle Zusammenarbeit mit dem Kunden geht vor ausgefeilten Vertragswerken.
• Anpassung an Veränderung ist wichtiger als sture Planverfolgung.

Damit sind Hierarchien unter Scrum weitgehend überflüssig. Menschen sind eben Menschen und keine Ressourcen und genau deshalb liegt der Fokus auf den Menschen und auf der Zusammenarbeit derselben als selbstständigen Individuen im Team.

In praktischer Hinsicht bedeutet Scrum bei GFE Media damit die Absage an Handling von großen Projekten, die über Monate und Jahre geplant und in langen Pflichtenheften und Excel-Sheets antizipiert werden, ganz einfach deshalb, weil die Realität stets anders aussieht als dies in noch so bunten Gantts über z. B. „MS-Project“ geraten werden kann.

Scrum bedeutet auch deswegen die Absage an klassische PM-Methoden, weil beim Wasserfall-Verfahren die Kunden nicht in ausreichendem Maße in die Entwicklung einer Software eingebunden werden können. Unter Scrum reduzieren frühe und regelmäßige (Zwischen-)Lieferungen das Risiko des Scheiterns eines Softwareprojektes. Frühes Feedback eliminiert unnötigen Stress durch Missverständnisse und damit Zeit- und Ressourcen-Verschwendung. Und ganz besonders wichtig ist die Tatsache, dass funktionierende Softwarestände abgeliefert werden und damit der zukünftige Anwender frühzeitig in die softwareseitige Umsetzung seiner Funktionsanforderungen eingeführt wird und rechtzeitig Protest einlegen kann.

Darstellung in Anlehnung an https://www.online-projektmanagement.info/agiles-projektmanagement-scrum-methode/scrum-versus-wasserfallmodell/ (letzter Zugriff: 22. Februar 2019)

Und last but not least bedeutet Scrum auch deshalb die Absage an bisherige Projektmanagement-Formen, weil sich die Anforderungen an eine Softwarelösung ständig ändern und deshalb in ihrer Gänze eben nicht vollständig vorausgeplant werden können, bzw. im Umkehrschluss möglicherweise komplett an aktuellen Marktanforderungen vorbei entwickelt werden. Je umfangreicher Projekte vorausgeplant werden und je länger Projektlaufzeiten angesetzt werden, umso mehr besteht die Gefahr, an realen Markt­erfordernissen und aktuellen technischen Entwicklungen vorbei zu programmieren.

Und deshalb wird unter Scrum (klein-)inkrementell und in überschaubaren Einheiten gearbeitet und nicht mit langen Zeiteinheiten und mit Pflichtenheften goetheschen Ausmaßes, sondern in kurzen und überschaubaren Arbeitseinheiten, die in kurzen Zeitfenstern zu bewältigen sind. Arbeiten vor allem auch mit funktionierenden Zwischenständen echt funktionierender Software am Ende einer solchen Arbeitseinheit. Dies unter maximaler Einbindung des Kunden, der nicht erst nach Monaten mit entsprechenden Ergebnissen überrascht wird, die er sich dann oft doch komplett anders vorgestellt hatte. Arbeiten mit Scrum bedeutet, so zu arbeiten, dass aktuelle Markt­entwicklungen Eingang in eine konkrete Software-Entwicklung finden können und eben nicht Features und Funktionen gebaut werden, die nach Fertigstellung kein Mensch mehr braucht. „Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten und der Erkenntnis, dass ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.“⁶

IV. Scrum Predefined Roles

Arbeiten mit klar definierten Rollen:
Product Owner, Entwicklungsteam, Scrum Master

In der Praxis der Software-Entwicklung bedeutet der Einsatz von Scrum auch das Arbeiten mit neuen Rollen und Spielregeln. Das Scrum Framework unterscheidet drei wichtige Rollen: den Product Owner, das Entwicklungsteam und den Scrum Master.

Der Product Owner ist verantwortlich für die Definition der Anforderungen an ein Produkt, die er entsprechend priorisiert und deren Umsetzung er am Ende eines Sprints abnimmt. Der Scrum Master stellt sicher, dass das Team operativ und produktiv arbeiten kann und räumt möglichst alle Hindernisse aus dem Weg. Das Entwicklungsteam organisiert sich selbst und ist verantwortlich für die Erreichung der Sprint-Ziele.

Product Owner

Der Product Owner trägt die Verantwortung für die Eigenschaften und Charakteristika eines Produktes, deshalb erstellt und priorisiert er die zu entwickelnden Produkteigenschaften ebenso wie er über das Erreichen der vereinbarten Sprint-Ziele befindet. Er ist als Person für alle Eigenschaften und die Reihenfolge deren Implementierung zuständig, die im sogenannten „Product Backlog“ festgehalten, geordnet, detailliert und aktualisiert werden.

Darüber hinaus verständigt sich der Product Owner mit dem Entwicklungsteam über die Kriterien, nach denen eine neue Funktion als fertiggestellt zu betrachten ist, wobei das Ziel eines jeden Sprints ein prinzipiell auslieferbares Produktinkrement darstellt, welches hinreichend getestet und in entsprechende Umgebungen integriert ist, um für potentielle Benutzer freigegeben zu werden.

Team

Das Entwicklungsteam ist für die Lieferung der vom Product Owner definierten Produkt­funktionalitäten in der gewünschten Reihenfolge zuständig und trägt die Verantwortung für die Qualität des Produktes. Wie bereits erwähnt, organisiert sich das Entwicklungsteam komplett selbst und nimmt weder vom Management noch vom Scrum Master Anweisungen zur Umsetzung der Sprint-Backlog-Einträge entgegen.⁷

Durch die interdisziplinäre und cross-funktionale Besetzung der Entwicklungsteams, z. B. mit Architekten, Entwicklern, Testern, Designern und Datenbankexperten, sollten diese in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Gemäß des Scrum-Reglements wird die Qualität einzelner Sprint-Ergebnisse immer auf das Entwicklungsteam als Einheit bezogen und im negativen wie im positiven Falle grundsätzlich nie einzelnen Teammitgliedern angelastet.⁸

Zu den Aufgaben eines aus mindestens drei und höchstens neun Mitgliedern bestehenden Entwicklerteams zählt auch die Schätzung des Umfangs der Einträge eines Sprint-Backlogs, ebenso wie die Aufbereitung der für einen Sprint ausgewählten Einträge (Sprint Backlog) in sogenannte „Tasks“ und „Subtasks“.

Scrum Master

Der Scrum Master ist für die Einführung und Umsetzung von Scrum verantwortlich, überwacht die Einhaltung der entsprechenden Regeln und kümmert sich um die Behebung von Störungen und Hindernissen wie z. B. mangelnde Kommunikation und Zusammen­arbeit, persönliche Konflikte, Unstimmigkeiten zwischen Product Owner und Entwicklungsteam sowie Störungen von außen, wie beispielsweise die Bearbeitung zusätzlicher Aufgaben während eines Sprints oder irgendwelche Einmischungen von Seiten des Managements.

Ein Scrum Master versteht sich gegenüber dem Entwicklungsteam als Coach, gehört dem Entwicklungsteam aber selbst nicht an und gibt Team-Mitgliedern auch keine Arbeitsanweisungen. Der Scrum Master sorgt dafür, dass der Projektfortschritt durch geeignetes Reporting für alle Beteiligten transparent ist.

V. Scrum Fixed-Price Offer

Festpreisangebote leider ausgegangen

Scrum-Festpreisangebote sind ein Widerspruch in sich selbst und können nur schwerlich funktionieren. Entweder man betreibt eine inkrementelle Entwicklung in enger Abstimmung mit dem jeweiligen Product-Owner bzw. „Stakeholder“, deren Ausgang und Ausmaß zu Beginn eines gemeinsamen Prozesses noch gar nicht absehbar ist und vielfältigen gemeinsam zu vertretenden Planänderungen unterliegt, oder man kennt das genaue Ausmaß aller notwendigen Aufwendungen, welche man in feste Budgets gießen kann.

Während man früher von der Kalkulierbarkeit solcher fester Budgets in beliebigen Größenordnungen ausging, scheint dies aus besagten Gründen immer unmöglicher zu werden. Die genannte Unmöglichkeit, alle erforderlichen Aspekte einer komplexen Projektentwicklung korrekt vorherzusagen, macht Software-Entwicklung zum Glücksspiel, bei dem entweder der Software-Anbieter oder der Kunde gewinnt, je nachdem, wie viel Sicherheitspolster vorher auf die geforderte Leistung (auf-)kalkuliert worden war. Unangenehm für den Kunden, wenn zu viel Sicherheitsabstand aufgerechnet wurde, Pech für den Software-Hersteller, der am Ende langwieriger Projekte feststellen musste, dass er draufgezahlt hat. Dies besonders bei Projekten, bei denen außer dem jeweiligen Entwickler niemand die Software vor Abgabe zu Gesicht bekommen hatte, was im Normalfall zu vielfältigen Zusatzwünschen auf Kundenseite führte, die aus Sicht des Kunden gerne Gegenstand der bisherigen Beauftragung darstellten.

All dies führt im besten Falle zu Frustration auf beiden Seiten und im schlechtesten Fall zu Misstrauensbildung oder gar richtigem Ärger. Deshalb setzt Scrum hier auf totale Transparenz und auf die permanente Mitwirkung des Kunden, vertreten durch einen Product Owner aus dem Hause des Kunden, oder eben auf einen „Proxy“-Product-Owner auf Seiten des Software-Herstellers, der in engster Abstimmung mit dem Kunden alle Entwicklungsschritte und damit verbundene Kosten freigibt.

Umdenken angesagt

Die neue Arbeitsweise unter Scrum erfordert ein erhebliches Umdenken auf Anbieter- wie auch auf Kundenseite. Während die Finanzabteilungen auf Anbieterseite bislang mit festen Größenordnungen eingehender Zahlungen aus Anzahlungs- und Schlussrechnungen planen konnten, stehen jetzt lediglich Schätzungen über potentielle Projektgrößen zur Verfügung, die in einzelnen Inkrementen zur Abrechnung kommen, deren genauer Abrechnungszeitpunkt von konkreten Sprintläufen und Abnahmen des Product Owners abhängt.

Während die Finanzabteilungen auf Kundenseite konkrete Budgets in ihre Jahresausgaben einstellen konnten, müssen sie sich unter Scrum mit Aufwandsschätzungen für das Gesamtprojekt zufrieden geben, die unter oder über den ursprünglich veranschlagten Größenordnungen liegen können. Verbindliche Angebote gibt es nur für die einzelnen Sprints eines Softwareprojektes. Fachabteilungen müssen sich unter Umständen vor ihrem Management rechtfertigen, welches nur begrenzte Mittel für eine bestimmte Software-Entwicklung zur Verfügung stellen möchte oder überhaupt zur Verfügung hat. Hier könnte systematischer Ärger vorprogrammiert sein, sollte sich das Management nicht auf agile Entwicklungsverfahren einlassen können.

Management integrieren und Vorteile an allen Fronten einsammeln

In jedem Falle ist dringend angeraten, insbesondere auch das Management – auf beiden Seiten – mit auf den agilen Weg zu nehmen und vor Projektbeginn klarzustellen, dass weder auf der Einnahmenseite noch auf der Ausgabenseite mit festen Preisen gerechnet werden kann, wenn Entwicklungsprozesse in der beschriebenen Form erfolgen. Klar sollte aber auch auf beiden Seiten sein, dass gewaltige Vorteile locken, die für den Software-Hersteller darin liegen, nach Umstellung der Arbeitsweise auf Scrum die eigenen Kapazitäten besser planen und auslasten zu können, weil in cross-funktionalen Teams Prozesse agiler parallelisiert werden können und vor allem, weil bei kleineren Leistungseinheiten weniger Fehlplanung und geringerer Nachbesserungs-Aufwand besteht. Der Vorteil auf Kundenseite liegt ebenfalls auf der Hand: Wird doch zu Kosten, deren Entstehung kleinteilig (mit-)beeinflusst werden kann, genau dasjenige entwickelt, was tatsächlich gebraucht wird und genau den Anforderungen entspricht, die wiederum der jeweils eigene Markt vorgibt.

VI. Transition to Scrum – Shift Happens

Scrum im Betrieb real umsetzen

Unternehmen, die sich in Ablösung traditioneller Wasserfall-Methoden auf den Weg der Agilität machen, stehen vor vielfältigen Herausforderungen, die es im täglichen Arbeitsablauf zu meistern gilt – GFE Media auch! Dies gilt für die oben beschriebenen finanzwirtschaftlichen Umstellungen ebenso wie für die Gestaltung fast aller Abläufe im Hause.

Nachdem die Umstellung auf Scrum nicht im abstrakten Raum stattfindet, sondern im Rahmen mehrerer bereits laufender Projekte, mit unterschiedlichen Kunden und höchst verschiedenen Anforderungsprofilen, mussten nicht nur verschiedene Projekte parallel auf Scrum umgestellt werden, sondern im einen oder anderen Falle auch ohne Scrum – und damit traditionell – zu Ende geführt werden.

Insbesondere auch der Umstand, dass nicht der ganze Entwickler-Stamm auf nur eine Aufgabe angesetzt werden kann, führt zu operativen Herausforderungen. Welche cross-funktionalen Teams können überhaupt gebildet werden? Welche Fähigkeiten und Erfahrungen, vor allem auch konkrete Vorerfahrung mit den betreffenden Software-Projekten und Kunden, stehen zur Verfügung? Wie viele Projekte können gleichzeitig mit den neuen Agilitäts-Axiomen parallel laufen? Wie sind die traditionellen Arbeitsweisen mit der neuen Verfahrensweise zu harmonisieren? Wie ist der Entwicklungsstand in den einzelnen parallel laufenden Software-Projekten? Wer ist wie weit? Was kann abgerechnet werden, was wird nach welcher Methode abgerechnet, wer behält den Überblick?

Hier empfiehlt es sich, zumindest für den Zeitraum der Transition zu Scrum, die bisherigen Projektmanager voll funktional eingesetzt zu lassen, auch wenn diese nach Scrum eigentlich nicht länger vorgesehen sind, sondern durch die Doppelrolle von Scrum Master und Product Owner abgelöst werden sollen.

Eine wichtige Neuerung im betrieblichen Ablauf stellen die Daily Scrums dar, welche die Teams zu einem max. 15-minütigen Event versammeln, bei denen ein Überblick über den aktuellen Stand der Arbeit gegeben wird. Zweck des Daily Scrum war ursprünglich der Informationsaustausch, bei dem berichtet wird, was seit dem letzten Daily Scrum erreicht wurde und was dabei im Wege stand. In der Praxis bei GFE Media haben sich Daily Scrums als konkrete lösungsorientierte Arbeitsbesprechungen etabliert.

Eine Herausforderung kann z. B. während der Transition-Zeit die längerfristige Vorausplanung von Projekten hinsichtlich Personaleinsatz, Fertigstellungstermin, Abrechnungszeitpunkt etc. darstellen. Dies weil die Unterschiedlichkeit bislang eingesetzter Methoden zum neuen Scrum-Verfahren und die Ablösung herkömmlicher Projektverwaltungssoftware leicht zu zeitweisen Unübersichtlichkeiten führen kann. Außerdem erfordert die Einführung und der effiziente Betrieb von Scrum Tools, wie z. B. Jira, Geduld und die Bereitschaft, Prozesse immer wieder zu überprüfen und neu zu definieren.

Aber auch die Entwicklungsabteilungen selbst sehen sich plötzlich ganz neuen Verantwortungen gegenüber, Aufgaben und individuelle Anforderungen ändern sich und wachsen: So ist es u. U. nicht ganz selbstverständlich, dass alle Beteiligten die neuen interdisziplinären Anforderungen akzeptieren, sich von bislang gewohnten Arbeitsweisen gerne verabschieden und z. B. als Entwickler nun auch QS-Aufgaben wahrnehmen und die produzierte Software tatsächlich auch noch selber testen sollen. Testen, dokumentieren, präsentieren, Style Guides erstellen, vielleicht ungewöhnliche, aber höchst wichtige Parallel-Anforderungen, die darauf basieren, maximale Teambildung, Flexibilität und Agilität auszubilden, weil ein sich gegenseitig verstärkendes Team potentiellen Unwägbarkeiten besser gewachsen ist als eine lose Sammlung individueller Talente.

Allergrößte Chancen für den Scrum-Einsatz ergeben sich gerade an dieser Stelle bei der umfassenden Teambildung. Wie vielfältig dokumentiert, kann aus der konstruktiven Zusammenarbeit unter Scrum etwas ganz Besonderes passieren: Durch die gemeinschaftliche Form des Planens, Umsetzens und Kontrollierens von Software-Entwicklung entsteht eine neue Qualität der Zusammenarbeit, welche zu einer Art gemeinsamen „Abhebens“ des Teams führen kann. Interessanterweise führt die kooperative Zusammenarbeit in cross-funktionalen, interdisziplinären Teams eben nicht zu verstärkter gegenseitiger Behinderung, sondern ermöglicht im Gegenteil verschärfte gegenseitige Verstärkung, durch die ein deutliches Mehr an Programmierungs-Power, Begeisterung und Projektfortschritt zu Tage treten kann. Dies vor, während und nach den jeweiligen Sprints, geprägt von dem Bemühen, immer noch Besseres gemeinsam zu schaffen.

VII. Beuys to Scrum

Unternehmenskultur und Agilität

Neben jeder Menge leicht nachvollziehbarer, funktionaler Plausibilität gibt es weitere gute Gründe, der neu gewählten Arbeitsweise gerade bei GFE Media weiter zu folgen: GFE Media ist seit vielen Jahren einer eigenen Unternehmenskultur verpflichtet, die in Verbindung mit dem Gestaltungsansatz der „Sozialen Plastik“ des Künstlers Joseph Beuys entstanden war: „Jeder Mensch ein Künstler“. Dieses Arbeitsprinzip setzt auf die Mitgestaltung jedes Menschen an seinem gesellschaftlichen und auch wirtschaftlichen Umfeld.

Die bislang gepflegte Unternehmenskultur bestand im Wesentlichen darin, Mitarbeiter wie Erwachsene zu behandeln, dies mit der naheliegenden Erwartung, dass diese sich dann ebenfalls wie Erwachsene verhalten würden. Deshalb war die Arbeit bei GFE Media geprägt von der Überzeugung, je mehr Selbstbestimmung und je mehr Freiräume im Alltag ermöglicht werden, umso besser. Und zwar genau deshalb, weil Unternehmen aus Erwachsenen und der Sache nach gleichberechtigten Menschen bestehen und eben nicht aus Arbeitskräften und Produktivfaktoren.

Die bisherige Arbeitsweise bei GFE Media war deshalb immer schon darauf ausgerichtet, Mitarbeiter möglichst ihre Arbeit selbst planen und einteilen zu lassen. Dies genau wie bei Scrum, möglichst ohne von außen in die Arbeit hinein zu regieren, im Sinne von unnötigem Kontrollieren, Schikanieren, Puschen und Stressen, im Sinne von vorgesetzten Software-Leitern und einer veralteten Chef-Struktur. Ganz im Gegenteil ging es bei der GFE Media-Unternehmenskultur mehr um die Schaffung der Möglichkeit, mitzureden bei allen Projekten, mitzuentscheiden, was wie gemacht wird. Kurz, eben möglichst selbstorganisiert zu arbeiten! In der Praxis bedeutet dies, möglichst keinen Druck auf Mitarbeiter auszuüben, keine extrinsische Motivations-Spielchen mit den Mitarbeitern zu spielen und eher auf Motivation aus Einsicht in gemeinsam erarbeitete Notwendigkeiten und Verfahren zu setzen, die innerhalb eigens anberaumter Mitarbeiter-Workshops definiert worden waren.

Wie man sieht, gibt es jede Menge Übereinstimmung der Scrum-Verfahrensweise mit der GFE Media-Unternehmenskultur und den bisherigen Gestaltungs-Ideen für die Zusammenarbeit im Betrieb. Arbeitsweisen, die natürlich zu keinem Zeitpunkt final eingeführt und abgeschlossen sein können und deshalb jeden Tag neu umgesetzt und jeden Tag neu gewollt werden müssen, ganz abgesehen davon, dass natürlich auch Scrum selbst sich ständig weiterentwickelt.
 

Ergänzung Februar 2020:

Einen Zwischenbericht über die Scrum-Transition bei GFE Media finden Sie hier.

Literatur- und Link-Verzeichnis

• Kriegisch, Alexander, „Scrum – auf einer Seite erklärt.“. https://scrum-master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert (letzter Zugriff: 22. Februar 2019).
• Pichler, Roman, Scrum: Agiles Projektmanagement erfolgreich einsetzen. Heidelberg: dpunkt Verlag, 2007.
• Richterich, Jens, „Scrum versus Wasserfall: Ein Vergleich.“. https://www.online-projektmanagement.info/agiles-projektmanagement-scrum-methode/scrum-versus-wasserfallmodell/ (letzter Zugriff: 26. Februar 2017).
• Schwaber, Ken und Jeff Sutherland, „The Scrum Guide: The Definitive Guide to Scrum:The Rules of the Game.“. href=“https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf (letzter Zugriff: 21. Februar 2019).
• Schwaber, Ken, Jeff Sutherland und u. a., „Manifest für Agile Softwareentwicklung.“. https://agilemanifesto.org/iso/de/manifesto.html (letzter Zugriff: 20. Februar 2019).
• Scrum Alliance, „Agile Atlas.“. https://www.scrumalliance.org/learn-about-scrum/agile-atlas (letzter Zugriff: 20. Februar 2019).

Anmerkungen

1. Ein Gantt-Diagramm – auch Balkenplan genannt – stellt im klassischen Projektmanagement die zeitliche Abfolge von Aktivitäten des Gesamtprojektes grafisch in Form von Balken auf einer Zeitachse dar.
2. Ken Schwaber und Jeff Sutherland, „The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game.“ (November 2017). https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf (letzter Zugriff: 21. Februar 2019).
3. Siehe z. B. https://de.wikipedia.org/wiki/Scrum#Sprint_Backlog (letzter Zugriff: 21. Februar 2019).
4. Scrum Alliance, „Agile Atlas.“. https://www.scrumalliance.org/learn-about-scrum/agile-atlas (letzter Zugriff: 20. Februar 2019).
5. Jens Richterich, „Scrum versus Wasserfall: Ein Vergleich.“. https://www.online-projektmanagement.info/agiles-projektmanagement-scrum-methode/scrum-versus-wasserfallmodell/ (letzter Zugriff: 26. Februar 2017).
6. Alexander Kriegisch, „Scrum – auf einer Seite erklärt.“. https://scrum-master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert (letzter Zugriff: 22. Februar 2019).
7. Schwaber und Sutherland, „The Scrum Guide“.
8. Roman Pichler, Scrum: Agiles Projektmanagement erfolgreich einsetzen (Heidelberg: dpunkt Verlag, 2007). S. 15.