Herausforderung Scrum

Das Berufsbild des Softwareentwicklers hat sich rasant verändert. Der Begriff Software Engineering entstand in den 50er Jahren und mit ihm die ersten Debatten darüber, was "Engineering" in Bezug auf die Entwicklung von Software überhaupt bedeutet. Diese Diskussion erhielt 1968 und 1969 durch zwei vom NATO Science Committee geförderte Konferenzen weiteren Auftrieb, und Zeitzeugen behaupten, dass dies die Wiege der (groß-)industriellen Softwareentwicklung gewesen sei. In den folgenden Jahrzehnten entstanden diverse Prozessmodelle zur standardisierten Softwareentwicklung - eher aus der Not geboren und um die Kosten der Softwareentwicklung transparenter zu machen sowie einen Mindeststandard für Softwarequalität zu garantieren. Die bekanntesten Vertreter sind das Wasserfallmodell (1970), das V-Modell (1986), das Spiralmodell (1988), Scrum (1995), Rational Unified Process (1999) und das V-Modell XT (2005).

Kern all dieser Ansätze ist der Versuch, die Unsicherheiten von großen Softwareprojekten im Hinblick auf Kosten, Funktionalität, Laufzeit und Qualität beherrschbar zu machen. Der agile Lösungsansatz unterscheidet sich allerdings eklatant von dem der klassischen Modelle und verändert die Arbeit von Softwareentwicklern und dem IT-Management.

Lösungsansatz "klassisches Vorgehen"

Die klassischen Modelle basieren auf der Idee, die Erfahrungen aus industriellen Fertigungstechniken wie dem Maschinen- oder Automobilbau auf die Softwareentwicklung zu übertragen. Hieraus ergibt sich zum einen die Trennung einzelner Aufgaben wie Konzeption, Architektur, Realisierung, Qualitäts-Management und Steuerung, also eine klare Einteilung der Mitarbeiter hinsichtlich Tätigkeiten und Fähigkeiten. Zum anderen bedarf es klar strukturierter Regeln und meist sequenzieller Prozesse, um die Projekte steuern und kontrollieren zu können. Das V-Modell definiert zum Beispiel mehr als 20 Entscheidungspunkte, 31 Rollen, 118 Produkte und 89 Aktivitäten.

Lösungsansatz "agiles Vorgehen"

Die Grundlage für die Zusammenarbeit aller an einem agilen Softwareprojekt Beteiligten wurde 2001 unter anderem von Ken Schwaber und Jeff Sutherland in dem "agilen Manifest" definiert.

Dieses Manifest nennt vier Kernpunkte:

1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.

2. Funktionierende Programme gelten mehr als ausführliche Dokumentationen.

3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.

4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Dieser Ansatz geht davon aus, dass es möglich ist, mit der kurzen, aber klaren Darstellung einer fachlichen Vision, einem interdisziplinären Team, einem quasi sofortigen Start der Realisierung und einer schnellen Feedback-Schleife (neue Software kann sofort durch den Auftraggeber getestet und bewertet werden) auf einen großen Overhead zu verzichten und ein mindestens gleichwertiges oder sogar besseres Ergebnis in Bezug auf Funktionsumfang, Projektlaufzeit, Qualität, Kosten und Kundenzufriedenheit zu erzielen. Verzichtet wird auf komplexe Rollen und Regelwerke, vorgelagerte Konzeptionsphase (Lasten-/Pflichtenhefte) und nachgelagerte Testphase.

Dass hier zwei Weltsichten aufeinanderprallen, steht außer Frage und wird vermutlich auch weiterhin zu intensiven Diskussionen führen. Die Einführung agiler Methoden in mittlerweile über 30 Prozent der Unternehmen und in Projekten, an denen drei bis mehr als 200 Mitarbeiter beteiligt sind, zeigt laut einer aktuellen Forrester-Studie, dass diese Arbeitsweise aus der IT-Welt nicht mehr wegzudenken ist.

Die Einführung agiler Vorgehensweisen, also "eigentlich simpler" Vorgehensmodelle, führt allerdings zu großen personellen und persönlichen Umstellungen etwa in Bezug auf Hierarchie, Verantwortung, Zuständigkeit, Eigenständigkeit, Ansprechpartner, Selbstdefinition, Sicherheitsempfinden, gefühlte Kontrolle, Vertrauen und Respekt.

Scrum, das derzeit am weitesten verbreitete Verfahren, zeigt die Auswirkungen im Vergleich zu klassischen Strukturen sehr deutlich. In der Praxis kommen meist mehrere agile Verfahren und Techniken in Kombination zum Einsatz.

Auswirkung auf die Organisationsstruktur

Klassische IT-Organisationen sind häufig streng hierarchisch aufgebaut und bilden entweder die Applikationslandschaft oder die Organisationsstrukturen der Fachbereiche mit den dafür benötigten Applikationen nach. Oft ist diese Struktur mit zusätzlichen Stabsstellen für Projektleitung als Brückenkopf zwischen der IT und den Fachbereichen und mit weiteren Querschnittsfunktionen, etwa für Architekturthemen, versehen.

Scrum-Teams sind prinzipiell interdisziplinär besetzt, um alle fachlichen Anforderungen autark realisieren zu können. Sie liegen somit quer zu den klassischen Strukturen (siehe Grafik "Scrum-Teams sind interdisziplinär besetzt"). Zudem erfolgt die komplette Aussteuerung aller Tätigkeiten innerhalb der agilen Teams. Eine Steuerung über die klassische Struktur ist nicht nur überflüssig, sondern auch explizit untersagt.

Konsequenz dieses Arbeitens ist:

• Die Hierarchieebenen flachen ab;

• Aufstiegsmöglichkeiten im klassischen Sinne entfallen zum Teil;

• Die Verantwortungsbereiche der verbleibenden Führungspositionen und aller beteiligten Mitarbeiter verändern sich stark.

Auswirkungen auf Zuständigkeiten

Das Organisationsgefüge wandelt sich durch die strenge Form der Gewaltenteilung, wie sie in Scrum implementiert ist. Der Grund liegt in der Entkopplung von Verantwortung, die in klassischen Organisationen über die hierarchische Struktur gebündelt ist.

Durch Scrum wird die klassische Teamstruktur aufgelöst. Die Steuerung der Projekte geht direkt an den Product-Owner, also den Fachbereich, während die Verantwortung für Realisierung und Qualität an die Entwickler übertragen wird. Mehrere, voneinander unabhängige Scrum-Teams können gleichzeitig an einem System arbeiten. Somit greifen die klassischen Kontroll- und Steuerungsmechanismen ins Leere.

Auswirkungen für den IT-Mitarbeiter

Für IT-Mitarbeiter ändert sich das Berufsbild im agilen Umfeld am eklatantesten. Die Ursache hierfür ist nicht die Veränderung der tatsächlichen Tätigkeiten, sondern vielmehr der Umgang mit der konkreten Verantwortung, die direkt aus der Freiheit der agilen Methoden resultiert. Festzustellen ist, dass diese Rückkopplung in den Definitionen der agilen Vorgehensmodelle implizit enthalten ist, die Auswirkungen in Bezug auf die Verantwortung aber meist erst bei der realen Arbeit im Scrum-Team wahrgenommen werden.

Das bedeutet:

• Das Team arbeitet direkt mit dem Product-Owner zusammen. Der Buchtitel "Wer auftritt, muss spielen" des Dirigenten Christian Gansch stellt die Situation gut dar: Der IT-Mitarbeiter tritt aus dem (geschützten) Hintergrund und wird zu einem Akteur in der ersten Reihe - in direktem Kontakt mit dem Fachbereich. Die Mitarbeiter erhalten einen ganzheitlichen Blick auf die Bedeutung und die Wichtigkeit ihrer Arbeit für das Unternehmen, aber auch auf die Auswirkungen eines Scheiterns.

• Beschrieben wird nur die fachliche Vision, die den Leistungsumfang der zu realisierenden Software bis ins Detail wiedergibt. Eine Ausarbeitung der fachlichen Anforderungen (Story) erfolgt im Idealfall in direkter Zusammenarbeit von Product-Owner und Team. Quasi gleichzeitig beginnt die Realisierung. Die Herausforderung liegt hier in dem Mut, die Themen anzugehen, auch wenn sich später herausstellt, dass einzelne Teile der Software wieder weggeworfen oder neu gebaut werden müssen - ohne Netz und doppelten Boden.

• Das Team hat das Recht und die Pflicht, die Menge der Aufgaben zu bestimmen. Hierbei handelt es sich um einen fairen Deal. Das Team erarbeitet eigenständig, wie komplex die Aufgaben sind, und verspricht dem Product-Owner auf dieser Basis, eine bestimmte Menge fachlicher Anforderungen in einer bestimmten Zeit (Sprint) und Qualität zu erfüllen. Dafür verspricht der Product-Owner, dem Team diese Zeit zu geben, ohne es mit wechselnden Anforderungen zu stören. Die Verantwortung bezüglich der Lieferung liegt nun voll in der Hand des Teams.

• Das Team muss dem Product-Owner die Herausforderungen und die Risiken bei der Realisierung der Anforderungen verständlich darlegen, um schnell und offen über mögliche Alternativen diskutieren zu können. Hierdurch entsteht eine direkte Transparenz bezüglich akuter und unangenehmer Probleme oder Fehleinschätzungen des Teams.

• Das Team arbeitet selbstorganisiert und eigenverantwortlich. Es ist für die Lieferung aller zugesagten fachlichen Arbeitspakete verantwortlich. Hierbei meint "Lieferung" hochwertige, getestete und lauffähige Software, die den vereinbarten Rahmenbedingungen entspricht. Wie das sichergestellt werden kann, liegt in der direkten Verantwortung des Teams. Fehlt Know-how, so muss es entscheiden, wer es bis wann aufbaut. Sinkt die Qualität der gelieferten Software, so müssen Verfahren zur Verbesserung erarbeitet werden.

• Das Team ist interdisziplinär besetzt, um alle Anforderungen des Product-Owners erfüllen zu können. Die Teilnehmer arbeiten somit an unterschiedlichen Systemen und haben die Möglichkeit, ihren Horizont zu erweitern. Auf der anderen Seite sind sie dazu auch dann gezwungen, wenn das Aufgabengebiet nicht zu ihrem (Interessen-) Schwerpunkt zählt. Ein weiterer Aspekt, der hierdurch entsteht, ist der gefühlte Verlust der eigenen Zuständigkeit oder "Wichtigkeit", da dies in klassischen Strukturen oft über "Ich verantworte Modul A aus System B" erfolgt. Im agilen Umfeld wechselt der Fokus hingegen von der Spezialisierung des Einzelnen hin zu der Leistung des Teams.

Durch diese öffentliche Situation kann bei den Mitarbeitern ein hohes Unsicherheits- und Druckgefühl entstehen, das durch eine gelebte Kultur des Respekts und der Toleranz aufgefangen werden muss.

Auswirkungen für das IT-Management

Die Verantwortung des Managements beschränkt sich auf die disziplinarische Führung des Personals, die Systeme (Architektur, Betriebsprozesse, Technologie, Qualität) und das Budget. Die Steuerung erfolgt vollständig über die Personalentwicklung, die Definition von Rahmenbedingungen und die Einteilung der Mitarbeiter zu den Scrum-Teams.

Der entscheidende Punkt ist, dass der IT-Manager keinen Einfluss darauf hat, woran seine Mitarbeiter arbeiten und ob Mitarbeiter aus anderen Abteilungen an dem System arbeiten, das er verantwortet.

Eine weitere Frage ist, wie der IT-Manager, als Verantwortlicher für ein System, aus seiner Sicht wichtige Refactoring-Maßnahmen umsetzen lassen kann, da er kein direkt für ihn arbeitendes Team hat.

Der IT-Manager muss sich folgenden Fragen stellen:

• Wie kann die Qualität des Systems, das er verantwortet, ohne direkten Einfluss auf die Entwicklung sichergestellt werden?

• Wie kann eine Personalentwicklung ohne direkten Einfluss auf die konkrete Arbeit der Mitarbeiter erfolgen?

• Wie sind Zielvereinbarungen zu gestalten?

• Wie werden Refactoring-Themen umgesetzt?

• Wie reagiert man auf die eigene Unsicherheit und das Gefühl des Kontrollverlusts?

Das IT-Management muss den Umgang mit den scheinbar unkontrollierten Mitarbeitern neu erlernen und sich auf seine eigentliche (neue?) Verantwortung einstellen.

Diese liegt einerseits in der Förderung der Mitarbeiter hinsichtlich Kultur, Technologien, Zielen und andererseits in der Erarbeitung, der klaren Kommunikation und Messung von Rahmenbedingungen für Softwarequalität und Prozesse.

Glossar

Scrum

Scrum ist ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle entwickelt und etabliert wurde (Ursprung: Englische Bezeichnung für das angeordnete Gedränge im Rugby-Sport).

Scrum-Team

Ein Scrum-Team besteht aus drei Rollen: dem Product-Owner, dem Scrum-Master und dem Team, also den Entwicklern, deren Aufgabe es ist, die Anforderungen der Fachabteilung umzusetzen.

Sprint

Ein Sprint ist der Iterationszyklus, in dem die Scrum-Teams arbeiten. Die Dauer ist für das Team fest definiert und sollte zwei bis vier Wochen betragen.

Story

Beschreibung von Anforderungen, die den fachlichen Bedarf und den Geschäftsnutzen, aber nicht die Art der Umsetzung beschreiben. Beispiel: Für den Betreiber eines Internet-Shops soll das System unmittelbar Bestellbestätigungen an die Käufer versenden, damit die Käufer sich sicher fühlen, dass ihre Bestellung erfolgreich eingegangen ist, und nicht im Call-Center anrufen müssen.

Burn-Down-Chart

Eine Grafik, die den Stand der Abarbeitung der Aufgaben von 100 bis 0 Prozent darstellt.

Product-Owner

Der Product-Owner vertritt die fachliche Auftraggeberseite. Er ist verantwortlich für die Priorisierung der Anforderungen und den Nutzen für das Unternehmen.

Scrum-Master

Der Scrum-Master ist der Hüter der vereinbarten Prozesse. Er sorgt für Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und versucht Verbesserungspotenziale zu erkennen und einzuführen.

Agile Methoden

Die agilen Methoden stellen einen konzeptionellen Rahmen für die Umsetzung von (Software-)Projekten dar. Im Fokus steht dabei ein schneller Start der Realisierung, eine flexible Reaktion auf Änderungen und ein schnellstmögliches Erbringen des echten Kundennutzens in Form funktionierender Software.

Die wichtigsten Veränderungen

• Der IT-Mitarbeiter tritt aus dem (geschützten) Hintergrund und wird zu einem Akteur in der ersten Reihe - in direktem Kontakt mit dem Fachbereich.

• Die Herausforderung liegt im Mut, die Entwicklung anzugehen, auch wenn sich später herausstellt, dass einzelne Teile wieder weggeworfen oder neu gebaut werden müssen.

• Das Team hat das Recht und die Pflicht, die Menge der Aufgaben zu bestimmen.

• Die Verantwortung bezüglich der Lieferung und der Qualität liegt in der Hand des Teams.

• Das Team arbeitet selbstorganisiert und eigenverantwortlich.

• Der Fokus wechselt von der Spezialisierung des Einzelnen hin zu der Leistung des Teams.

• Das IT-Management hat keinen Einfluss darauf, an welchen Projekten und Systemen die Mitarbeiter arbeiten.

• Das IT-Management muss den Umgang mit den scheinbar unkontrollierten Mitarbeitern neu erlernen und den Fokus auf seine eigentliche (neue?) Verantwortung lenken.