Scrum

Scrum ist eine Projektmanagementmethode, die es Entwicklungsteams ermöglicht, digitale Produkte und Services nach den Grundsätzen des Lean Development zu realisieren. Sie kommt überall dort zum Einsatz, wo Softwareanwendungen gestaltet und entwickelt werden. Ursprünglich beheimatet im Bereich Software Engineering, erobert Scrum immer mehr auch designnahe Projekte, etwa im Bereich Digital Design, Service Design, Web- und App Design, User Experience Design oder Interactive Design. Der Digital Turn im Bereich Design hat Scrum zu einem wichtigen Thema für all jene kreativen Berufe gemacht, die sich mit der Ideation, der Planung und der Umsetzung digitaler Produkte und Services befassen.

mehr

Woran agile Projekte scheitern

Wir haben fünf beliebte Fehler zusammengestellt …

mehr

Agiles Projektmanagement

Agiles Projektmanagement: Tools und Methoden für die Kreativbranche

Kreation, Budget, Timing und Technik – alles fest im Griff? Agiles Projektmanagement ist das Gebot der Stunde. Doch welche Methode ist die richtige für Ihr Projekt?

mehr

10 Online-Tools für die Projektplanung

Verteilt und interdisziplinär – so arbeiten die meisten Agenturen, Freelancer und Kunden heute. Für derart dynamische Projekte braucht es cleveres Aufgabenmanagement. Projektplanungstools helfen, die Aufgaben effizient zu bewältigen.

mehr

Kreative Berufe: Scrum Master

Welche Ausbildung und Skills ein Scrum Master benötigt …

mehr

Anzeige

Design- und Entwicklungsteams, die Scrum als agile Produktentwicklungsmethode wählen, arbeiten in zwei- bis vierwöchigen Iterationen, den sogenannten Sprints. Ziel jeder iterativen Schleife ist ein Minimum Viable Product (MVP), das lauffähig sein sollte, aber nicht voll ausgearbeitet sein muss. Im nächsten (oder den nächsten) Sprint(s) geht es dann darum, das MVP sukzessive zu verbessern.

Scrum dient dem Ziel, Entwicklungsprojekte, die zu komplex sind, um sie vollumfänglich zu planen, auf überschaubare Entwicklungslinien herunterzubrechen. Dies geschieht mithilfe sogenannter Artefakte wie dem Product Backlog, dem Sprint Backlog und dem Product Increment, dem Burn-down-Chart, in dem die noch zu leistende Entwicklungsarbeit visualisiert wird, sowie mittels einer klar festgelegten Dramaturgie aus Sprint Planning, Daily Scrum, Sprint Retrospektive und Produkt Backlog Refinement.

Die Artefakte sollen die Kommunikation im Team fördern und den Fortschritt sichtbar machen. Zusätzlich sorgt eine klare Rollenverteilung aus Product Owner, Entwicklungsteam und Scrum Master dafür, dass das Team effizient und zielorientiert arbeitet.


Mehr Wissenswertes über den Einzug agiler Projektmanagement-Methoden in die Kreativberufe lesen Sie im PAGE eDossier »Projektmanagement in der Kreativbranche«.


Welche Ausbildung und welche Skills ein Scrum Master benötigt, erfahren Sie hier.



Abenteuer agil

Wer agile Arbeitsweisen einführen will, unternimmt eine Reise ins Ungewisse – das gilt für Agenturen und Auftraggeber gleichermaßen. Und doch kann gerade der Bereich User Experience enorm davon profitieren. Stefan Freimark erläutert die Rahmenbedingungen für erfolgreiche agile Projekte.


Erstveröffentlichung dieses Beitrags: WEAVE 05.2013 / Autor: Stefan Freimark


INHALT

1. Wer Scrum einführt, rüttelt an der Unternehmenskultur
2. Gute Rahmenbedingungen führen zum Erfolg
3. Neue Bedingungen für Auftraggeber
4. Schlüsselpositionen richtig besetzen!
5. User Experience (UX) wird gerade erst agil
6. Scrum-Projekte Schritt für Schritt: So gelingen agile Digitalprojekte
7. Kleines Scrum-Glossar
8. Im Interview: Jutta Eckstein, Trainerin, Beraterin und Autorin für 
agile Softwareentwicklung
9. Buchtipps von »Abenteuer agil«-Autor Stefan Freimark

Kanban, Crystal Clear, Lean Management, Scrum … In Ausschreibungen und Pitches häufen sich die Anfragen nach agilen Arbeitsweisen, und auf der Berliner IA Konferenz im Mai war dies der Schwerpunkt der Vorträge. Nicht ohne Grund, denn Scrum und Co bieten handfeste Vorteile gegenüber dem klassischen Projektablauf nach dem Wasserfallmodell.

Das Wasserfallmodell sieht einen klaren Plan mit eindeutig voneinander abgegrenzten Projektphasen vor – nicht selten mit dem Ergebnis mangelnden Dialogs zwischen den Disziplinen. Dies führt dazu, dass die Beteiligten oft keine Verantwortung für das Gesamtergebnis übernehmen. Dazu hat das Team zu Beginn meist nur ein vermeintlich klares Bild vom Endergebnis – und erstellt eine detaillierte Spezifikation mit allen Finessen, von denen in der Umsetzung nur die Hälfte Gestalt annimmt. Dumm gelaufen!

Themenseite-Scrum-Projektwand
Ausdrucke mit User Storys sorgen für Übersicht und ermög­lichen dem Team, aufkommende Fragen sofort zu diskutieren

Kein Wunder, denn zum Start kennen weder die Auftraggeber noch die Dienstleister wirklich alle Anforderungen – oft kommen im Verlauf des Projekts noch neue Erkenntnisse hinzu. Oder beim Auftraggeber wechseln die Entscheider, und die Prioritäten ändern sich. Auch die Technik kann sich weiterentwickeln, oder die Beteiligten müssen auf neue Markterfordernisse reagieren. Wenn das Projekt dann auch noch lange dauert, ist angesichts dieses beweglichen Kontexts das Risiko ziemlich groß, dass der Wasserfallplan durcheinandergerät.

Agile Arbeitsweisen eignen sich besonders gut, derlei Begleiterscheinungen zu begegnen. Und doch ist es nicht sinnvoll, sämtliche Projekte über einen Kamm zu scheren und nur noch agil zu arbeiten – der Wasserfall hat nach wie vor seine Berechtigung: Wenn die Projektlaufzeit überschaubar ist, die Anforderungen weitgehend klar sind und mit Überraschungen nicht zu rechnen ist, dann ist die traditionelle Arbeitsweise besser geeignet.
Top

Wer Scrum einführt, rüttelt an der Unternehmenskultur

Erfolgreich können agile Projekte nur sein, wenn die Unternehmenskultur es zulässt. Das im Jahr 2001 von 17 Erstunterzeichnern formulierte »Agile Manifesto« definiert ein Wertesystem, das Orientierung gibt. So gilt etwa: »Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.« Das heißt aber nicht, dass es keine Regeln gibt. Agil bedeutet nicht chaotisch!

Zum wirklich »agil sein«, statt nur »agil tun«, gehört mehr, als nur bestimmte Scrum-Artefakte wie »Burn down Charts« (siehe Glossar) oder »Product Backlogs« zu produzieren oder definierte Meetings wie »Sprint Review« oder »Retrospektive« einzuhalten. Es reicht nicht, alten Arbeitsweisen einfach neue Namen zu geben. Zum »agil sein« gehört das Bewusstsein, dass jeder im Team Verantwortung für das Gesamtergebnis trägt. Das heißt auch: Wenn etwas nicht gut läuft oder Schwierigkeiten auftauchen, hat jeder nicht nur das Recht, sondern die Pflicht, das anzusprechen. Alle Teammitglieder müssen offen für Veränderungen sein und flexibel genug bleiben, um Anregungen aufzugreifen. Kommunikation ist generell Trumpf!

Ein Beispiel: Die User Storys sollte nicht der Konzepter allein formulieren und dann den Entwicklern zur Umsetzung zuschieben, denn dies entspräche wieder der sequenziellen Arbeitsweise des Wasserfalls. Stattdessen entstehen die Storys durch Teamarbeit in Sprint Null, einer zwei- bis vierwöchigen Vorlaufphase. Mathias Wrba, Leiter der Beratung bei FELD M in München, riet auf der IA Konferenz, die User Storys als Diskussionsgrundlage zu betrachten.
Top

Gute Rahmenbedingungen führen zum Erfolg

Damit das Team effizient arbeiten kann, braucht es einen Projektraum, in dem alle Teammitglieder Platz finden – und zwar nicht nur für den regelmäßigen Statusabgleich, sondern zum Arbeiten! In Agenturen kann hier schnell ein Konflikt entstehen, denn womöglich sind die Beteiligten nicht zu 100 Prozent für das Projekt eingeplant, sei es, weil kein Budget für eine Besetzung an fünf Tagen die Woche vorgesehen ist oder dass in einem anderen Projekt noch Arbeit ansteht.

Themenseite Scrum, Rainer Sax
Rainer Sax, freier User-Experience-Stratege und Service Designer in Hamburg

»Agiles Arbeiten erfordert von allen Projektbeteiligten Disziplin und gegen­seitigen Respekt. Niemand kann sagen: ›Das ist nicht mein Job!‹«

Für den betroffenen Mitarbeiter bedeutet das dann, dass er gedanklich oft zwischen verschiedenen Projekten wechseln muss und sich nicht auf eine Aufgabe konzentrieren kann. Außerdem ist der Projektraum dazu gedacht, schnell miteinander zu kommunizieren. Wenn Teammitglieder in weitere Projekte eingebunden sind, passiert es leicht, dass sie wegen Besprechungen für diese anderen Projekte gar nicht im Raum und somit nicht ansprechbar sind. Dadurch bleibt nicht nur die Idee eines Projektraums auf der Strecke, es wird auch ein wesentlicher Wert des agilen Arbeitens ad absurdum geführt, nämlich die Wertschätzung für Individuen und Interaktionen. Daher sind agile Arbeitsweisen vor allem für größere Projekte geeignet, bei denen die Teammitglieder für einen längeren Zeitraum nahezu ausschließlich für dieses eine Vorhaben tätig sind.

Wenn Sie sich für agile Methoden entscheiden, gilt: Kennen Sie die Regeln, bevor Sie sie brechen! Die empfohlenen »Artefakte«, Abläufe und Meetings sind gut dazu geeignet, unerfahrenen Projektteams Orientierung zu geben. »Teilagil« oder »moderat agil« arbeiten, um alte Arbeitsweisen beizubehalten – das geht meistens schief.
Top

Neue Bedingungen für Auftraggeber

Agil zu arbeiten heißt, sich iterativ an ein bewegliches Ziel anzunähern. Anders gesagt: »Fahren auf Sicht«. Darauf kann oder will sich nicht jeder Auftraggeber einlassen. Anders als das Wasserfallmodell mit seiner vermeintlichen Planungssicherheit löst die Beschreibung agiler Arbeitsweisen oft erst einmal Unsicherheit aus, die bei genauerer Sicht der Dinge allerdings in der Natur von Digitalprojekten generell begründet ist.

Sie sollten Auftraggeber auch nicht darüber im Unklaren lassen, auf was sie sich unter dem Stichwort »agil« einlassen: Entgegen einem weit verbreiteten Irrtum bedeutet dies nämlich nicht, dass der Kunde jederzeit Änderungen einbriefen kann. Der Kunde kann erst im Review Meeting die Ergebnisse ansehen und mit allen Teammitgliedern sprechen und, sollte Bedarf bestehen, eine neue Richtung vorgeben, ehe sich das Team für eine weitere Iteration in den nächsten Sprint zurückzieht.

Mathias Wrba, Stellvertretender Geschäftsführer, FELD M GmbH, München

»User Storys sind Conversation Starters. Sie sollen zu
Beginn noch nicht alles vollumfänglich festlegen«

Agile Projekte erfordern auch andere Verträge. In Wasserfallprojekten gibt es Werkverträge, in denen vor Projektstart der Gegenstand der Lieferung festgelegt ist. Anders bei agilen Projekten: In ihnen ist zwar nicht völlig unbekannt, was entwickelt werden soll – wie das Endergebnis tatsächlich aussieht, zeigt sich aber hauptsächlich auf dem Weg. Eine Möglichkeit ist, zwar einen Festpreis zu vereinbaren, aber das exakte Endergebnis an dieser Stelle noch nicht festzulegen. Stattdessen vereinbaren Auftraggeber und Dienst leister, dass sie im Laufe des Projekts gemeinsam beschließen, welche Features bis zur bekannten Budgetgrenze umgesetzt werden sollen. Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr beschreiben in ihrem Buch »Der agile Festpreis«, worauf Sie bei agilen Projekten achten sollten, und schlagen unter anderem Musterverträge vor.
Top

Schlüsselpositionen richtig besetzen!

Bei Scrum gibt es neben dem Entwicklungsteam zwei weitere Rollen: den Product Owner (kurz PO) und den Scrum Master. Zu den Aufgaben des POs gehört es, Kontakt zum Kunden zu halten. Er muss Anforderungen aufnehmen und diese mit dem Kunden priorisieren, um dann die jeweiligen Sprints vorzubereiten, damit das Projekt sich in die richtige Richtung entwickelt. Und er muss Kundenwünsche während eines Sprints vom Team fernhalten, damit es sich unbeschwert auf den aktuellen Sprint konzentrieren kann. Außerdem muss der PO das Gesamtprodukt im Blick haben und dabei eine gute Balance zwischen den Interessen der Nutzer, des Auftraggebers, aber auch des Auftragnehmers finden. Da der PO inhaltlich tief in das Projekt involviert sein muss, ist ein hohes zeitliches Engagement erforderlich – kurz: Diese Aufgabe kann man nicht nebenbei erledigen.

Der Scrum Master sorgt dafür, dass alle Beteiligten den Prozess einhalten. Er ist dafür verantwortlich, dass die vorgesehenen Meetings stattfinden – in seiner Aufgabe als Moderator achtet er darauf, dass die Teammitglieder Konflikte ansprechen, damit sie gelöst werden können. Darüber hinaus vermittelt er die agilen Werte im Unternehmen und beseitigt auftauchende Hindernisse, damit das Team effizient arbeiten kann.

Übernimmt ein erfahrener Konzepter (oder Designer oder Entwickler) eine dieser beiden Rollen, darf diese Person nicht gleichzeitig Teil des Entwicklungsteams sein. Auch Projektmanager oder Accounter könnten diese Rollen wahrnehmen. Es kommt eher auf die Persönlichkeit an als 
auf den fachlichen Hintergrund. Und obwohl Konzepter häufig die Rolle des POs und Projektmanager die des Scrum Masters einnehmen, sollte es da keine Automatismen geben, weil beide Rollen ein hohes Maß an Empathie, Kommunikationsfähigkeit und Stressresistenz erfordern.
Top

User Experience (UX) wird agil

Ursprünglich kommen agile Prozesse aus der Softwareentwicklung. Die Frage, wie UX-Aspekte dabei berücksichtigt werden, wurde jedoch ausgeklammert – unsere Zunft ist aufs Ausprobieren und auf Erfahrungswerte angewiesen. Beim Start des Projekts ist es wichtig, dem Briefing auf den Grund zu gehen: Welches Problem soll weswegen gelöst werden? In Briefings fordern Auftraggeber eine App, eine Facebook-Seite oder eine neue Website mit allem Zipp und Zapp. Aber ein reibungslos ablaufendes Projekt mit in sich stimmigem Konzept, atemberaubendem Visual Design und perfekt ausgefeilter technischer Umsetzung nützt nichts, wenn sich am Ende kein Nutzer für die Lösung interessiert. Am besten klären Sie die Frage nach dem richtigen Problem also schon im Sprint Null. Sollte diese Frage schwer zu fassen sein, können Sie ein separates Vorprojekt durchführen.

Themenseite Scrum, Jens Christian Jensen
Jens-Christian Jensen, Director Beratung & Konzeption, Pixelpark

»Die eigentliche Herausforderung ist, ein Team zu einem agilen Team zu machen«

Scrum sieht vor, dass am Ende eines Sprints der Nutzer selbst das Ergebnis im Review Meeting bewertet. Prinzipiell ist es richtig, Nutzer in einem Usability Test das Produkt testen zu lassen – am besten nach jeder Iteration. Im Projekt selbst ist es Aufgabe des Konzepters, als der oft zitierte »Anwalt des Nutzers« die Nutzerbedürfnisse zu vertreten – gegebenenfalls auch die mehrerer Zielgruppen mithilfe von zuvor durchgeführtem User Research und Personas. Außerdem muss er die Informationsarchitektur und konzeptionelle Fragen des Interaction und Interface Designs durchdenken. Wie muss die Website oder die App strukturiert sein? Wie laufen Funktionen genau ab? Was passiert im Falle eines Fehlers? Wann ist welches Element zu sehen? Die Antworten auf diese Fragen hält der Konzepter in den Akzeptanzkriterien der einzelnen User Storys fest und diskutiert sie im Team. Übergreifende konzeptionelle Anforderungen werden bei Scrum in der »Definition of Done« hinterlegt, beispielsweise dass eine hohe Performanz wichtig ist und Serveranfragen innerhalb einer bestimmten Zeit beantwortet sein müssen.

Im Sinne der bereits erwähnten Verantwortung aller für das Gesamtergebnis sind auch die Kollegen aus anderen Disziplinen gefordert – sie dürfen und sollen den Konzepter hinterfragen und bringen natürlich auch ihre visuelle, redaktionelle oder technische Perspektive in das Projekt ein. Beispiele hierfür sind der Designer, der darauf hinweist, dass ein Element im Raster bleiben muss und daher nicht nach Belieben positioniert werden kann, oder die Redakteurin, die entsprechend ihrer Expertise zu bedenken gibt, dass Texte in Russisch oder Finnisch länger laufen und dafür Platz vorhanden sein muss.

Bei Aperto haben wir gute Erfahrungen damit gemacht, wenn die Konzeption einen Sprint Vorsprung vor Design und Development hat. Die Disziplinen können auch leicht versetzt arbeiten. Es gibt keine starren Regeln: In einem Projekt zur Entwicklung eines Wissensmanagementsystems etwa hatten Design und Konzept denselben Vorsprung.
Top



Scrum-Projekte Schritt für Schritt managen

So gelingen agile Digitalprojekte

Unterstützen Sie das Team bei der Einführung! Diese Aspekte sind wichtig:

1. Beratung einholen
Lassen Sie sich bei der Einführung von Scrum und Co beraten, sei es von erfahrenen Kollegen aus dem Unternehmen oder durch einen externen Trainer. Dieser sollte das Team nicht nur mit dem Handwerkszeug vertraut machen, sondern ihm auch die agilen Werte nahe bringen.

2. Methodik vermitteln
Bringen Sie alle Teammitglieder zum Start auf den gleichen Wissensstand. Nur wenn alle ein gemeinsames Verständnis von den Abläufen haben, kann das Projekt rund laufen.

3. Eigenverantwortung klar machen
Machen Sie deutlich, dass jeder im Team die Verantwortung für das Gesamtergebnis hat. »Nach mir die Sintflut« oder gar Schuldzuweisungen haben in agilen Projekten keinen Platz.

4. Regelwerk einhalten
Verstehen Sie die Regeln von Scrum und anderen agilen Methoden nicht als Einengung, sondern nutzen Sie sie zur Orientierung! Springen Sie ins kalte Wasser und probieren Sie Scrum aus – vermeiden Sie faule Kompromisse wie »teilagil« oder »moderat agil«.

5. Lernaufwand berücksichtigen
Learning by Doing ist okay, denn theoretisches Wissen kann keine praktischen Erfahrungen ersetzen. Aber das bedeutet nicht, dass Agil-Einsteiger den Prozess von heute auf morgen beherrschen. Wer lernt, braucht Zeit zur Reflexion, um die neuen Erfahrungen zu verarbeiten.

Sorgen Sie für gute Startbedingungen! Darauf sollten Sie achten:

6. Das richtige Problem lösen
Hinterfragen Sie das Briefing und betreiben Sie Research, statt mit dem Kopf durch die Wand zu gehen. Nur so können Sie sicher sein, dass das fertig entwickelte Produkt dem Auftraggeber auch tatsächlich hilft.

7. Sprint null planen
Überlegen Sie sich zu Beginn von Sprint Null, welche Ergebnisse Sie benötigen, um mit dem eigentlichen Projekt anfangen zu können. Was muss geklärt werden, welche Fragen müssen beantwortet sein, welche Basics sind erforderlich? Da durch nutzen Sie die Zeit sinnvoll und schaffen ideale Startbedingungen.

8. Engagement klären
Teamwork ist in agilen Projekten noch wichtiger als in Wasserfallprojekten. Nehmen Sie daher nur Menschen ins Team auf, die sich auf agiles Arbeiten einlassen wollen.

9. Rollen richtig besetzen
Der Product Owner und der Scrum Master tragen besonde re Verantwortung und stehen unter hohem Druck. Fragen Sie sich ehrlich, ob Sie eine solche Rolle wirklich übernehmen können. Lautet die Antwort »Nein«, achten Sie darauf, die richtigen Persönlichkeiten mit diesen Jobs zu betrauen.

10. Projektraum einrichten
Eine effiziente Kommunikation ist für agile Projekte unverzichtbar. Daher sollten die Wege zwischen den Teammitgliedern kurz sein. Am besten versammeln Sie alle in einem Raum, der ausreichend Platz zum Aufhängen von Artefakten wie User Storys oder Scrum Board bietet. Ideal sind außerdem Whiteboards, damit das Team schnell Ideen skizzieren kann.

Bleiben sie agil! So machen Sie es:

11. User Storys kleinteilig formulieren
User Storys sollten nicht zu umfangreich sein, damit sich der Umsetzungsaufwand leichter und realistischer einschätzen lässt. Ein Sprint sollte für eine User Story reichen.

12. User Storys präsent halten
Hängen Sie die User Storys an die Wände Ihres Projektraums, seien es handgeschriebene Karteikarten oder Ausdrucke aus einem Wiki. Dadurch weiß das Team jederzeit, welche Storys aktuell relevant sind, welche Änderungen zuletzt besprochen wurden und welche Zusammenhänge zwischen den jeweiligen Storys bestehen.

13. Gemeinsam arbeiten
Diskutieren Sie Ideen im Team, fragen Sie Ihre Kollegen aus anderen Disziplinen, und geben Sie selbst konstruktives Feedback – in agilen Prozessen ist jeder Einzelne dafür verantwortlich, das Beste aus dem Projekt zu machen.

14. Meetingdisziplin einhalten
»Stand up« zum täglichen Austausch über den aktuellen Stand, »Review« oder »Retrospektive« – jeder im Team sollte die vorgesehenen Besprechungstermine wahrnehmen.

15. Retrospektiven wirklich durchführen
Bisweilen fallen sie aus Zeitgründen weg, aber sie sind für die Motivation im Team eines der wichtigsten Meetings überhaupt: Das Team bespricht hier, was im abgeschlossenen Sprint gut gelaufen ist und was es im nächsten verbessern will.

Top



Kleines Scrum-Glossar

Akzeptanzkriterien
Sie sind Teil jeder User Story. In ihnen legt das Team fest, welche Punkte erfüllt sein müssen, damit eine User Story als erfolgreich implementiert gilt.

Backlog
In ihm sammelt das Projektteam User Storys. Es gibt zwei Arten von Backlogs: Im Product Backlog stehen alle Storys des gesamten Projekts, die noch nicht umgesetzt wurden. Das Sprint Backlog enthält dagegen die User Storys, die das Team im aktuellen Sprint bearbeitet.

Burn-down Chart
Es macht den Projektfortschritt sichtbar, denn es zeigt, wie viele Storys noch zu erledigen sind. Je weiter der Sprint fortgeschritten ist, desto weniger Storys sind noch umzusetzen – das Chart zeigt dann eine abfallende Linie.

Retrospektive
Dies ist ein Meeting zum Rückblick auf den zurückliegenden Sprint. Was lief gut? Was sollten wir verbessern? Die Retrospektive dient dazu, aus den letzten Wochen zu lernen, damit der kommende Sprint besser verläuft.

Review Meeting
In ihm präsentiert das Team die Ergebnisse des Sprints dem Kunden. Das Ende eines Sprints ist auch eine gute Gelegenheit, um einen Usability Test durchzuführen.

Sprint
Eine Iteration von zwei bis vier Wochen Dauer, in der das Team die vorab vereinbarten User Storys umsetzt.

Sprint Null
Vor dem eigentlichen Projekt benötigen die verschiedenen Disziplinen Zeit, um nötige Grundlagen zu schaffen. Beispielsweise definieren die Designer Farben und Anmutungen, während die Technik das System aufsetzt. Der Sprint Null sollte nicht wesentlich länger dauern als die späteren Iterationen.

User Story
Eine Anforderung an das Projekt, die immer nach diesem Schema formuliert ist: »Als (Rolle) möchte ich (Handlung), damit (Nutzen).«

Zurück zum Haupttext
Top



»Die Umstellung ist das Schwierigste«

Interview mit Jutta Eckstein, Trainerin, Beraterin und Autorin für 
agile Softwareentwicklung

Jutta Eckstein, Trainerin, Beraterin und Autorin für 
agile Softwareentwicklung

Was sind die Stolpersteine bei der Einführung agiler Arbeitsweisen?
Jutta Eckstein: Meist ist es die so wichtige Umstellung auf sogenannte Featureteams oder crossfunktionale Teams: Unterschiedliche Disziplinen müssen gemeinsam Funktionalitäten entwickeln und diese auch in recht kurzen Zyklen – etwa zweiwöchentlich – liefern. In vielen Unternehmen ist der Silogedanke so ausgeprägt, dass eine echte Zusammenarbeit mit gegenseitiger Unterstützung nur schwer möglich ist.

Wie sollte ein Team konkret vorgehen, um auf agil umzustellen?
Eckstein: Es ist essenziell, auf existierende Erfahrung bezüglich Prozessen und Zusammenarbeit aufzubauen. Als Einstieg bietet sich eine Retrospektive an, sodass wertvolle Erfahrungen nicht verloren gehen. Darüber hinaus übernimmt das Team direkt die »Ownership« über den Prozess. Regelmäßige Retrospektiven tragen dann dazu bei, dass das kontinuierlich Dazugelernte transparent und die Zusammenarbeit ständig verbessert wird.

Oft arbeiten die Teams ja verteilt. Was ist dann zu beachten?
Eckstein: Das Team muss in der Lage sein, gemeinsam Funktionalitäten zu erstellen. Das bedeutet, dass die Mitarbeiter unabhängig vom Standort zusammenarbeiten. Das heißt die Teamgrenze orientiert sich weder an Raum oder Zeit noch an Aufgaben wie Analyse, Design, Entwicklung oder Test. Dafür müssen alle gleichermaßen auf Informationen zugreifen können. Nicht selten erweist sich eine Firewall als der größte Verhinderer einer standortübergreifenden Zusammenarbeit.

Top



Themenseite Scrum, Stefan Freimark
Stefan Freimark, Autor dieses Artikels, arbeitet als Lead UX Consultant bei Aperto Berlin und ist unter anderem Mitorganisator des UXcamp Europe

Buchtipps von Stefan Freimark:

Sven Röpstorff & Robert Wiechmann: Scrum in der Praxis. Heidelberg (dpunkt.verlag) 2012, 348 Seiten. 36,90 Euro. ISBN 978-3898647922.

Mike Cohn: User Stories für die agile Software-Entwicklung mit Scrum, XP u.a. Heidelberg (mitp Professional) 2010, 288 Seiten. 34,95 Euro. ISBN 978-3826658983.

Jutta Eckstein: Agile Softwareentwicklung in großen Projekten. Teams, Prozesse und Technologien. Strategien für den Wandel im Unternehmen. Heidel
berg (dpunkt.verlag) 2011, 270 Seiten, ISBN 978-3898647908

Bernd Oestereich, Christian Weiss: APM – Agiles Projektmanagement. Heidelberg (dpunkt.verlag) 2007, 454 Seiten, ISBN 978-3898643863

Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. München (Carl Hanser) 2012,239 Seiten,ISBN 978-3446432260

Andreas Rüping: Dokumentation in agilen Projekten. Lösungsmuster für ein bedarfsgerechtes Vorgehen. Heidelberg (dpunkt-verlag) 2013, 176 Seiten. 34,90 Euro. ISBN 978-3-86490-040-2.

Top