Viele Wege führen zum Ziel – Scrum und Großprojekte

Für den Einsatz agiler Methoden wie Scrum stellen Großprojekte eine enorme Herausforderung dar. In der Praxis sind Hybridlösungen aus traditionellen und agilen Vorgehensmodellen daher weit verbreitet. Oft bringen diese ein Projekt erst richtig in Fahrt, manchmal können sie sich jedoch auch als Irrweg erweisen. Der Beitrag betrachtet verbreitete Fallstricke in Scrum basierten Großprojekten und zeigt auf, wie man das Projektgeschehen wieder auf Kurs bringen kann.

Aufgrund ihrer besonderen Rahmenbedingungen mit komplexen Anforderungen, vielen Beteiligten, umfangreichen Softwareartefakten und einem oft schwierigen organisatorischen Umfeld stellen Großprojekte für das Projektmanagement eine enorme Herausforderung dar. Während bei der Planung und Steuerung umfangreicher Softwareprojekte in der Vergangenheit traditionelle Vorgehensmodelle wie das V Modell oder das Wasserfallmodell dominierten, erfreuen sich in jüngerer Zeit agile Ansätze wie Scrum zunehmender Beliebtheit. Schaut man allerdings genauer hinter die Kulissen, so ist gerade in Großprojekten nicht immer alles agil, wo Scrum draufsteht. Häufig sind Hybridlösungen aus traditionellen und agilen Vorgehensmodellen anzutreffen, die wissentlich oder auch unbeabsichtigt etabliert wurden um agile Methoden an die besonderen Rahmenbedingungen von Großprojekten anzupassen. Daraus resultiert die Chance, eine maßgeschneiderte Lösung zu finden, deren Effizienz und Effektivität unter den gegebenen Umständen einer Scrum Implementierung die streng dem Scrum-Guide folgt deutlich überlegen ist. Andererseits besteht ein Risiko einen faulen Ad-Hoc Kompromiss zu etablieren, der das Schlechteste aus beiden Welten miteinander vereint und alle Projektbeteiligten unnötig Zeit, Geld und Nerven kostet.

Nahezu jeder Entwickler der bereits in mehreren größeren agilen Projekt mitgewirkt hat, kennt die Situation mit 25 Kollegen morgens um 9 Uhr im Daily zu stehen. Mit viel Glück oder wenn der Scrum-Master penibel darauf achtet, die Redezeit der Anwesenden auf maximal eine Minute zu beschränken, ist das Meeting um halb 10 überstanden. Man darf allerdings stark bezweifeln, welchen Informationsnutzen die Teilnehmer aus einem Beitrag von höchstens einer Minute ziehen können. Für mehr als – ‚ich habe gestern an Ticket 6537 gearbeitet und heute mache ich Ticket 6545‘ wird es kaum ausreichen. Hinweise etwa auf unklare Anforderungen, Abhängigkeiten zu anderen Tickets oder Abstimmungsbedarf im Team aufgrund von Inkonsistenzen in der Softwarearchitektur – Fehlanzeige da keine Zeit. Selbst wenn doch einmal mehr besprochen wird, so rauscht das Meeting aufgrund der großen Zahl der Beiträge, wie ein Wasserfall an den Teilnehmern vorbei und es ist notwendig Notizen zu machen, um wenigstens die wichtigsten Themen im Blick zu behalten.

Ein kurzes, konzentriertes und effektives Daily ist mit 25 Personen nicht möglich. Nicht ohne Grund fordern die Autoren des Scrum-Guide eine Beschränkung der Teamgröße auf maximal 9 Personen. Erreicht werden kann dies, indem große Teams in Feature Teams aufgeteilt werden. Ein teamübergreifender Informationsaustausch ist möglich, indem sich Vertreter der Feature Teams regelmäßig zu einem sogenannten Scrum of Scrums treffen. Ein zu großer Teilnehmerkreis im Daily lässt sich ebenso vermeiden, indem funktionale Teilteams wie Entwicklung, Test oder Betrieb anstatt einem gemeinsamen jeweils ein eigenes Daily abhalten und wechselseitig Vertreter zu den Meetings der anderen Teams schicken. Dies widerspricht zwar dem Cross-Functional Team Ansatz der Scrum Methodik, kann aber in Einzelfällen mehr nutzen als schaden.

Ein Beispiel aus dem Projektalltag ist ein Team, welches ein gemeinsames Daily von Entwicklung, Test und Betrieb abgehalten hat. Nachdem wiederholt aufgefallen ist, dass ausufernde und für die Entwickler wenig informative Diskussionen über Probleme im Test und auf den Produktivumgebungen das Daily auf bis zu 90 Minuten aufgebläht hatten, wurde entschieden, das Entwickler Daily in einem kleineren Kreis abzuhalten und teamübergreifende Themen in separaten Terminen zu diskutieren.

Nicht nur ein XXL Daily kostet produktive Zeit, sondern auch ein Übermaß an sonstigen Besprechungen und Terminen. Zu den Scrum Regelterminen addieren sich in Großprojekten oft noch Meetings wie Scrum of Scrum, Grooming, Jour-Fixe, Architekturworkshops, Schätzrunden, Statusmeetings oder Treffen für den Informationsaustausch mit Stakeholdern. Häufig werden diese Termine mit einem viel zu großen Personenkreis abgehalten, was in der Konsequenz dazu führt, dass der Großteil der Teilnehmer gelangweilt die Zeit absitzt oder das Meeting aufgrund der Anzahl an Wortmeldungen regelmäßig den geplanten zeitlichen Rahmen sprengt. Die Meetingzeiten summieren sich dann selbst für Entwickler schnell auf mehr als 10 Stunden pro Woche. Für Softwarearchitekten oder Entwickler in Team-Lead Positionen mitunter auch mal das doppelte. Dabei ist zu Bedenken, dass jede Arbeitsunterbrechung zusätzlich Zeit kostet, da anschließend wieder eine gewisse Einarbeitung in das zuletzt bearbeitete Thema erforderlich ist.  

Es ist daher im Interesse des Projektes auf unproduktive Meetings, die vor allem der Einhaltung organisatorischer Prozesse dienen zu verzichten und den Teilnehmerkreis auf jene Personen zu beschränken, die am besten zum Erfolg eines Meetings beitragen können. Um das Abschweifen in Detailfragen und allzu philosophische Diskussionen zu unterbinden, ist es hilfreich eine Agenda sowie eine Timebox vorzugeben und bei der Moderation auf eine Fokussierung auf die wesentlichen Ziele des Treffens zu achten.

Die Flexibilität von Scrum beruht im Wesentlichen auf intensiver Kommunikation innerhalb des Projektteams und regem Austausch mit den Stakeholdern. Dies ermöglicht es auf bürokratische Prozesse und Regeln zu verzichten und offene Fragen oder Diskussionspunkte auf dem kurzen Dienstweg zu klären. Da die Stakeholder das Projekt kontinuierlich begleiten, können Anforderungen entsprechend knapp formuliert werden. Wenn während der Implementierung einer User Story fachliche Lücken oder Unklarheiten auftauchen, lassen sich diese zeitnah im Dialog klären. Soweit die Theorie. In der Praxis zeigt sich, dass gerade sehr umfangreiche Projekte kein Scrum Wunschkonzert sind. Bei mehr als 100 Beteiligten ist die Anzahl der Stakeholderanfragen potentiell deutlich höher als in einem Projekt mit 10 Personen. Wenn Stakeholder dann auch noch Aufgaben ausserhalb des Projektes haben und nicht im Minutentakt gestört werden wollen, werden oft Regeln installiert, um Anfragen zu bündeln und zu kanalisieren. Damit wird genau das untergraben, was mit Scrum eigentlich erreicht werden soll – schnelle und unkomplizierte Kommunikation. Stakeholderfeedback ja, aber bitte nur zur Sprechstunde Dienstag und Donnerstag zwischen 13 und 14 Uhr.

Wenngleich das Team den Arbeitsalltag der Stakeholder zu respektieren hat, so muss diesen dennoch bewusst sein, dass eine zügige Klärung offener Fragen im ersten Moment vielleicht unbequem ist, aber letzten Endes dem Fortschritt des Projektes dient.

Wenn Stakeholder aufgrund ihres Wissens oder ihrer Funktion durch das Team besonders stark in Anspruch genommen werden, so müssen Maßnahmen ergriffen werden, um die Anfragen auf mehr Köpfe zu verteilen. Es müssen Stellvertreter bestimmt und das Wissen an weitere Personen – auch innerhalb des Projektteams weiter gegeben werden. Jede Frage oder Unklarheit die innerhalb des Teams bereinigt werden kann, muss nicht an Stakeholder weiter eskaliert werden.

Auch innerhalb des Projektteams kann die Kommunikation in einem großen Team für den einzelnen sehr anstrengend werden. Je mehr Mitglieder ein Team hat, umso größer ist die potentiell mögliche Anzahl an Kommunikationswegen.

Was das im Einzelfall bedeuten kann, lässt sich am besten anhand eines Beispiels illustrieren. Man stelle sich vor, man ist für die Entwicklung einer Querschnittskomponente wie der Rollen- und Rechteverwaltung verantwortlich. Irgendwann wird diese Komponente innerhalb des Projektes zur Verwendung freigegeben. Ob 10, 30 oder gar 100 Entwickler gleichzeitig damit beginnen die Querschnittskomponente zu analysieren, zu integrieren, Tests zu schreiben – und Fragen zu stellen, macht einen gewaltigen Unterschied.

Eine mögliche Lösung für dieses Problem könnte darin bestehen, eine vollumfassende Dokumentation für die Querschnittskomponente zu schreiben und für das Team zugänglich zu machen. Allerdings bedeutet dies eine teilweise Abkehr von Scrum, da Dokumentation zwar nicht grundsätzlich abgelehnt aber zumindest kritisch gesehen wird, insbesondere wenn sie wie in der geschilderten Situation nicht Teil der auszuliefernden Software ist, sondern alleine der Kommunikationsunterstützung dient. Allerdings kann sie in diesem speziellen Fall Redundanz vermeiden, da grundlegende die Querschnittskomponente betreffende Fragen nicht wiederholt beantwortet werden müssen.

Abgesehen davon sollte das Wissen über Querschnittskomponenten grundsätzlich nicht bei einer Person liegen, sondern im Team möglichst breit gestreut werden.

Genauso wie ein Übermaß an Kommunikation zu Problemen führen kann, so ist es auch schädlich, wenn innerhalb des Teams zu wenig gesprochen wird.

In sehr großen Projekten werden die Teilteams häufig entsprechend der Funktion bzw. Aufgabe im Projekt gebildet. So zum Beispiel könnten Anforderungsanalysten und Tester, sowie Entwickler verschiedener fachlicher Komponenten oder Applikationsebenen wie ‚Backend‘ oder ‚UI‘ jeweils ein eigenes Team bilden. Um entsprechend des Cross-Functional Team Ansatzes eine nahtlose Zusammenarbeit der Teilteams zu ermöglichen, ist eine offene und flexible teamübergreifende Kommunikation notwendig. In der Praxis zeigt sich immer wieder dass Sprachbarrieren, eine räumliche Trennung sowie unterschiedliche zeitliche Verfügbarkeiten der Teilteams – etwa durch Meetingtermine oder Offshoreteams in anderen Zeitzonen, diesem Anspruch entgegen stehen.

Teamübergreifende Regeltermine wie ein Scrum of Scrum sind nur eine Möglichkeit, um den Informationsfluss zu verbessern. Darüber hinaus muss ein Gefühl gemeinsamer Verantwortung für das Projektergebnis geschaffen werden, damit eventuelle Probleme nicht einem anderen Team ‚über den Zaun‘ geworfen und nach dem Prinzip aus den Augen aus dem Sinn ignoriert werden. Ein interessanter Ansatz besteht darin, Projektmitglieder regelmäßig zwischen den Teams rotieren zu lassen. So zum Beispiel unterstützt ein Entwickler das Testteam und ein Tester wirkt im Requirement-Engineering mit. Dies erleichtert den Wissensaustausch zwischen den Teams und schafft ein Bewusstsein für die spezifischen Erfordernisse der jeweiligen Aufgaben.

Die Beschränkungen die sich durch Offshoreteams ergeben, müssen bei der Planung in besonderem Maße berücksichtigt werden, etwa um sicher zu stellen, dass das ohnehin schon begrenzte Zeitfenster in dem alle Teams potentiell füreinander erreichbar sind, nicht durch vermeidbare Termine noch weiter eingeschränkt wird.

Nicht zu unterschätzen ist die kommunikationsvermeidende Wirkung von Sprachbarrieren. In einem konkreten Fall wurde das Daily auf Englisch abgehalten, weil der teilnehmende Leiter des Nearshore-Testteams über keine ausreichenden Deutschkenntnisse verfügte. In der Folge schränkten einige Mitglieder des Entwicklerteams ihre Beiträge auf das notwendige Minimum ein, wodurch wichtige Punkte nicht oder zu spät zur Sprache kamen. Als Konsequenz wurde die Abstimmung mit dem Testteam in ein separates Meeting verlagert, um das Entwickler Daily wieder in deutscher Sprache und mit der gewohnten Kommunikationsqualität abhalten zu können.

In Teams die schon lange zusammen arbeiten existiert ein implizites Verständnis verschiedener Do’s und Dont’s, die für alle Mitglieder selbstverständlich sind. Diese Werte, Methoden und Praktiken sind soweit verinnerlicht, dass zum Beispiel niemand lange darüber nachdenken muss, dass der Merge von Feature Branches auf einen Hauptbranch mit Testfehlern keine gute Idee ist.

In großen Teams ist es deutlich schwieriger einen engen Zusammenhalt und ein daraus resultierendes Gefühl gemeinsamer Verantwortung für die Arbeitsweise sowie das Produkt zu etablieren. Ein implizites Verständnis bezüglich bestimmter Werte oder Praktiken bildet sich aufgrund der Teamgröße und hoher Fluktuation oft nur innerhalb eines kleinen Kernteams heraus. Zudem steigt aufgrund der geringeren sozialen Kontrolle die Bereitschaft z.B. aus Zeitmangel implizite Regeln bewusst zu missachten – ‚das juckt in dem großen Team doch keinen, wenn eine Story ausnahmsweise mal ohne Code-Review gemerged wird‘.

Um dennoch eine reibungslose Arbeit sicherstellen zu können, versuchen große Projekte den Mangel an gemeinsamem Verantwortungsgefühl, implizitem Verständnis und sozialer Kontrolle oft durch explizite Regeln und Prüfungen zu kompensieren. In der Konsequenz führt dies oft zu schwerfälligen und bürokratischen Abläufen, deren Kontrolle sowie Dokumentation die Teammitglieder davon abhält funktionierende Software zu entwickeln. In der Praxis findet man sperrige Regelwerke nicht nur für grundlegende Themen wie den Umgang mit Ticketstati oder der Definition of Done, sondern auch für Detailaspekte wie der korrekten Verwendung von SCM-Tools.

Dieser Verwaltungsoverhead könnte vor allem dann zum Problem werden, wenn der dafür benötigte zusätzliche Aufwand in Schätzungen nicht eingepreist ist oder vom Kunden bzw. Management nicht als Arbeitsleistung akzeptiert wird. Begünstigt wird dies dadurch, dass umfangreiche Projekte Aufwandsschätzungen oft nicht innerhalb der Teams durchführen, sondern diese von erfahrenen Teammitgliedern vornehmen oder gar vom Product-Owner mit dem Kunden bzw. Management verhandeln lassen. Das Ergebnis einer solchen Schätzung spiegelt dann oft mehr den politisch gewollten, als den tatsächlichen Aufwand wieder.

Für die Beteiligten wird eine regelkonforme Arbeitsweise dann schnell zum Luxus, da sie die dafür benötigte Zeit an anderer Stelle einsparen müssen. Dauert der Zeitmangel aufgrund wiederholt unrealistisch niedrig angesetzter Schätzungen länger an, so kann dies ein Projekt nachhaltig auf die schiefe Bahn bringen.

Früher oder später wird auch bei zeitaufwändigen aber essentiellen Praktiken wie Test-Automatisierung oder Code-Reviews geschludert, um Zeit für vergleichsweise unwichtige aber regulatorisch vorgeschriebene Aufgaben zu gewinnen. Wenn keine Gegenmaßnahmen eingeleitet werden, summieren sich diese Nachlässigkeiten zu hartnäckigen Qualitätsmängeln, lückenhafter Testabdeckung und technischen Schulden, welche die Zeitprobleme weiter verschärfen. Wird das Sprintziel erst ein paar mal gerissen, so verliert das Management oft die Geduld und legt das Team endgültig an die kurze Leine.

Auch wenn Interventionen des Managements in die Arbeitsweise des Teams im Kontext von Scrum eigentlich ein No-Go darstellen, so sind derartige Eingriffe in der Praxis keine Seltenheit. Beispiele hierfür sind tägliche Aufwandsbuchungen auf Taskebene, die Einführung von aufgabenbezogenen Checklisten oder die Zweckentfremdung des Dailys um detailliert den Status langer Listen von Tasks abzufragen.

Anstatt des gewünschten Zwecks, das Team wieder auf Kurs zu bringen, bewirken solche Versuche in der Regel das genaue Gegenteil. Wer Aufwände bucht oder Checklisten abhakt, kann in diesem Moment keine Software schreiben. Hinzu kommt der nicht zu unterschätzende psychologische Effekt, da dem Team suggeriert wird, dass man ihm nicht mehr vertraut und es unter verschärfter Beobachtung steht.

Der Gegenentwurf zu einem starren Korsett von Regeln und Richtlinien ist der weitgehende Verzicht des Projektmanagements auf eine Einmischung in die Belange des Teams. Dies entspricht zwar den Vorstellungen der Scrum-Macher, allerdings wird dabei von der Annahme ausgegangen, dass das Team seine Arbeit selbst organisiert.

Gerade große Teams tun sich damit aus den im vorangegangenen Abschnitt diskutierten Gründen oft schwer. Support durch einen Scrum-Master ist nicht immer selbstverständlich, da sich in Großprojekten oft mehrere Teams einen Scrum-Master teilen müssen und ein Team das Unterstützung nicht aktiv einfordert schnell zu kurz kommt. Das Resultat ist ein Wildwuchs an individuellen Sichtweisen, Praktiken und Vorgehensweisen. In der Praxis führt dies zu erhöhtem Abstimmungsbedarf, sowie einer schwieriger zu wartenden Software, etwa weil ähnliche Probleme durch unterschiedliche Teammitglieder verschiedenartig gelöst werden.

Für eine effektive Arbeit innerhalb des Scrumteams, ist dessen Fähigkeit zur Selbstorganisation unabdingbar. Dazu gehört auch, dass Schätzungen innerhalb des Teams vorgenommen werden.

Wenn ein Team dazu nicht in der Lage ist, so ist es Aufgabe des Scrum-Masters, den Problemen gemeinsam mit den Teammitgliedern auf den Grund zu gehen und Lösungen zu erarbeiten. Sofern der Scrum-Master zu der Einschätzung gelangt, dass es im Team nicht richtig rund läuft, sollte er auch von sich aus aktiv werden, anstatt darauf zu warten, dass sich die Teammitglieder an ihn wenden. Dabei ist es hilfreich, wenn er ausreichend Zeit hat um das Team kontinuierlich begleiten und zum Beispiel an den Daylies teilnehmen zu können und nicht nur sporadisch hereinschaut um zu fragen ob alles in Ordnung ist.

Dies setzt voraus, dass dem Projekt genügend qualifizierte Scrum-Master zur Verfügung stehen, um alle Teams kontinuierlich unterstützen zu können. Es reicht nicht aus, wenn ein Entwickler oder gar der Product-Owner neben seinen eigentlichen Aufgaben versucht notgedrungen in diese Rolle zu schlüpfen.

Um Teams bei ihrer Arbeit effektiv unterstützen und Hindernisse aus dem Weg räumen zu können, ist es wichtig, dass die Befugnisse der Scrum-Master nicht an den Grenzen des Projektteams enden. Konflikte ergeben sich oft nicht alleine innerhalb des Teams, sondern an den Schnittstellen mit dem organisatorischen Umfeld, wie etwa Stakeholdern, Management oder Betriebsführung. Um diese beilegen zu können, ist es notwendig, dass Scrum-Master dazu autorisiert sind auch mit diesen Stellen zu sprechen, Kompromisse zu erarbeiten und falls notwendig durchzusetzen.

Großen Projekten liegen oft Anforderungsdokumente im Umfang von mehreren tausend Seiten zugrunde. Damit der Spagat zwischen klassischem Requirements-Engineering und der agilen Welt gelingt, sollten diese in leichtgewichtige Konzepte wie Epics, Stories und Tasks heruntergebrochen werden.

Dabei ergeben sich einige überaus knifflige Herausforderungen. Anforderungen sind oft viel zu umfangreich, um sie in eine einzelne Story verpacken zu können, die potentiell innerhalb eines Sprints umgesetzt werden kann. Zu große Stories sind schwierig schätzbar, dümpeln teilweise über mehrere Sprints im Sprintbacklog vor sich hin und erschweren die Kontrolle des Projektfortschritts.

Das Aufsplitten großer Anforderungen in mehrere Teilstories führt wiederum zu Abhängigkeiten, welche die Verteilbarkeit der Aufgaben innerhalb der Teams einschränken. Während sich fachliche Abhängigkeiten bereits im Zuge der Anforderungsanalyse herauskristallisieren, ergeben sich technische Abhängigkeiten häufig erst deutlich später bei der Konzeption der Softwarearchitektur oder gar während der Implementierung.

Nicht oder zu spät erkannte Abhängigkeiten können zu erheblichen Störungen im Entwicklungsbetrieb führen. So zum Beispiel müssen Entwickler aufwändige Mocks für fehlende Schnittstellen bauen oder eine Komponente kann nicht richtig getestet werden, weil das UI das diese Komponente aufrufen soll noch nicht fertig ist.

Gerade aufgrund der großen Zahl an Stories ist es in umfangreichen Projekten wichtig, Abhängigkeiten zu erfassen und in Requirements-Engineering oder Issue-Management Werkzeugen zu verwalten. Dabei können komplexe Abhängigkeitsnetze entstehen, die bei der Release- und Sprintplanung unbedingt zu berücksichtigen sind.

In der Praxis ergibt sich dabei immer wieder das Problem, dass im Rahmen des Anforderungs- oder Projektmanagements Office-Anwendungen wie Word oder Excel verwendet werden, die keine effektive Nachverfolgung von Abhängigkeiten unterstützen. Aber auch bei der Verwendung ausgereifter Requirements-Engineering oder Issue-Tracking Lösungen, gibt es keine Garantie, dass diese sachgerecht genutzt werden. Oftmals scheitert es an fehlendem Know-How im Umgang mit diesen Werkzeugen oder am Durchhaltevermögen alle relevanten Storyattribute fortwährend zu pflegen. Gerade in stressigen Projektphasen oder nach Abschluss der Implementierungsarbeiten wenn ’nur‘ noch Test und Bugfixing auf der Agenda stehen, ist die Verlockung groß es bei der Backlogpflege nicht mehr ganz so genau zu nehmen.

Dabei ist das Wissen um Abhängigkeiten gerade in späten Phasen großer Projekte unersetzlich, etwa um nach einem Bugfix oder CR solide einschätzen zu können, welche Systemteile in besonderem Maße getestet werden müssen.

Abhängigkeiten können nicht nur fachlicher oder technischer, sondern auch organisatorischer Art sein. Ein Beispiel wo die agile und die nicht agile Welt oft brutal aufeinandertreffen, ist die Bereitstellung von Test- und Produktionsumgebungen durch den Applikationsbetrieb.

In Großprojekten werden diese zumeist durch eine andere Abteilung oder den Kunden, manchmal sogar durch einen externen Dienstleister geliefert. Die zuständigen Mitarbeiter sind nicht Teil des Scrumteams, sondern arbeiten nach einer eigenen Aufbau- und Ablauforgansiation die zum Beispiel auf Kanban basieren kann.

Damit die Zusammenarbeit funktioniert, muss der Applikationsbetrieb vom Scrumteam wissen, wie die benötigten Umgebungen konfiguriert werden müssen. Umgekehrt ist das Projektteam darauf angewiesen, dass die Umgebungen rechtzeitig bereitstehen.

In der Praxis gibt es hier oft Konflikte, da das Scrum Projekt vom Applikationsbetrieb eine Agilität und Flexibilität erwartet, die dieser organisatorisch bedingt nicht leisten kann. Wenn Umgebungen zu spät bestellt oder Konfigurationsänderungen spontan eingekippt werden, ist es nicht verwunderlich, dass es zu Verzögerungen kommt, bis diese mit den erwünschten Eigenschaften zur Verfügung stehen. Ein Test Driven Development basierter Ansatz, bei dem automatisierte Tests vor dem eigentlichen Programmcode geschrieben werden, scheitert dann oft schon aufgrund der noch fehlenden Infrastruktur zur Ausführung von Regressionstests.

Ist eine Nutzung extern bereit gestellter Ressourcen verbindlich, muss dieser Faktor bei der Planung daher so frühzeitig wie möglich berücksichtigt werden. Dies gilt nicht nur für die Beschaffung und Konfiguration einer Umgebung, sondern auch für die Implementierung des CI-Prozesses. Belange des Datenschutzes sowie der IT-Sicherheit können für das erste Deployment auf einer Produktivumgebung schnell zum Showstopper werden und sollten daher entsprechend adressiert werden. Wer später Zeit sparen und seine Nerven schonen möchte, muss sich in Sachen Infrastruktur auch über lästige Details wie die Bereitstellung von Logdateien aus Test- und Produktionsumgebungen Gedanken machen. In der Praxis bleiben gerade in Großprojekten viel zu viele Bugs unnötig lange liegen, weil das Team aufgrund sperriger administrativer Prozesse tagelang auf die zur Analyse benötigten Log-Files warten muss.

Alternativ können Teile der Betriebsführung auch in das Scrumteam integriert werden, was insbesondere dann relativ leicht umsetzbar ist, wenn eine cloudbasierte Infrastruktur verwendet wird, für die keine Hardware beschafft und eingerichtet werden muss.

Wenn eine Testumgebung endlich bereit steht, ist dies jedoch erst die halbe Miete. Effektiv testen kann das Team erst, wenn sie reproduzierbar mit Daten befüllt ist.

Auch hier tun sich Großprojekte oft schwer, weil die Erstellung und kontinuierliche Pflege von Testdaten aufgrund der hohen fachlichen Komplexität der Testobjekte mit einem enormen Aufwand verbunden sein kann.

Die denkbar schlechteste Möglichkeit damit umzugehen ist, die Testdatenerzeugung unkoordiniert den Entwicklern oder Testern unterzuschieben. Um wiederholte Arbeiten zu vermeiden, werden diese zumeist versuchen, die Testdatenerzeugung auf irgendeine Art zu automatisieren – ob durch Datenbankdumps, SQL-Skripte oder Testdatengeneratoren. Idealerweise findet das Team selbstständig eine einheitliche und für alle akzeptable Lösung. Gerade in Großprojekten besteht jedoch ein erhöhtes Risiko, das Teilteams oder gar einzelne Entwickler ihr eigenes Süppchen kochen, was zu einem Flickenteppich unterschiedlicher Lösungen führt. Abgesehen von der redundanten Arbeit, ist es für die Qualität der Testaktivitäten nicht förderlich wenn jeder mit unterschiedlichen oder auf andere Weise erzeugten bzw. manipulierten Daten testet. Die erzielten Testergebnisse lassen sich meist nicht zuverlässig reproduzieren oder auf einer anderen Umgebung nachstellen, was Bewertungen, Analysen und Diskussionen enorm erschwert.

Um dies zu vermeiden, ist es essentiell, die Frage der Testdatenerzeugung einheitlich für alle Teilteams des Projektes zu klären. Dabei sollte eine Lösung angestrebt werden, die zuverlässig konsistente Daten erzeugt und die zudem mit überschaubarem Aufwand verwendet und an Änderungen oder Erweiterungen der Software angepasst werden kann.

Dies kann z.B. ein Datenbankdump sein, der kontinuierlich auf den neusten Stand gebracht und zentral bereitgestellt wird oder ein automatisierter Importprozess der mit der zu testenden Applikation kontinuierlich mitwächst. Pragmatismus entsprechend dem KISS Prinzip ist dabei wichtiger als Perfektionismus, denn der ausgefeilteste fancy Testdatengenerator nutzt dem Projekt wenig, wenn er vom Team gemieden wird, weil er fehleranfällig oder unnötig kompliziert zu bedienen ist.

Großprojekte stellen eine besondere Herausforderung für das Projektmanagement dar. Wenngleich Scrum seine Stärken auch in diesem Umfeld ausspielen kann, so sind in der Regel Anpassungen an die speziellen Rahmenbedingungen des Projektes notwendig. Diese können von großem Nutzen sein, sich aber auch als katastrophale Fehlentscheidungen erweisen. Besonders fatal ist dabei, dass Großprojekte dazu neigen, an einmal getroffenen Entscheidungen gegen alle Widerstände festzuhalten. Anstatt die Ursache der dadurch entstandenen Probleme zu bekämpfen, wird an den Symptomen herumgedoktert und etwa einer schlechten Teamperformance – z.B. aufgrund zu optimistischer Schätzungen, unzureichender Fähigkeit des Teams zur Selbstorganisation oder mangelndem Scrum-Master Support mit der Vergrößerung des Teams oder engmaschigerem Controlling begegnet. Dies entfernt das Projekt nicht nur immer weiter von den Idealen von Scrum, sondern führt oft zu weiteren Verschlimmbesserungen.

Dabei bietet Scrum mit der Retrospektive ein geeignetes Werkzeug um die Arbeitsweise in den Teams sowie im Gesamtprojekt regelmäßig kritisch zu hinterfragen und falls notwendig anzupassen. Gerade Großprojekte sollten dieses Instrument mutig und konsequent nutzen, um sich von kostspieligen wie nervenaufreibenden Vorstellungen und Praktiken zu trennen.

Dennoch kann der Ansatz einen wertvollen Beitrag liefern, um die Risiken durch Updates, Konfigurationsänderungen oder Anpassungen von ERP-Systemen wie APplus zuverlässiger bewerten zu können.