Wie funktioniert Scrum?

Wie funktioniert Scrum? Inhaltsverzeichnis: 1 Agile Softwareentwicklung 2 1.1 Scrum 3 1.1.1 Rollen im Scrum 3 1.1.2 Framework in Scrum 4 1.1.3 Scrum Meetings 5 1.2 Agiles Manifest 7 1.3 Werte für eine erfolgreiche Zusammenarbeit 9 Auszug aus der Masterarbeit (Karl-Franzens Universitä Graz): Integration systemischer Ansätze in Managementrollen für agile Wissensarbeit. Am Beispiel eines Ausbildungsprogramms für Scrum Master. Von Mag.a Manuela Grundner, MA 1

Auftragnehmer in ein Pflichtenheft Ein Problem ist halb geloest, wenn es klar formuliert ist. John Dewey 1 Agile Softwareentwicklung Februar 2001: In einem Skiressort in Utah trafen sich zwölf namhafte Softwareentwickler, um gemeinsam darüber nachzudenken, was für die Entwicklung guter Software relevant ist. übersetzt, das die geplante Lösung für diese Anforderungen beschreibt. Dieses Pflichtenheft segnet der Auftraggeber ab, anschließend entwickelt der Auftragnehmer die Lösung, wie in diesem Pflichtenheft zugesagt. In einem für den Auftraggeber nicht sichtbaren Prozess entsteht die fertige Software. Änderungen im Verlauf der Projektentwicklung sind dabei nicht vorgesehen. Hier finden wir die größten Unterschiede zu agilen Vorgehensweisen. Bei diesen ist es essentiell für den Erfolg eines Projekts, dass Auftragnehmer und -geber im Aus dieser Zusammenkunft wurzelt das agile Manifest der Softwareentwicklung, das seitdem als Standard-Referenz agiler Entwicklung gilt. Die klassische Softwareentwicklung folgt einem Plan, der zu Beginn des Projekts festgelegt wird. Im Lastenheft beschreibt der Auftraggeber möglichst präzise die Gesamtheit seiner Anforderungen. Diese werden vom stetigen Austausch stehen. Es gibt einen groben Plan über das gesamte Projekt. Einzelne Inhalte hingegen werden im gemeinschaftlichen Austausch nach und nach konkretisiert. Durch diese Vorgehensweise gibt es während des Projekts die Möglichkeit, Inhalte anzupassen und auf neue Anforderungen zu reagieren. Das wird beispielsweise durch Entwicklungen am Markt genauso wie durch den 2

laufenden Erkenntnisgewinn aller in das Vorhaben eingebundenen Personen notwendig. Dadurch entsteht ein schrittweise reifendes Produkt, das den individuellen Kundenanforderungen entspricht. Eine weitere Forderung des agilen Manifests ist es, Software in kleinen Häppchen zu entwickeln, die arbeitsfähig und bereits getestet sind. Der Kunde kann Teile der Software schon produktiv in seinem System nutzen, bevor das ganze Projekt abgeschlossen ist. Dadurch entsteht ein Controlling-Mechanismus, der in knappen Schritten den Fortschritt eines Projekts misst. Durch regelmäßige Feedbackschleifen werden Probleme sowie neue Anforderungen früh sichtbar und es kann rechtzeitig darauf reagiert werden. 1 1.1 Scrum Das Wort Scrum kommt aus dem Rugby und bedeutet soviel wie Gedränge. Es ist ein spezieller Spielzug, bei dem die Mannschaften in 1 Grundner, Karlinger, Rauen Coaching Magazin, S.25. einer engen Teamformation um den Ball kämpfen. Scrum ist ein Framework, das die Zusammenarbeit selbstorganisierter Teams und die Prozessverbesserung durch zentrale Feedbackschleifen regelt. 2 1.1.1 Rollen im Scrum 3 Der Produkt Owner (PO) ist das Bindeglied zwischen Developer Team und den AuftraggeberInnen und ist für den geschäftlichen Erfolg des Produkts verantwortlich. Der PO arbeitet eng mit den Kunden, Anwenderinnen und Stakeholdern zusammen und konsolidiert deren Wünsche und Aufträge. Der Product Owner ist allerdings kein Projektleiter und trägt nicht die Gesamtverantwortung für das Produkt. Der PO ist für das WAS zuständig, also was genau das Produkt beinhalten soll, das die Endkundin möchte. Der PO hat die Verantwortung für das Product Back Log, in dem die einzelnen Items für die Software vermerkt werden. 2 Grundner, Karlinger, Rauen Caoching Magazin, S. 25. 3 Wintersteiger, Scrum - Schnelleinstieg, ibooks. 3

Das Developer Team ist für das WIE in der Produktkette verantwortlich und besteht durchschnittlich aus 5 bis 9 Personen. Die Kernkompetenzen liegen in der Umsetzung der Anforderungen in qualitativ hochwertige und laufende Software. Scrum erfordert die Umsetzung der einzelnen Items aus dem Sprit Back Log in einem fix definierten und eher kurzen Zeitraum, meist 2 bis 3 Wochen. In dieser Zeit wird keine fertige Software hergestellt, sondern kleine funktionierende Teile, die man Incremente nennt. Eine wichtige Bestimmung innerhalb von Scrum ist die Selbstorganisation des Teams. Es gibt keinen Teamleiter, der dem Team vorgibt wie es die Arbeit organisieren soll. Es gibt die Rolle des Scrum Masters (SM), der als Team Coach agiert. Seine Hauptaufgabe liegt darin, sich darum zu kümmern, dass das Developer Team effizient arbeiten kann. Der Scrum Master fördert die Reflektion und Entwicklung innerhalb des Teams und tritt dabei als Coach, Mediatorin, Trainer, Moderatorin und Mentor auf. Eine weitere Aufgabe des Scrum Masters ist es, das Developer Team vor Störungen von Außen zu schützen. Er stellt sicher, dass das Team einen geschützten Raum und Zeit für die Erledigung der Arbeit hat. Wenn beispielsweise der Product Owner während des Sprints weitere Items in Auftrag gibt, liegt es am Scrum Master, dies zu regeln. Der Scrum Master führt das Team ohne disziplinäre Macht und inhaltliche Verantwortung. Das führt dazu, dass er seine Hauptaufgabe wahrnehmen kann, das Developer Team dabei zu unterstützen, selbstorganisiert und höchst produktiv zu arbeiten. 1.1.2 Framework in Scrum 4 Die Anforderungen an das zu liefernde Produkt werden im Product Back Log festgehalten. Da Veränderungen in der 4 Wintersteiger, Scrum - Schnelleinstieg, ibooks. 4

agilen Softwareentwicklung erwünscht sind und Inkremente regelmäßig ausgeliefert werden, befinden sich im Product Back Log nur Anforderungen, die noch nicht erfüllt wurden. Um die Liste möglich einfach zu halten, sind die Einträge in kurzen Sätzen formuliert. Hierfür werden meistens User Stories verwendet. Diese Anwendererzählungen sind in Alltagssprache formulierte Anforderungen an die Software. Die User Stories sind die unterschiedlichen Arbeitsschritte in einem Sprint und werden auf dem Taskboard festgehalten. Dabei wird unterschieden, welche Arbeiten noch zu machen sind, was gerade in Bearbeitung ist und was bereits fertiggestellt wurde. So hat man jederzeit einen Überblick darüber, wie weit man mit den einzelnen Tasks ist. Abbildung 1 Beispiel für Taskboard http://www.hanseric.com/2010/04/08/analog-or-digital-task-board/ Im Sprint Back Log stehen die zu erledigenden Items für einen Sprint. Der Product Owner gibt die Reihenfolge und Priorisierung vor. Das Developer Team schätzt, wie viel Arbeit in einem Sprint erledigt werden kann. Da diese Schätzung in jedem Sprint wiederholt wird, hat das Team die Möglichkeit die Schätzungen immer mehr zu präzisieren. Für Items die in das Sprint Back Log übernommen werden, ist eine Definition of Ready essentiell. Es handelt sich dabei um klare Akzeptanzkriterien, wann eine Aufgabe so klar definiert ist, dass sie vom Developer Team entwickelt werden kann. 1.1.3 Scrum Meetings 5 Bei Scrum wird in Sprints gearbeitet. Ein Sprint ist eine geschlossene Zeiteinheit die zwischen 2 und 8 Wochen dauert. In diesem Zeitraum werden bestimmte Pakete entwickelt und es gibt wiederkehrende Rituale, die der Planung, dem Feedback und der Verbesserung dienen. In den 5 Wintersteiger, Scrum - Schnelleinstieg, ibooks. 5

meisten Scrum Teams hat sich eine Sprintzeit von zwei Wochen durchgesetzt. Gemeinsam mit dem PO werden aus dem Product Backlog die Items für einen Sprint in das Sprint Backlog übernommen. Im Sprint Planning werden Ziele für den jeweiligen Sprint vereinbart: wie viel im nächsten Sprint erledigt werden kann und wie die Produktteile entwickelt werden. Hier wird auch die Definition of Done erläutert, also wie die funktionale vollständige Implementierung einer Anwendung aussehen muss, damit sie als fertig bezeichnet werden kann. Das Daily Scrum ist ein Stand-up- Meeting, das jeden Arbeitstag stattfindet und die Fortschritte hinsichtlich des Sprint-Ziels unter die Lupe nimmt. Es soll maximal 15 Minuten dauern, deshalb wird es oft im Stehen abgehalten. Es werden im Wesentlichen 3 Fragen von allen Mitglieder des Developer Teams bearbeitet: ü Was habe ich gestern gemacht und erreicht? ü Was werde ich heute tun? ü Welche Blockaden habe ich bzw. was hindert mich am Fortschritt? Die Sprint Review ist das Meeting, in dem Stakeholder (Anwender, Auftraggeberinnen) und das gesamte Scrum Team zusammenkommen. Es findet ein Mal, gegen Ende des Sprints statt. Das Developer Team zeigt den Anwenderinnen die fertigen Produktinkremente nach Möglichkeit so, dass die neuen Features gleich getestet werden können. Die Auftraggeber haben die Möglichkeit, Feedback zu geben und zu überprüfen, ob die Software sich mit ihren Anforderungen und Erwartungen deckt. Darin liegt ein gewichtiger Vorteil der agilen Softwareentwicklung: die Kundin wird in regelmäßigen Abständen in den Fortschritt der Entwicklung eingebunden und hat so die Möglichkeit, zeitnah Einfluss zu nehmen und die optimale Entwicklung 6

zu fördern. geben. Der Scrum Master ist eine wichtige Person in diesem Meeting, da es eine seiner Aufgaben ist, einen geeigneten Rahmen für die Retrospektive zu schaffen. Abbildung 2 Ablauf in Scrum http://www.dasscrumteam.com/scrum In der Sprint Retrospective betrachtet das Scrum Team sich selbst aus einer Metaebene und schaut, wie ein Sprint verlaufen ist. Die Retrospektive ist fester Bestandteil des Sprints und findet ein Mal gegen Ende statt. Probleme die aufgetreten sind, werden analysiert und konkrete Maßnahmen erarbeitet, damit die Arbeit nachhaltig verbessert werden kann. Auch in der Retrospektive geht es nicht darum, die fachlichen Fähigkeiten des Teams zu begutachten, sondern die Teamentwicklung unter die Lupe zu nehmen. Die Sprint Retrospektive soll in einem geschützten Rahmen ablaufen, in dem alle Mitglieder die Möglichkeit haben, einander offen, mutig und wertschätzend Feedback zu 1.2 Agiles Manifest Agile Entwicklungsmethoden wie Scrum, Kanban 6, und Extrem Programmierung 7 hatten sich schon vor Entstehen des agilen Manifests entwickelt. 12 namhafte Softwareentwickler 8 haben sich gemeinsam überlegt, was für das Produzieren guter Software notwendig ist. Daraus entstand das agile Manifest, das sich vor allem mit diesen 4 Kernpunkten beschäftigt: Individuen und Interaktionen - mehr als Prozesse und Werkzeuge Funktionierende Software - mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden - mehr als Vertragsverhandlungen Reagieren auf Veränderung - mehr als das Befolgen eines Plans 6 Leopold, Kaltenecker, 2013. 7 Beck, Anders, 2004. 8 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. 7

Agiles Manifest 9 Prinzipien 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. 2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. 3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. 4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. 5. 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. 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. 9 http://agilemanifesto.org 7. Funktionierende Software ist das wichtigste Fortschrittsmaß. 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. 9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. 10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. 11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. 12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. Wenn man sich mit klassischem Projektmanagement beschäftigt, wie es sowohl in der IT als auch in anderen Bereichen angewandt wird, kann man hier sehen, dass diese 4 zentralen Punkte sowie die 12 Prinzipien eine Veränderung der üblichen Herangehensweisen mit sich bringen. In der Organisationsentwicklung 8

stehen alle Beteiligten hier vor der Herausforderung, die unterschiedlichen Zugänge von agiler Entwicklung und klassischem Management herauszuarbeiten und zu sehen, wo sowohl die Chancen als auch auch die Stolpersteine sind. Seit Veröffentlichung des Manifests sind mehr als 20 Jahre vergangen. Agile Methoden, allen voran Scrum und Kanban, haben sich entwickelt und etabliert. Das Framework der agilen Methoden ist bekannt. Allerdings stehen wir immer noch vor der Herausforderung, unterschiedliche Managementansätze zu kombinieren und gewinnbringend einzusetzen. 1.3 Werte für eine erfolgreiche Zusammenarbeit Da sich diese Werte aus den Prinzipien des agilen Manifests ergeben, ist es wichtig, sich mit diesem ausführlich zu beschäftigen. Anhand eines Artikels im Heise Developer, einer deutschsprachigen Fachmagazinreihe in der Softwareentwicklung, habe ich mich mit diesem Thema auseinandergesetzt: Die Autoren Röpstorff und Wiechmann haben sich aufbauend auf das agile Manifest in ihrem Buch "Scrum in der Praxis" mit den Werten beschäftigt, die für Wissensarbeiter essenziell sind. Dabei haben sie die dargestellten acht Werte ermittelt. Sie werden im Folgenden kurz umrissen, um einem klassischen Konfliktpotenzial in Teams vorzubeugen dem Missverständnis: Im Team ist es wichtig, den Fokus auf das Wesentliche zu richten und Störungen von den Entwicklern fernzuhalten. Das ermöglicht ein konzentriertes und effektives Arbeiten im Projekt. Für Inputs von außen werden fixe Zeitfenster geschaffen, die den Austausch ermöglichen. Offenheit ist ein essenzielles Element, um Vertrauen aufzubauen. Muss man keine Angst haben, an den Pranger gestellt zu werden; falls man eigene Fehler eingesteht oder Kritik äußert, ist es möglich, tief in ein Thema vorzudringen und Neues zu schaffen. Wertschätzung ist die wichtigste Form der Anerkennung. Menschen streben nach Erfolg und Bestätigung. In einem Team, dessen Mitglieder einander 9

wertschätzen und respektieren, steigt auch der Mut. Diesen braucht man, um Unannehmlichkeiten offen anzusprechen. Auch der Mut zu einem Nein ist wichtig, wenn innerhalb oder außerhalb des Teams Dinge verlangt werden, die nicht umsetzbar erscheinen. Andererseits würden aber auch neue Wege nicht gegangen, wenn nicht die Mutigen voranschritten. Nun zur Einfachheit. Oft neigen Projektmitglieder dazu, eine Entwicklung unnötig zu verkomplizieren, beispielsweise um eine möglichst generische Verwendbarkeit sicherzustellen. Dabei vergessen sie, dass Projekte an sich bereits komplex genug sind und es eine viel größere Kunst ist, die einfachste Lösung für ein Problem zu finden. Kommunikation ist das A und O einer gelungenen Teamarbeit. Hierarchische Schranken sollen abgebaut werden, um die Kommunikation in alle Richtungen zu öffnen. Es bedarf bestimmter Regeln und Kreativität, um die Kommunikation zu fördern beziehungsweise wieder in Fluss zu bringen. Gutes Feedback zu geben, das das Gegenüber gerne annimmt und ihm gleichzeitig Möglichkeiten zur Weiterentwicklung bietet, ist eine Wohltat. Zugleich ist es auch eine Kunst, die hohe Anforderungen sowohl an den Geber als auch an den Nehmer stellt: Feedback soll klar geäußert werden, darf aber nicht persönlich verletzen. Beim Nehmer braucht es die Offenheit, Feedback zuzulassen und anzunehmen. Zu guter Letzt der Wert des Commitment. Darunter verstehen die Autoren ein Team, das zueinander steht und sich gegenseitig den Rücken stärkt; aber auch ein Team, das gemeinsame Ziele über die individuellen Ziele der Mitglieder stellt. Zu Fehlern steht das gesamte Team. Es geht um die Lösung und nicht darum, wer den Fehler begangen hat. 10 10 Grundner, Karlinger Heise Developer Online. 10

Manuela Grundner...Ich hole meine Kundinnen und Kunden von unterschiedlichen Standorten ab und führt sie auf die spannende Reise der Weiterentwicklung... Manuela Grundner ist Gründerin und CEO von murbit der Entwicklungscompan y, Lektorin am Institut für Unternehmensführung und Entrepreneurship sowie Organisatorin der (Un)Conference Freiräume Graz. Sie definiert die Grundsätze ihrer Arbeit basierend auf Wertschätzung, Veränderung und Weiterentwicklung. Durch ihren vielseitigen beruflichen Werdegang im universitären Bereich, im Kulturwesen sowie im Tourismus hat sie einen facettenreichen Blick entwickelt, mit dem sie gerne über den Tellerrand schaut. Als Teamcoach, Trainerin und und Scrum Master entfaltet sie, gemeinsam mit ihren Kundinnen, einen handlungs- und lösungsorientierten Zugang, der neue Perspektiven sowie Veränderungsprozesse initiiert. Das breite Spektrum ihrer berufliche Erfahrung ermöglicht es ihr, vielfältige Perspektiven einzunehmen. Mag.a Manuela Grundner MA manuela.grundner@murbit.at 0650 230 77 92 www.murbit.at www.freiräume-graz.eu 11