Der Erfolg eines Webprojektes – egal ob Online-Shop, Webseite oder auch Online-Marketing – hängt ganz entscheidend vom Projektmanagement ab. Während man früher im Vorfeld den Fokus auf umfassende Konzepte legte (um in der Umsetzung dann festzustellen, dass diese häufig nicht passten), geht der Trend inzwischen hin zu sog. agilen Projektmanagementmethoden. Mit vorliegendem Beitrag möchte ich hierzu einen ersten Einstieg in die Grundüberlegungen und Vorteile dieser Managementmethoden geben.
Während man beim klassischen Entwicklungsansatz nach dem sog. Wasserfallmodell möglichst detaillierte Vorarbeiten leistet – mit entsprechend genauen Arbeitsanweisungen – erhalten Scrum-Teams entsprechend genaue Vorgaben, was die Zielerreichung anbelangt – nicht jedoch die detaillierte Umsetzung. Dabei entstand der Scrum-Ansatz primär aus der Problematik, dass zwischen Analyse- bzw. Konzeptphase und der tatsächlichen Implementierung häufig zu viel Zeit vergeht, in der sich nicht nur Anforderungen an die Software bzw. an das Projekt verändern, sondern eine Vielzahl von Fragestellungen lassen sich zu einem solch frühen Zeitpunkt einfach nicht valide beantworten.
Kennen Sie das? Am Ende eines Projektes bekommen Sie zwar im besten Falle das, was Sie vorab ausgearbeitet und konzeptioniert haben, aber nicht das, was Sie eigentlich haben wollen bzw. tatsächlich brauchen. Scrum versucht, genau an diesem Punkt einzugreifen. Wenn Ihnen dieses Problem bekannt vorkommt, sollten sie an dieser Stelle weiterlesen.
Der Weg zum jeweiligen Endergebnis entwickelt sich bei Scrum innerhalb eines hoch qualifizierten und interdisziplinären Teams während der Implementierung. Insofern kann auch der erste mögliche Trugschluss, Scrum sei „planlos“, widerlegt werden. Bei Scrum wird lediglich die genaue Art der Umsetzung nicht vorgegeben, sondern im Team erarbeitet, wobei hier zum einen der gruppendynamische Prozess vorteilhaft zum Tragen kommt und zum anderen natürlich auch laufende Erkenntnisse permanent in die Arbeit einfließen.
SCRUM (engl. „Gedränge“) bezeichnet ursprünglich einen Spielzug im Rugby, der auf den ersten Blick wie ein undurchschaubares Gedränge wirkt, jedoch sehr sorgfältig einstudiert ist. Im Projektmanagement handelt es sich hierbei um ein Prozessmodell, das mehr und mehr in der IT- und Softwareentwicklung angewendet wird. Angelehnt an bestimmte Annahmen aus der Automobilproduktion und den Ansatz der „Lean Production“ liegt der Kern von SCRUM in einer iterativen Herangehensweise, d. h. der Wiederholung von Prozessen und Arbeitsschritten, die dem Team das Lernen aus vorherigen Prozessphasen und dadurch die stetige Optimierung späterer Phasen ermöglicht. SCRUM besteht im Kern aus dem Zusammenspiel einzelner Rollen, Meetings und Artefakte (Dokumente), die klar strukturiert und vorgegeben sind.
Zusammengefasst bedeutet Scrum: Zerteilung komplexer und umfangreicher Entwicklungsarbeiten in kleine Teilprojekte, die nacheinander in sog. Sprints, die in der Regel zwei bis vier Wochen dauern, umgesetzt werden und bei denen das Ziel die Auslieferung eines funktionsfähigen und qualitativ hochwertigen Codes bzw. eines funktionsfähigen Endergebnisses darstellt.
Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist.
Das oberste Ziel in einem Scrum-Projekt besteht darin, bestmögliche und funktionsfähige (auslieferbare) Software bzw. Arbeitsergebnisse unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität abzuliefern!
Dabei charakterisiert sich Scrum – insbesondere im direkten Vergleich mit klassischen Entwicklungsmethoden – durch die nachfolgenden drei Prinzipien:
Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten.
Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt.
Anpassung: Die Anforderungen an das Produkt werden nicht ein für alle Mal im Vorfeld festgelegt, sondern nach jeder Lieferung eines Teilprojektes neu bewertet und bei Bedarf angepasst.
Scrum funktioniert dabei – vereinfacht dargestellt – nach dem folgenden Muster, wobei agil nicht bedeutet, einfach loszulegen. Hier geht es vielmehr um umfassendes Mikro-Projektmanagement:
Aufteilung einer Organisation in kleinere, crossfunktionale und selbstorganisierende Teams
Aufteilung der Arbeit in möglichst konkrete und abgeschlossene Arbeitspakete, die priorisiert und deren Aufwand im Team anhand relativer Angaben (Komplexitätspunkte) geschätzt wird.
Aufteilung der Zeit in kurze und fest vorgegebene Zeitintervalle – sog. Sprints - (gewöhnlich 2–4 Wochen), bei denen das oberste Ziel in der Auslieferung funktionsfähiger Software bzw. Lösungsansätze besteht.
Laufende Optimierung des Releaseplans und permanente Prüfung sowie ggf. Anpassung der Priorisierung einzelner Tasks zusammen mit dem Kunden und auf Basis der Ergebnisse der bisherigen Arbeit.
Optimierung des Prozesses durch gemeinsame Prüfung und Analyse der Arbeitsergebnisse nach jedem Zeitintervall (Sprint).
Zusammengefasst bedeutet Scrum – wie eingangs bereits erwähnt – demnach nichts anderes als die Aufteilung eines großen Arbeitspaketes (dabei spielt es im Prinzip keine Rolle, ob es sich um Software oder z. B. auch Online-Marketing-Tasks handelt) in kleinere „Häppchen“, die nacheinander abgearbeitet und deren Zwischenergebnisse nach jedem „Häppchen“ erneut geprüft werden. Auf Basis der Ergebnisse aus dieser Zwischenprüfung können dann im weiteren Verlauf kurzfristige Änderungen vorgenommen werden, wodurch die Flexibilität signifikant erhöht wird.
Scrum-Teams organisieren sich selbst und die Mitglieder sind in sehr hohem Maße für die an sie gestellten Teilaufgaben eigenverantwortlich. Dadurch wird den Mitarbeitern mehr Vertrauen entgegengebracht, der häufig im Marketing benötigte Freiraum wird erhöht und die Motivation der Teams steigt mitunter deutlich. Durch straffe organisatorische Vorgaben und klare Rollen wird ein schlüssiger Rahmen geschaffen, der die Eckpunkte und Strukturen vorgibt, den Teammitgliedern innerhalb ihrer Arbeit aber größtmögliche Freiheit gewährt.
Obwohl Scrum primär auf IT-Entwicklungsprozesse abzielt, lässt sich die Vorgehensweise auch durchaus auf diverse andere Bereiche (z. B. Marketing, Vertrieb etc.) adaptieren und immer mehr Unternehmen versuchen hier auch, die Vorteile von Scrum für sich in breiterem Kontext nutzbar zu machen.
Im Jahre 2001 wurden von einigen IT-Vordenkern zwölf Thesen zu Scrum aufgestellt, die zum besseren Verständnis beitragen, das mittlerweile berühmte „Agile Manifest“:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
Heiße Anforderungsänderungen selbst spät in der Entwicklung sind willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.
Quelle: einfach.st/srm1
Sofern Scrum für nicht IT-Bereiche angewendet wird, werden häufig bestimmte Scrum-Vorgaben als Einstieg genommen (z. B. Daily Stand-up-Meetings), die dann mit individuellen Ergänzungen oder Adaptionen versehen werden, um die individuellen Anforderungen besser abbilden zu können. Hier besteht auch durchaus gewisse Flexibilität, sodass die besten Ergebnisse nicht immer durch eine lehrbuchhafte Einführung von Scrum, sondern eher durch eine Art Best-of-Breed-Ansatz entstehen.
Häufig kommt hier eine Kombination aus Scrum und Kanban zum Einsatz, wobei über Karteikarten anfallende Tasks abgewickelt werden und das oberste Ziel darin besteht, durch einen sog. Pull-Ansatz (der Mitarbeiter holt sich selbstständig Aufgaben vom Kanban-Board) den sog. Work-in-Progress zu optimieren.
Eine zentrale Vorgabe bei Scrum besteht in festen Rollen, die zwingend besetzt und eingehalten werden müssen. Auf der einen Seite steht das klassische Scrum-Team, das die nachfolgenden Rollen beinhaltet:
Product Owner: Diese Rolle kann als verlängerter Arm des Kunden gesehen werden. Der Product Owner gibt die Anforderungen und die strategische Marschrichtung inkl. Priorisierung von Anforderungen bzw. Tasks vor. Diese werden in Abstimmung mit dem Entwicklungsteam im sog. Product Backlog als sog. User Stories erfasst. Er allein entscheidet über Features, Kosten und Timings (Auslieferung). Entscheidungen des Product Owners sind dabei verbindlich.
Scrum Master: Er ist für den Erfolg eines Scrum-Projektes verantwortlich und für die Einführung der entsprechenden Scrum-Regeln. Er moderiert die anfallenden Meetings und kümmert sich darum, dass etwaige Hemmnisse im Scrum-Prozess beseitigt werden. Dazu zählen u. a. mangelnde Kommunikation oder Störungen von außen durch neue/geänderte Anforderungen etc.
Entwicklungsteam: Wie der Name bereits vermuten lässt, ist das Entwicklungsteam für die Implementierung der vom Product Owner im Backlog geforderten Funktionalitäten zuständig. Eine Besonderheit bei Scrum besteht darin, dass das Entwicklungsteam zu Beginn des ersten Sprints im Rahmen des sog. Sprint Plannings gemeinsam die Anforderungen prüft und diskutiert und in der Folge dann eigenmächtig ein Commitment zur Umsetzung des ersten Sprints und der dort enthaltenen Anforderungen abgibt und sich verpflichtet, die dort selbst definierten Anforderungen zu erreichen. Dabei werden die Anforderungen in Form von User Stories vom Team gemeinsam geschätzt und in sog. Tasks heruntergebrochen, die normalerweise max. einen Tag in Anspruch nehmen dürfen. Während der kompletten Entwicklung steht dabei immer das Team im Vordergrund und nicht einzelne Entwickler. Das Team gewinnt zusammen und muss sich auch miteinander arrangieren, sofern unerwartete Probleme auftauchen oder z. B. ein Entwickler aus- oder abfällt. Wichtig dabei ist auch der interdisziplinäre Ansatz, über den Entwickler z. B. auch Testaufgaben übernehmen und so einen umfassenderen Einblick erhalten und sich gegenseitig ergänzen können. Eine zentrale Vorgabe im Scrum-Prozess besteht im sog. Daily-Scrum, einem täglich stattfindenden 15-minütigen Meeting, bei dem der aktuelle Stand abgestimmt wird und folgende Fragen durch die Mitglieder des Entwicklungsteams beantwortet werden:
Was hast du gestern getan?
Was wirst du heute tun?
Welche Hindernisse stehen dir im Weg?
Wann haben wir das Ziel erreicht?
Auf der anderen Seite stehen nachfolgende drei Rollen, die man jedoch auch aus diversen anderen Ansätzen und Entwicklungsmethoden kennt:
Customer: Diese Rolle beschreibt – was auch nicht sonderlich überraschend ist – den Kunden. Er wird in den meisten Fällen vom Auftraggeber gestellt, könnte theoretisch aber auch durch den Auftragnehmer bereitgestellt werden. Der Customer sollte im engen Austausch mit dem Product Owner stehen, dessen Ziel darin besteht, den Customer mit der gelieferten Software zu begeistern.
User: Als User wird der spätere Anwender der Software verstanden. Dies kann zugleich auch der Customer sein, was jedoch nicht zwingend der Fall ist. User sollten im Scrum-Prozess insbesondere beim Sprint-Planning sowie bei Reviews dabei sein, um das gelieferte Ergebnis aus Anwendersicht beurteilen zu können.
Management: Die Aufgabe des Managements besteht darin, die Rahmenbedingungen für ein erfolgreiches Scrum-Projekt zu schaffen. Dazu zählt neben der Bereitstellung der notwendigen Ressourcen auch die Unterstützung des Scrum-Teams durch Beseitigung etwaiger externer Faktoren, die den Erfolg des Scrum-Projekts gefährden könnten.
Da Scrum im Prinzip einer Art Paradigmenwechsel gleichkommt, wird die Einführung dieser Projektmanagement-methode nicht von heute auf morgen funktionieren. Hier sollten in jedem Fall ausreichend Zeit und idealerweise auch entsprechende Test-Projekte vorhanden sein. Häufig ist es auch so, dass der Scrum-Prozess an individuelle Bedürfnisse angepasst werden muss und das Team bei der Implementierung einer Optimallösung diese idealerweise mitgestalten sollte.
Die Praxis zeigt jedoch sehr häufig, dass nach einer gewissen Einarbeitungs- und Umstellungsphase sehr positive Effekte zu verzeichnen sind: Zum einen wird sich die Produktivität der Teams mitunter signifikant erhöhen, und das bei gleichzeitiger Verbesserung der Qualität, zum anderen wird die Arbeit häufig als planvoller und strukturierter empfunden. Die Ergebnisse fallen häufig praxisorientierter aus, wodurch die Zufriedenheit sowohl beim Team als auch beim Kunden steigt:
Kundenaussage nach einem Scrum-Review -Meeting: „Das, was man uns gezeigt hat, war schlichtweg ‚umwerfend‘ und ‚perfekt‘ … Ein großes und dickes Lob an Sie. Ich bin begeistert ...“
Es zeigt sich aber auch, dass eine Vorgehensweise anhand (meist überbuchter) Festpreisangebote in der Praxis kaum mehr funktioniert. Hier wird dann sehr häufig nach monatlichen Stundenkontingenten abgerechnet. Die Praxis zeigt hier jedoch, dass die Ergebnisse sowohl für Auftraggeber als auch für Auftragnehmer meist besser ausfallen. Es wird nur die tatsächliche Leistung verrechnet. Dies muss natürlich auch bei der Vertragsgestaltung entsprechend berücksichtigt werden.
Eine Studie der Standish Group aus dem Jahr 2009 hat gezeigt, dass lediglich ein Drittel aller IT-Projekte erfolgreich ist. Folglich enden zwei Drittel aller IT-Projekte mit überzogenen Zeitplänen, überzogenen Budgets oder mit nicht fertiggestellten Funktionen. Folgt man diesem Ergebnis, bestehen zwei Möglichkeiten:
Man weist zu Beginn darauf hin, dass ein Projekt mit rund 67-prozentiger Wahrscheinlichkeit länger dauert als geplant, teurer wird als budgetiert, und/oder dass am Ende häufig nicht das dabei herauskommt, was sich der Auftraggeber vorgestellt hat.
Man setzt auf einen iterativen und praxisorientierten Ansatz über Scrum, der die laufenden Arbeitsergebnisse sowie etwaige Änderungen von Anforderungen berücksichtigt und so höchstmögliche Flexibilität und Transparenz gewährleistet.
Hier gilt es zu beachten, dass Scrum keine grundsätzlichen Probleme löst, sondern diese nur schneller transparent macht. Dadurch können sich jedoch ganz entscheidende Zeit- und Kostenvorteile ergeben und die Time-to-Market kann signifikant verbessert werden. Insofern sollte Scrum bei der zukünftigen Projektplanung in jedem Fall mit ins Kalkül gezogen werden.