Scrum in Real Life

Scrum ist das Thema, wenn es um Vorgehensmodelle in der Softwareentwicklung geht. Das Modell ist einfach und einleuchtend. Es gibt Antworten und Lösungen auf die typischen Fragestellungen und Probleme, welche sich bei herkömmlich geführten Softwareprojekten als echte Projektkiller herausstellen. So ist es auch kein Wunder, dass Scrum und agile Methoden generell seit ein paar Jahren die Softwareentwicklung im Team, in Projekten und Produktentwicklung massiv beeinflussen, ja, wenn nicht sogar umkrempeln.

Das Modell ist einfach und einleuchtend… in der Theorie. Doch wie sieht es in der Praxis aus?

Wir haben ein größeres Projekt mit Scrum abgewickelt und ich möchte hier ein wenig über die guten und erfolgreichen Punkte berichten, aber auch über die Dinge berichten, die verbesserungswürdig sind.

In der Theorie und der Literatur geht man bei der Beschreibung von Vorgehensmodellen immer von optimalen Verhältnissen aus, so auch bei Scrum.

Idealerweise wird ein Scrum Projekt von einem homogenen Team von 5-9 Entwicklern in Vollzeit und möglichst in einem gemeinsamen Büro abgewickelt. Es gibt ein Scrum-Board, einen Scrum Master und einen Product-Owner, der optimaler Weise ein Vertreter der Anwenderseite ist und final über die Umsetzung von Anforderungen entscheiden kann. Anwender finden sich regelmäßig zu den Sprint-Reviews ein und das Management kommt natürlich damit klar, dass es keinen „verantwortlichen“ Projektleiter mehr gibt, sondern das Team eine kollektive Projektverantwortung übernimmt. Der Projektowner, also der Budgetverantwortliche, hat natürlich auch kein Problem damit, dass er zu Projektbeginn nicht weiß, wofür er sein Budget bereitstellt, weil das Projektziel zwar definiert ist, jedoch nicht, wie dieses erreicht wird.

So viel zur Theorie, doch wie sieht die Realität aus?

In den seltensten Fällen findet sich ein homogenes Entwicklerteam zusammen, welches an einem gemeinsamen Standort arbeitet, ganz zu schweigen von einem gemeinsamen Büroraum. Bei räumlich verteilten Teams stellt der Einsatz eines Scrum Boards dann schon das erste Problem dar. Den Scrum-Master gibt es zwar meist, aber der Product-Owner mit Entscheidungskompetenz, der seine Aufgabe versteht und auch wahrnimmt, ist selten. Anwender finden sich selten zu den Sprint Reviews ein, und wenn, dann fehlt oft ein Verständnis dafür, dass das, was sie sehen, nicht das fertige Endprodukt ist, sondern ein Zwischenstand: „Warum geht denn XYZ nicht mit der Software?“. Das Management bestimmt den Scrum Master kurzerhand zum Projektleiter und erwartet ein umfangreiches Projekt-Reporting á-la PMI*, GPM** etc. Der Budgetverantwortliche will auf jeden Fall ein Lasten- und ein Pflichtenheft haben. Schließlich will er ja nicht die „Katze im Sack“ kaufen.

Unter diesen Voraussetzungen kann eine agile Softwareentwicklung und damit auch Scrum nicht funktionieren. Das Projekt endet im Chaos und gießt Wasser auf die Mühlen der eingefleischten Scrum Gegner und GPM bzw. PMI Befürworter.

Trotzdem stellt Scrum ein Vorgehensmodell dar, welches für die typischen Fragestellungen in Softwareprojekten klare Antworten liefern kann und dem, in Softwareprojekten notwendigen, empirischen Vorgehen gerecht wird.

Die Frage lautet daher, wie man unter realistischen Bedingungen erfolgreich Projekte mit Scrum abwickeln kann, insbesondere in einer Dienstleister – Kunden Situation.

Wie bereits eingangs erläutert, haben wir ein größeres Projekt nach Scrum abgewickelt und natürlich hat sich die Ausgangssituation nicht wesentlich von der oben geschilderten Realität unterschieden. Ein Punkt hat sich jedoch für den Erfolg des Projektes als wesentlich herausgestellt: Die Bereitschaft des Kunden, sich auf die Methode einzulassen.

Auf dieser Basis war es möglich, Scrum als Projektmethode zu etablieren. Dabei haben sich folgende Punkte als praktikabel und hilfreich herausgestellt:

• Wir haben, gemeinsam mit den Mitarbeitern des Kunden, ein gemeinsames Projektteam gebildet. Damit haben wir von vornherein auf eine intensive Zusammenarbeit im Projekt gesetzt.
• Die IT-Leitung des Kunden hat das Projekt gegen das Management abgeschirmt und als „Projektleiter“ nach außen fungiert. Sie hat somit Kundenintern einen Teil der Rolle des Scrum Masters, vor allem aber die, für das Management so wichtige Rolle des Projektverantwortlichen übernommen. Das Projektcontrolling wurde aus den Scrum-Kennzahlen und Logs (Velocity, Product- und Sprint-Breakdown, Impediment-Log etc.) gespeist.
• In einem vorangehenden 2-tägigen Analyse-Workshop wurde eine relativ konkrete Zielvorstellung für das Endprodukt definiert und in Form von UML Use-Case Diagrammen dokumentiert. Damit hatten alle Beteiligten eine Vorstellung davon, was erreicht werden und wie das Ergebnis aussehen sollte.
• Es wurden feste Projekttage vereinbart. Natürlich hatten die Projektmitarbeiter des Kunden ihr Tagesgeschäft zu erledigen. Eine Vollzeitarbeit im Projekt war für keinen der betroffenen Mitarbeiter realisierbar. Die IT-Leitung hat jedoch den notwendigen Freiraum für die Mitarbeiter geschaffen, sodass sich diese während der Projekttage (in unserem Projekt je zwei Tage pro Woche) ausschließlich der Projektarbeit widmen konnten.
• Die typische Scrum-Vorgehensweise mit Product- und Sprint-Backlog, Sprint-Planning-, Review- und Restrospective-Meetings sowie Estimation-Meetings wurde eingehalten. An den Projekttagen wurde ein Daily Scrum abgehalten.
• Das Scrum Team hat mit einem virtuellen Scrum Board gearbeitet. Damit war auch eine Übersicht über die Aufgaben außerhalb der Projektzeiten für alle Beteiligten möglich. Dies hilft ggf. auch für Projektteams, welche über Standortgrenzen hinaus verteilt sind.
• Der Product-Owner war ein Mitarbeiter des Kunden. Der Product-Owner beeinflusst maßgeblich das Endprodukt des Projektes. Somit behält der Kunde die Kontrolle über das Projekt und das Projektergebnis.
• Ein Anwendervertreter war Mitglied des Scrum Teams und diente als Multiplikator für die Fachabteilung. Dieser unterstützte den Product-Owner in seiner Arbeit, sodass dieser teilweise eine Vermittlerrolle einnehmen konnte, ohne jedoch seine Kernaufgabe zu verlieren.

Alle diese Maßnahmen haben zu einem gut funktionierenden Projekt geführt. Aber auch hier gilt: Besser geht immer!

In verschiedenen Punkten haben wir für uns und für unser nächstes Projekt Verbesserungspotential identifiziert:

• Auf die enge Einbindung der Anwenderseite sollte sehr viel Wert gelegt werden. Dies war in unserem Projekt zwar von vornherein vorhanden, jedoch kann diese Zusammenarbeit vermutlich nie intensiv genug sein.
• Wir haben es versäumt, die Einhaltung einer „Definition-Of-Done“ konsequent einzufordern. Dies hat insbesondere in Bezug auf qualitätssichernde Maßnahmen Auswirkungen gehabt.
• Qualitätssicherung durch System- und Integrationstests stellt in agilen Projekten eine Herausforderung dar. Der herkömmlicher Ansatz, dass nur ein komplettes Produkt getestet wird und das Entwicklerteam vom Testteam gänzlich entkoppelt ist, funktioniert in agilen Projekten methodenbedingt nicht. Agile Entwicklung bedeutet auch agiles Testen! Tester müssen in Scrum Projekten, im Sinne des Sprint-Ziels und der Definition-Of-Done, Mitglieder des Scrum Teams sein.

* PMI, Project Management Institute

** GPM, Gesellschaft für Projektmanagement

Haben Sie Fragen zu diesem Artikel oder brauchen Sie Unterstützung?

Nehmen Sie mit uns Kontakt auf!

Wir unterstützen Sie gerne bei Ihren Vorhaben!