Agile Methoden ohne Hype

Größe: px

Ab Seite anzeigen:

Download "Agile Methoden ohne Hype"

Steffen Beltz
vor 10 Jahren
Abrufe

1 Agile Methoden ohne Hype Bastian Helfert Torsten Fink akquinet AG

2 Microsoft/.NET 650T EK akquinet AG 1,5 Mio. EK Outsourcing 400T EK Java 400T EK SAP 100T EK International 140T EK

3 Die präagile Zeit Dominanz des Wasserfallmodells Umfassende Spezifikationsphasen vor Implementierungen Späte Aufdeckung von Spezifikationsfehlern Langsame Reaktion auf Anforderungsänderungen Softwarekrise Fachlich unpassende Anwendung bei gesprengten Budgets 3

extreme Programming 2001: Veröffentlichung des agilen

4 Dann kamen: Scrum und XP 1993: Jeff Sutherland führt erstes Scrum- Projekt durch 1996: Kent Beck entwickelt extreme Programming 2001: Veröffentlichung des agilen Manifests...u.v.m. (FDD, Crystal Clear, The Eclipse Way, Kanban) 4

5 Warum funktionieren sie so gut? Konzentration auf das Wesentliche Implementierung von Fachlichkeit Reduktion formaler Wasserköpfe Entwickler als kreative, verantwortliche Mitentscheider statt als tumbe Befehlsempfänger Durchgängige Qualitäts-/Selbstkontrolle Testgetriebene Entwicklung, Pair Programming, Stehungen, kurze Iterationen 5

6 Was bedeutet das für die Firma? Dadurch erhöhte Produktivität Flexibilität (= Agilität) Qualität Transparenz Somit: schnellere Time-to-Market Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. 6

7 Glauben Sie dran? 7

8 Knirschen bei Einführung agiler Methoden Vielfältige Probleme Menschliche, organisatorische, historische/kulturelle Schwierige adäquate Rollenbesetzung insb. Produktverantwortlicher bei Scrum Für alles verantwortlich, aber kaum Steuerungsmöglichkeiten. Dysfunktionale selbstgesteuerte, eigenverantwortliche Teams Alle sind verantwortlich = keiner ist verantwortlich... Ein (übliches) Ergebnis: Alte Prozesse mit agilen Vokabeln 8

9 Weitere Probleme im Umfeld Schwierige Koordination zwischen Teams Abstimmung von Teilprojekten mit komplexen Abhängigkeiten Scrum-Master als Prozessverantwortlicher ohne Projektverantwortung insb. kritisch bei Einsatz externer Dienstleister 9

10 Ende Ianus Wieso diese Diskrepanz? Was sind die Ursachen? Anfang 10

11 Angst führt zur dunklen Seite der Macht... 11

12 Beispiel: Stehung (a.k.a. Standup) Konzept Jeder Entwickler gibt jeden Tag erweiterten Statusbericht (Erledigtes, Geplantes, Probleme) Ein Effekt: Transparenz der Entwicklerleistung Gefahr: Angst der Entwickler vor Offenbarung selbst wahr genommener Schwächen, Sanktionen 12

13 Was kann man tun? Was bekommt man dann? Gegenmaßnahme: Etablierung der Werte intensive, persönliche, direkte, offene, ehrliche Kommunikation Feedback Mut Respekt Grundlage dafür: Vertrauensbasis Gewünschte erreichbare Effekte: Kenntnis des gesamten Projektstands im Team Frühzeitiges Aufdecken von Synergie- und Konfliktpotenzialen Stärkung: Teamgefühl, Identifikation, Verantwortungsgefühl 13

Beispiel: Programmierung im Paar Konzept: Zwei Entwickler realisieren gleichzeitig eine Anforderung an einem Rechner Mögliche Gefahren: Nur einer

14 Beispiel: Programmierung im Paar Konzept: Zwei Entwickler realisieren gleichzeitig eine Anforderung an einem Rechner Mögliche Gefahren: Nur einer arbeitet: < 50% Produktivität Erhöhte Spannungen, Konfliktmehrungen im Paar Team zerfällt in 2er-Gruppen => kein Wissensaustausch, Spannungspotenzial 14

15 Was kann man tun? Was bekommt man dann? Gegenmaßnahmen: Zuerst: Danach: Einverständnis vom Team holen Schulungen/Workshops (Techniken, Soft-Skills) Gewünschte erreichbare Effekte: Höhere Qualität, weniger Fehler durch 4-Augenprinzip dadurch Kosteneffizienz Umfassende Wissensverbreitung im Team Reduktion des Truck-Faktors Konstante Weiterbildung Einhaltung von Standards und Konventionen Spaß an der Arbeit durch soziale Interaktion 15

16 Mal ein Versuch der Zusammenfassung... 16

17 Woher kommt die Angst? Transparenz Technische Projektverantwortung beim Entwickler Soziale Kompetenz als Muss-Eigenschaft Kontrollverlust bei Entscheidungen Manager geben Entwicklern die Kontrolle Kooperativer statt autoritärer Führungsstil Neue Methoden führen zu Veränderungen 17

18 Der Abschluss 18

19 Wir mögen agile Methoden weil sie den Menschen/Entwickler wieder in den Mittelpunkt stellen, sie ergebnisorientiert sind, (soll heißen: Die Anwender bekommen das, was sie brauchen.) sie durch viele Feedbackschleifen eine hohe Flexibilität/Angemessenheit ermöglichen, und sich nicht an einem dokumentenlastigen Prozess festklammern. 19

20 Die Herausforderung ist..... der Faktor Mensch 20

Ähnliche Dokumente

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock [email protected] Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann