Keine Angst vor Scrum

Methoden wie Scrum stehen und fallen mit dem intensiven Austausch zwischen den Beteiligten. Auch die Kunden müssen sich umstellen und über den gesamten Projektverlauf hinweg aktiv mitarbeiten sowie einen engagierten Ansprechpartner bereitstellen. Dann profitieren sie davon, dass sie jederzeit direkten Einfluss auf die Projektentwicklung haben und über den Stand der Arbeiten im Bilde sind.

Das Dienstleistungsverhältnis zwischen Agentur und Kunde wandelt sich zu einer Partnerschaft, die dem Auftraggeber mehr Transparenz als bei herkömmlichen Entwicklungsmethoden gibt. Sie stellt zudem sicher, dass das fertige Produkt exakt seinen Vorstellungen entspricht. Die Agentur wiederum kann sich durch das zeitnahe Feedback sicher sein, dass sie nicht an den Wünschen ihres Kunden vorbei entwickelt und kein Streit um vereinbarte Leistungen aufkommt.

Kleines Scrum-Glossar
Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor.

Scrum
Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde.

Das Scrum-Team
Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen:

1. Rolle: Product Owner
Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt.

2. Rolle: Scrum-Master
Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen.

3. Rolle: Die Entwicklergruppe
Sie besteht idealerweise aus sieben Entwicklern.

Sprint
Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat.

Backlog
So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt.

Definitionen von fertig
Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.

Agile Entwicklungsmethoden haben sich aus der Erkenntnis entwickelt, dass sich Spezifikationen in IT-Projekten nie so exakt formulieren lassen, dass kein Interpretationsspielraum bei der Umsetzung mehr bleibt. Deshalb setzen Methoden wie Scrum auf kurze Feedback-Zyklen, die verhindern, dass Auftraggeber und Entwickler aneinander vorbeireden. So können Missverständnisse schnell ausgeräumt werden und alle auf ein gemeinsames Ziel hinarbeiten.

Der Kunde bestimmt die Entwicklungsrichtung

Bei Scrum vertritt der "Product Owner" den Auftraggeber über den gesamten Entwicklungszeitraum im Projektteam. Seine Aufgabe ist es, die einzelnen Anforderungen zu benennen und zu priorisieren. Das Entwicklerteam setzt entsprechend der vom Product Owner vorgegebenen Reihenfolge nach und nach die Anforderungen in sogenannten Sprints um. Zu jedem Sprint - dieser dauert zwischen einer und vier Wochen - darf der Product Owner neue Anforderungen definieren, bestehende Anforderungen abändern oder neu priorisieren.

Nach Ende des Sprints entscheidet er, ob er die Entwicklungsergebnisse akzeptiert. Damit trägt der Product Owner einen wesentlichen Teil der Verantwortung für den Erfolg des Projekts. Denn er kann als einziges Mitglied des Scrum-Teams den Business-Wert der einzelnen Anforderungen beurteilen und muss den Kurs justieren.

Lässt sich ein Auftraggeber auf die agilen Prinzipien ein, profitiert er von der Flexibilität der Methode und kann seine neue Software wesentlich früher produktiv nutzen als bei herkömmlichen Entwicklungsverfahren. Während beispielsweise bei der Entwicklung einer Website nach einem Wasserfallmodell erst nach Abschluss des Projekts der gesamte neue Auftritt in einem großen Release freigegeben wird, ist die Website bei einer Entwicklung mit Scrum bereits einsetzbar, wenn die Kernelemente fertiggestellt sind.

Da der Product Owner steuert, welche Teile zuerst implementiert werden, stehen dem Auftraggeber nach kurzer Entwicklungszeit die Teilbereiche zur Verfügung, die für ihn den größten Wert haben. Beispielsweise können so die Start- und die Produktseiten eines neuen Webauftritts online gehen, während Serviceseiten oder Social-Media-Elemente erst in einer späteren Phase folgen. Bei der Entwicklung mit Scrum kann der Kunde so schon die gewinnbringendsten Teile nutzen, während die weniger relevanten Funktionen nach und nach ergänzt werden.

Optmierung noch im Projektverlauf

Dieses Grundprinzip - Teile fertigzustellen, sie zu testen und zu optimieren -, erlaubt es darüber hinaus, gewonnene Erkenntnisse aus den ersten Phasen eines Projekts in die spätere Entwicklung einfließen zu lassen und bei bestehenden Komponenten nachzusteuern. Das Verhalten der User lässt sich nie zuverlässig vorhersagen. Zwar kann man sich an Erfahrungswerten orientieren, aber erst der Praxiseinsatz zeigt, ob die Nutzer eine neue Funktion in dieser Form annehmen. Bei Scrum gehen die im aktuellen Projekt gemachten Erfahrungen und die daraus abgeleiteten Optimierungen direkt in die Entwicklung der noch ausstehenden Funktionen ein.

Ein weiterer Vorteil von Scrum ist die Möglichkeit, Optimierungen und Erweiterungen mit Continous Delivery zeitnah in das Live-System einzuspielen. Von den Entwicklern fertiggestellter Code wird dabei zuerst auf Testsysteme geladen und dort geprüft. Diese Testsysteme sind, soweit möglich, 1:1-Abbildungen der Live-Systeme - angefangen von identischer Hardware über versionsgleiche Software bis hin zu Verkehrsdaten beispielsweise aus SAP. Falls dies aus datenschutzrechtlichen Gründen unmöglich ist, ersetzen anonymisierte Testdaten mit identischen Eigenschaften die echten Verkehrsdaten. Nach der erfolgreichen Prüfung auf dem Referenzsystem wird der neue Code automatisch auf das Live-System überspielt. So lassen sich kontinuierlich kurze Release-Zyklen von etwa 14 Tagen erreichen.

1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen.

2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia.

3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv.

4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt.

5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet.

6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann.

7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht.

8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software.

9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist.

10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat.

11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3.

12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen.

13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren.

14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes.

15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden.

15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.

Dieses Vorgehen ermöglicht darüber hinaus flexible Tests neuer Features oder Layouts mit echten Nutzern. Eine neue Variante wird dabei nur auf einen Teil der Server eingespielt und nur ein Teil der Nutzer kommt damit in Berührung. Sind die Ergebnisse besser als bei der alten Version, wird sie auf das ganze System übertragen und die dabei gewonnenen Erkenntnisse fließen in die noch ausstehenden Entwicklungen ein. Wenn nicht, wird eine andere Variante ausprobiert. Dadurch lässt sich das Projekt noch in der Entwicklungsphase anhand von echten Kundenreaktionen verbessern und auch nach Projektabschluss weiter optimieren. Diese Integration kontinuierlicher Verbesserungen noch im Projektverlauf ist nur in einem agilen Entwicklungsmodell möglich.

Neue Fehlerkultur

Scrum unterscheidet sich von anderen Entwicklungsmethoden auch durch seinen Kosten-Nutzen-orientierten Umgang mit Fehlern. Ebenso wie es unmöglich ist, alle Anforderungen ohne Spielraum für Missverständnisse zu definieren, sind auch Fehler bei der Implementierung unvermeidbar. Während bei anderen Entwicklungsmethoden aber große Ressourcen investiert werden, um mögliche Fehler bereits im Vorfeld zu antizipieren und diese auszuschließen, beschränkt sich dies bei Scrum auf schwerwiegende Fehler. Kleinere Bugs werden erst mal in Kauf genommen. Was aber nicht heißt, dass sie im fertigen Produkt toleriert werden.

Die Erfahrung lehrt, dass bei derartigen Fehlern der Aufwand für die Korrektur, einschließlich der folgenden Tests, meist nur einen Bruchteil der Zeit beansprucht, der aufgewendet werden müsste, um den Bug von vorneherein auszuschließen. Agile Entwicklungsmethoden sind in diesem Sinne fehlertolerant, da ihr Augenmerk auf dem schnellen Beheben auftretender Fehler liegt, statt große Ressourcen in deren Vermeidung zu investieren.

Eine Voraussetzung dafür, dass die Softwarequalität am Ende trotzdem stimmt, ist ein zuverlässiges Test-Management. Im Projektalltag ermöglicht das einen wesentlich offeneren Umgang mit Problemen, weil sie nicht als Versagen einzelner Beteiligter wahrgenommen werden, solange mit den Fehlern konstruktiv umgegangen wird. Viele Unternehmen haben mit Scrum die Erfahrung gemacht, dass ihr Code bei einem richtigen Test-Management am Ende trotz geringerem Ressourceneinsatz eine niedrigere Fehlerquote aufweist als bei anderen Entwicklungsmethoden.

Lässt sich ein Kunde auf die agilen Prinzipien ein, hat er davon viele Vorteile: Neben der zielgenaueren Entwicklung und der höheren Flexibilität bei der Anpassung der Anforderungen im Projektverlauf profitiert er von der gesteigerten Transparenz. Er sieht nicht nur ständig, was entwickelt wird und kann nachsteuern, sondern er sieht auch, welche Ressourcen in welche Anforderungen investiert wurden. Beispielsweise ist es möglich, die einzelnen Arbeitsschritte auf Tickets festzuhalten und alle Zeiten darauf zu buchen. So sieht der Kunde tagesaktuell, wer wann wo wie lange an einem Ticket gearbeitet hat und was gemacht wurde. Er kann exakt nachvollziehen, wie viel Geld er für welche Leistung ausgegeben hat und kann damit besser beurteilen, ob sich ein Feature für ihn lohnt oder nicht.

Wenn der Kulturwandel gelingt, profitieren beide Seiten

Scrum verändert nicht nur das Verhältnis zwischen Auftraggeber und Auftragnehmer. Es führt auch zu mehr Flexibilität und Transparenz und damit zu mehr Offenheit. Das hat den Vorteil, dass beide Seiten jederzeit wissen, woran sie sind. Es bedeutet aber auch, dass sich keine der beiden Seiten mehr hinter langen Verträgen und dicken Lastenheften verstecken kann. Wenn sich beide Seiten auf das agile Entwicklungsmodell einlassen, profitieren am Ende auch beide - nicht nur von einer angenehmeren Zusammenarbeit, sondern auch von schnelleren und besseren Ergebnissen zu einem besseren Preis-Leistungs-Verhältnis.