Wie wird ein klassisch arbeitendes Projekt zum Scrum-Projekt? Diese Frage beantworteten Colette Ziller und Dietmar Matzke, beide Project Manager bei OPITZ CONSULTING, in ihrer Session "Cultural Change - Der sanfte Übergang zum agilen Projekt" auf dem Agile Day der JAX 2010.

1. Colette Ziller, Projektmanagerin OPITZ CONSULTING München GmbH Dietmar Matzke, Projektmanager OPITZ CONSULTING München GmbH Der sanfte Übergang zum agilen Projekt JAX, Mainz, 03.05.2010 Cultural Change

2. Agenda Ausgangssituation Wandel der Stakeholder Wandel des Teams Ergebnisse

3. 1 Ausgangssituation

4. Rahmenbedingungen Entwicklungsteam aus Mitarbeitern des Kunden und Beratern von OPITZ CONSULTING System für 1200 Anwender Mehrere Standorte Unterschiedliche Fachabteilungen Koordinationsstelle für Anwender (Fachadministration) Vier Mitarbeiter 1st Level Support Anforderungsabstimmung Schulungserstellung und Koordination

5. Stakeholder Wer Fachbereiche Fachadministration Betrieb Linienverantwortliche Ad-hoc-Forderungen Direkte Kommunikation zu Teammitgliedern Fehlende Transparenz der Arbeitsweise des Teams Kein konsequenter Umgang mit Fehlern

6. Mitarbeiter Kunde Mitarbeiter OPITZ CONSULTING Team Fehler machen nur andere Individuelles Arbeiten Sicherheitsbedürfnis keine Abgabe von Schätzungen keine Verantwortungsübernahme Dienst nach Vorschrift Resignation bei Vorschlägen zur Fehlervermeidung Kritik nur hinter vorgehaltener Hand Interner konstruktiver Umgang mit Fehlern Arbeiten im Team Forderung von Verantwortung und Zuständigkeit Spezialisiertes Wissen Risikobewusstsein Lernbereitschaft Interne Offenheit

7. 2 Wandel der Stakeholder

13. 3 Wandel des Teams

14. Aussagen des Teams Die Planung ist stabiler und vorhersehbarer geworden. Die Transparenz im Projekt hat zugenommen. Scrum – ein Vorgehensmodell, bei dem man während der Arbeitszeit pokern darf. Man nimmt sich auch die Zeit, den Entwicklungsprozess zu verbessern. Probleme werden schnell identifiziert und können frühzeitig ausgeräumt werden.

16. Kommunikation erhöht

19. Arbeitsqualität erhöht

21. Überblick ProductBacklog und Release Backlog erzeugt

25. Teambuilding-Phasen: Forming + Storming

26. Teambuilding-Phasen: Norming + Performing

27. Performing-Effekte

28. 4 Ergebnisse

29. Aufgegeben Erhalten Stakeholder Ad-hoc-Anforderungen Monolithische Releases Direkte Kommunikation Sanktionierung von Fehlern Strukturierte Agilität Schnellere Auslieferungen Verbesserte Produktqualität Einheitliche Aussagen Erhöhte Abarbeitungs-geschwindigkeit Verbindlichere Planungen Motiviertere Teammitglieder

30. Team Zurückhaltung bei Verbesserungsvorschlägen Fehler verheimlichen oder ignorieren Sicherheitsnetze Isoliertes Arbeiten Schuldzuweisungen Verbesserung im Entwicklungsprozess Konstruktiver Umgang mit Fehlern Aktive Mitgestaltungs-möglichkeit Transparenz im Projekt Arbeits-Fokussierung Verbesserte interkulturelle Zusammenarbeit Aufgegeben Erhalten

31. Fazit Integration der Stakeholder ist erforderlich Vermeidung von Überforderung der Mitarbeiter ist sinnvoll Ausgleich durch Unternehmenskulturen ist wichtig Transparenz für Prozess ist notwendig Wechsel der Projektmentalität benötigt Zeit

32. Kontakt Colette Ziller, Project Manager OPITZ CONSULTING München GmbHWeltenburger Straße 4  81677 MünchenTel. +49 89 680098-0 Mail: colette.ziller@opitz-consulting.com Dietmar Matzke, Project Manager OPITZ CONSULTING München GmbHWeltenburger Straße 4  81677 MünchenTel. +49 89 680098-0 Mail: dietmar.matzke@opitz-consulting.com

33. Maßnahmenübersicht? Fehlerkultur Akzeptanz Retrospektiven Schätzpoker Architekturmeeting Rollendefinition Schutz des Teams Projektraum Meetings Zeit