Agiles Vorgehen bei der Softwareentwicklung in Großunternehmen

Scrum, aber mit Projektleiter?
Keine Kommentare

Scrum in Großunternehmen, geht das überhaupt? Wenn viele Teams, noch mehr Interessen und zahlreiche Legacy-Lösungen im Spiel sind, stellt das erschwerte Bedingungen für das agile Arbeiten dar. Das heißt aber nicht, dass es nicht gelingen kann, auch Großunternehmen agil zu machen.

Es ist inzwischen über 20 Jahre her, dass mit Scrum eine Alternative zum klassischen Projektvorgehen entworfen wurde. Obwohl einer der Vorreiter und Evangelisten von Scrum, Ken Schwaber, nicht der Erfinder dieser Methodik ist, wird doch sein Name stets mit der agilen Revolution im Softwareentwicklungsprozess verbunden.

Scrum unterstellt, dass Softwareprojekte ab einer gewissen Komplexität grundsätzlich nicht mehr planbar sind, da im Projektverlauf zu viele unvorhersehbare Ereignisse auftreten können und werden. Es lohnt, sich den Begriff der Komplexität nochmal ins Gedächtnis zu rufen: „Ein Softwareprojekt gilt als komplex, wenn der Umfang als nicht gering anzusehen ist und die Anforderungen vorab nicht exakt formuliert werden können.“

IT Security Summit 2019

Sichere Logins sind doch ganz einfach!

mit Arne Blankerts (thePHP.cc)

Hands-on workshop – Hansel & Gretel do TLS

mit Marcus Bointon (Synchromedia Limited)

 

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Vielleicht wird der eine oder andere Leser jetzt bemängeln, diese Definition sei nicht exakt messbar. Diese weichen Definitionen muss man aber einfach akzeptieren und mit Hilfe seiner persönlichen und IT-technischen Erfahrungen konkretisieren. Wer dennoch eine kleine Interpretationshilfe benötigen sollte: Ein Softwareprojekt ist sehr komplex, wenn mehr als zwei Entwickler beteiligt sind und der Projektverantwortliche nicht in 15 Minuten erklären kann – inklusive vollständiger Beantwortung meiner Rückfragen –, was genau umzusetzen ist. Eine Erweiterung einer Schnittstelle um ein genau definiertes Feld wird daher in der Regel nicht als komplex angesehen.

Hingegen findet man gerade in Großunternehmen meist Architekturen vor, die sich zum einen über viele Layer und Systeme erstrecken und damit auch ebenso viele Personen beteiligt sind. Zum anderen gelten viele dieser Systeme als Legacy, was nichts anderes bedeutet, als dass sich die Schöpfer beziehungsweise Experten für die internen Strukturen des Systems nicht mehr im Unternehmen befinden. Schließlich haben auch die Fachbereiche oft nur eine grobe Idee (aka Vision), was mit dem Projekt erreicht werden soll.

Mit anderen Worten: ideale Voraussetzungen für die Anwendung von Scrum.

Abschied vom Wasserfallmodell

Laut diverser Studien aus den Jahren 2007 und 2008 mussten bis dato die meisten IT-Großprojekte als gescheitert betrachtet werden. Genaue Zahlen sind schwierig zu nennen, da oftmals gescheitere IT-Vorhaben nach außen als Erfolg verkauft werden. Kritische Quellen sprechen von maximal einem Fünftel aller Projekte, die in Time und Budget und zur Zufriedenheit der Auftraggeber umgesetzt wurden. Was allerdings nicht strittig ist, ist der komplette vorzeitige Abbruch von ebenfalls einem Fünftel aller Projekte und dem damit einhergehenden Verlust aller bis dahin investierter Geldern. Während der goldenen Zeiten konnten, gerade im Bankenumfeld, diese verbrannten Gelder durch noch höhere Beträge auf der Einnahmenseite ausgeglichen werden. Dagegen muss spätestens seit der Finanzkrise 2008 jeder Euro im Projektbudget hart erkämpft und im Review verantwortet werden. Angesichts dieser Rahmenbedingungen – schlechte Erfolgsquote und wenig Budget – suchte man nach einer Silver Bullet für die Probleme bei der Umsetzung von IT-Projekten und wurde fündig bei Scrum.

Scrum-Rollen

Das Schöne an Scrum ist die Einfachheit des Verfahrens, wie in Abbildung 1 dargestellt: Es gibt nur drei Rollen innerhalb eines Scrum-Teams und nur wenige Artefakte beim Vorgehen. Die wichtigsten Mitglieder eines Teams sind die Entwickler. Der Grund dafür ist, dass das Entwicklerteam die Verantwortung für die Lieferung des Inkrementes nach der vorher festgelegten Sprintdauer von meist zwei Wochen übernehmen soll.

Daneben gibt es den Produkt Owner, der die Aufgabe hat, das Projekt über die Erstellung und Priorisierung von Stories zu steuern. Schließlich gehört noch der Scrum Master zum Team, dessen Aufgabe es sein sollte, sich selbst überflüssig zu machen, indem er die Einhaltung des agilen Prozesses so lange überwacht und die anderen Teammitglieder in der Umsetzung coacht, bis beides nicht mehr nötig ist.

Als Faustregel sollte ein Scrum-Team aus etwa sieben Entwicklern bestehen. Bei mehr als zehn Entwicklern greifen gruppendynamische Prozesse und das Team zerfällt in mehrere Grüppchen. Daher sollte man die Aufgaben bei größeren Projekten nach dem Prinzip „teile und herrsche“ so schneiden, dass die Teams die richtige Größe haben. Die Abstimmung der Teams erfolgt dann im Scrum of Scrums, wo sich jeweils ein Vertreter der Entwickler aus jedem Team trifft.

Scrum, aber …

Die Theorie klingt einfach und funktioniert auch oft in kleineren Unternehmen. Je größer das Unternehmen, desto eher wird aber versucht, Scrum zu adaptieren. Leider wird dadurch meist der Nutzen des agilen Vorgehens ganz oder teilweise zerstört. Hier die wichtigsten drei Adaptionen, von Ken Schwaber liebevoll „Scrum, but“ genannt:

… der Projektleiter leitet das Projekt

Fakt ist: Scrum kennt keinen Projektleiter, daher gibt es diese Rolle nicht mehr. Leider wird aus genau diesem Grund in größeren Unternehmen, die mit dem agilen Modell starten wollen, oft der Fehler gemacht, die Scrum Master aus den Reihen der Personen zu rekrutieren, die bis dato lange Jahre als Projektleiter tätig waren. Damit meint man gleich zwei Fragen zu beantworten, nämlich zum einen „Woher nehme ich die Scrum Master?“ und zum anderen „Was mache ich mit meinen Projektleitern?“. Leider werden dadurch neue Probleme geschaffen, da die Rolle des Scrum Masters meist falsch interpretiert wird. Ein Scrum Master hat die Aufgabe, für ein Einhalten des Scrum-Prozesses zu sorgen, die Eigenverantwortung im Team zu fördern und Probleme und Widerstände (Impediments) zu beseitigen.

Ein klassischer Projektleiter nimmt dagegen meist steuernde und leitende Aufgaben wahr und dieser Anspruch ist meist nicht von heute auf morgen abzulegen wie ein Kleidungsstück. Wohin also mit den Projektleitern, deren Know-how und Erfahrung ein kostbares Gut im Unternehmen ist, aber deren Skills als Leiter und Steuerer in dieser Form nicht mehr benötigt werden? Ein Projektleiter könnte sich zum Produkt Owner entwickeln, wenn er ausreichend fachliches Know-how mitbringt, er bereit ist, sich auf diese Rolle einzulassen und Mikromanagement der Teammittglieder zu vermeiden. Ein Projektleiter sollte aber niemals – zumindest nicht ohne vorherige Schulungen und Coachings – zum Scrum Master ernannt werden.

In Großunternehmen gibt es vorhandene Strukturen, die sich nicht von heute auf morgen ersetzen lassen. Gerade bei den Mitarbeitern entstehen teilweise Existenzängste, wenn revolutionäre Verfahren umgesetzt werden sollen und die eigene bisherige Rolle nicht mehr im Zielbild auf irgendwelchen Organigrammen erscheint. Diese Ängste gilt es von vorneherein zu beseitigen, damit der Start in die agile Welt gelingen kann.

… das Managementreporting muss erhalten bleiben

Fakt ist: Es gibt in Scrum maximale Transparenz, nämlich zum einen durch das Burndown Chart über das Sprint Backlog, zum anderen über die nach dem Sprint stattfindende Review, wo den Stakeholdern das Inkrement vorgestellt wird. Scrum lässt keine andere Art von Reporting zu, da es das Team in seiner Arbeit stören und an der Erbringung der zugesagten Arbeit hindern würde.

Dies reicht aber dem Management in größeren Unternehmen meist nicht aus. Die Angst vor der Übergabe der Verantwortung der Kontrolle an das Scrum-Team ist groß und das Misstrauen, dass ein selbstorganisiertes Team ohne Eingriff vom Manager arbeiten soll, ist größer. Der oben beschriebene Wegfall des Projektleiters verstärkt dieses Misstrauen noch, da manchem Manager seine gewohnte Reportinglinie abhandenkommt.

Ein deutliches Indiz dafür, dass man sich definitiv auf dem falschen Weg befindet, ist die Zweckentfremdung des Daily Scrum als Statusmeeting, wo der Projektleiter sich – in welcher Rolle auch immer – von jedem Teammitglied den Status abholt. Wie kann also im agilen Vorgehensmodell das Management zufrieden gestellt werden? Zum einen sollte das Scrum-Team ein Sprint Backlog führen und auch aktuell halten. Aus dem Burndown Chart ist dann – nach dem Update des Sprint Backlog im Daily – tagesgenau der Fortschritt ablesbar. Wird für die Verwaltung der Backlogs ein Tool benutzt wie zum Beispiel Jira, dann ist der Projektstatus jederzeit aktuell abrufbar. Mehr Transparenz geht eigentlich nicht. Schließlich gibt es den Sprint Review, wo das Team dem Product Owner und allen Stakeholdern sowie dem Management das Inkrement vorstellt.

… wir haben keinen Product Owner

Fakt ist: Ohne Product Owner gibt es kein ordentliches Backlog und keine Priorisierung. Daher wird das Team mit hoher Wahrscheinlichkeit nicht in die richtige Richtung arbeiten. Vom Product Owner wird außerdem erwartet, dass er dem Team jederzeit als Ansprechpartner für aufkommende Fragen zur Verfügung steht. Da in größeren Projekten mehrere Fachbereiche beteiligt sind und der Product Owner das Mandat aller Fachbereiche benötigt, mag meist niemand diese Rolle übernehmen. Oft ist es auch so, dass jemand, der diese Rolle übernehmen könnte, zeitlich dazu nicht in der Lage ist. Oder es werden mehrere Product Owner benannt, die aber unterschiedliche Vorstellungen bezüglich der Prioritäten haben („mein Bereich zuerst“) und sich später im Sprint-Planungsmeeting nicht einig sind.

Dieses Problem ist in der Tat das kniffligste, das man in Großunternehmen lösen muss. Man kann sogar sagen, dass der Erfolg gefährdet ist, wenn diese Rolle nicht adäquat besetzt wird. Eine Patentlösung gibt es nicht, jedoch kann man zur Not, also wenn sich überhaupt kein Product Owner aus dem Fachbereich findet, die Rolle eines „Proxy Product Owner“ etablieren. Dieser kann und wird in der Regel aus der IT gestellt werden und wird normalerweise so arbeiten, dass er die Anforderungen auf der einen Seite und die Rückfragen des Teams auf der anderen Seite jeweils durchleitet und so für Priorisierung beziehungsweise Klärung offener Punkte sorgt.

Weitere Herausforderungen

Größere Projekte müssen, wie schon zuvor beschrieben, mit mehreren Scrum-Teams mit jeweils fünf bis zehn Personen gestemmt werden. Dabei sollte jedes Team interdisziplinär besetzt sein, so dass es sämtliche zugewiesenen Stories ohne Hilfe von außen lösen kann. In Großunternehmen sind die Abteilungen in der Regel jedoch nach Skills aufgeteilt. Zum Beispiel werden alle Datenbankentwickler in einer Gruppe, alle Java-Entwickler in einer weiteren und alle Hostentwickler in einer dritten organisiert sein, jeweils unter einem Bereichsleiter, der seine Mitarbeiter natürlich weiterhin organisiert und disziplinarisch betreut. Durch die Einsortierung in Scrum-Teams wird diese Struktur aufgebrochen und die Personen werden neu zugeordnet. Es müssen plötzlich Kollegen direkt zusammenarbeiten, die bisher nur am Telefon oder per Mail kommuniziert haben. Jeder, der sich mal mit Team-Building beschäftigt hat, wir sofort das Bild mit der Teamuhr vor Augen haben und wissen, dass die Neuformierung zunächst mal mit einigen Gewittern einhergehen wird, bevor man hoffentlich funktionierende und produktive Teams bekommt.

Wenn man diesen Schritt geschafft hat, dann steht man vor der Hürde, die Scrum-Teams untereinander zu koordinieren. Im besten Fall lässt sich das Projekt in mehrere Teile zerschneiden, die unabhängig voneinander bearbeitet werden können. Dann wird der Aufwand der Koordination sich auf die Etablierung eines gemeinsamen Build-Prozesses sowie der Festlegung auf gemeinsame Sprint-Intervalle beschränken. Sind dagegen die Arbeiten der Teams auf irgendeine Weise gekoppelt, ist ein „Scrum of Scrum“ nötig, der zum Austausch zwischen den Teams dient. Entgegen mancher Praxis sollte nicht immer die gleiche Person und auch nicht der Scrum Master in diese Runde entsandt werden, sondern möglichst eine Rotation stattfinden, damit jeder im Team involviert ist und ein Gefühl für die gemeinsame Sache bekommt.

Wie man Scrum in Großunternehmen retten kann

Falls bis hierher ein eher düsteres Bild entstanden sein sollte, habe ich eine gute und eine schlechte Nachricht: Die schlechte Nachricht ist, dass es tatsächlich in den meisten Fällen genauso düster aussieht. Die gute Nachricht ist, dass man über bestimmte Methoden dennoch gute Ergebnisse bei der Etablierung von Scrum in Großunternehmen erzielen kann. Als wichtigste Methoden seien hier die „Guerillataktik“ und das „Managementcoaching“ genannt.

Bei der Guerillataktik wird auf die Unterstützung des Managements zur Etablierung des Scrum-Prozesses verzichtet. Stattdessen versucht der Scrum Master oder auch ein Projektleiter, sämtliche schädlichen Einflüsse von außen vom Team fernzuhalten. Das geforderte Managementreporting in Form von MS-Project-Grafiken oder den allgegenwärtigen Ampelfolien übernimmt auch der Projektleiter, der aber das Team in Ruhe arbeiten lässt. Diese Taktik funktioniert innerhalb von Großunternehmen insbesondere für kleinere Projekten mit einem oder maximal zwei Teams.

Für das Management Coaching benötigt man eine starke Persönlichkeit in der Rolle des Scrum Master, der Coachingerfahrung mitbringt und das Management von der Sinnhaftigkeit und dem Nutzen des agilen Prozesses überzeugt. Als Argumente sollten immer die höhere Produktivität, eine bessere Transparenz und last but not least das geringere Projektrisiko angeführt werden. Am Ende sollten ein hundertprozentiges Commitment der Führungsebene sowie eine öffentliche Kommunikation des Managements zur Einführung des neuen Prozesses stehen.

Fazit

Es ist oft ein harter, steiniger Weg, ein echtes agiles Verfahren wie Scrum in Großunternehmen zu etablieren. Aber der Weg lohnt sich, denn sobald man erste Inselprojekte erfolgreich in Time und Budget abgeliefert hat, wird das Vertrauen bei den Mitarbeitern wie auch beim Management wachsen, und es wird leichter fallen, neue Projekte agil aufzusetzen. Am Ende hat vielleicht das komplette Unternehmen den Schritt in die Agilität geschafft. Der größte Widerstand wird von Mitarbeitern kommen, die um ihren Job fürchten, da sie sich im Scrum-Prozess nicht wiederfinden. Hier ist von Seiten des Managements und des Scrum Masters Überzeugungsarbeit zu leisten.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -