Agile Testing in der Praxis Paradigmenwechsel als Game Changer Ein Praxisbericht über einen kompletten Schwenk in der Prozessorganisation eines Testprojektes. Markus Schell (CGI), Nadja Brendel (Daimler AG) 27.01.2016 © CGI Group Inc. 2013

Agenda 1

Vorstellung

2

Bestimmung der Ausgangssituation

3

Daraus resultierende Probleme

4

Wir ändern die Spielregeln > Jetzt agil

5

Was bei einer Einführung zu beachten ist

6

Fazit

2

Nadja Brendel Ausbildung

Rolle

Zertifizierungen

Dipl. Informatiker (FH) Software Engineering

Product Owner

Certified Requirements Engineer SOA-Analyst Professional Product Manager Certified ITM Business Consultant Certified Product Owner

Projekterfahrung Schwerpunkte RE und RM Beratung in Agilen Projekten Rolle Product Owner für MB Retailer Website

• Daimler AG • Tätigkeiten: • Entwicklung von effizienten Softwareentwicklung-Vorgehensmodellen gemäß Projekt-Rahmenbedingungen • Requirements Engineering und Requirements Management in IT-Großprojekten • RE-Methodenberatung in IT-Großprojekten • Business Consulting und Business Process-Optimierung • Ansprechpartner für Requirements Engineering und Management in Agilen Projekten inkl. Atlassian Toolchain JIRA and Confluence • Product Owner in Agilen Projekten

Markus Schell Ausbildung

Rolle

Zertifizierungen

Dipl.-Ing. (FH) Elektrotechnik

Test Manager

ISQi Certified Agile Tester ISTQB CTAL Testmanager ISTQB Certified Tester Foundation Level PRINCE 2 Foundation ITIL V3 Foundation

Projekterfahrung Schwerpunkte • Test Management • Agile Testing • Testwerkzeuge HP QC und Atlassian JIRA • Quality Management • ChangeRequest Management

• Kunden: Automobilbranche • Tätigkeiten: • Testmanagement und Testkoordination (Onside, Nearshore und Offshore) • Beratend in den Initialisierungsphasen von agilen Projekten für das Setup der Werkzeuge und Prozesse sowie Tätigkeiten als agiler Tester. • Ansprechpartner für Testwerkzeuge HP Quality Center und Atlassian JIRA und deren professionelle Projekteinführen. • Qualitätsmanagement (QS-Prüfung interner Dokumente anhand von QSChecklisten, Audits/Reviews beauftragen) • Assessments zum Software-Entwicklungsprozess und dessen Verbesserung in einer gesamtheitlichen Betrachtung.

Ganz nah und weltweit geschätzt Unsere Kompetenz vor Ort Führend in Deutschland* Hamburg  Business Innovation/Transformation Partner (Lünendonk, 2013)

Bremen

 Anbieter für Application Management (PAC, 2013)

Berlin

Hannover

 IT-Dienstleister im Telekommunkationssektor (PAC, 2013) Düsseldorf

Global gelistet*  Magic Quadrant for Application Testing Services, Worldwide (Gartner, 2014)

Köln Frankfurt/ Sulzbach

 Forrester Wave™: Enterprise Mobility Services (Forrester, 2013)

Top Arbeitgeber

5

2.300 Mitarbeiter

Darmstadt Mannheim Karlsruhe LeinfeldenEchterdingen München

 Führender Anbieter für Smart Grids (IDC, 2013)

* Auszug: CGI-Ranking 2013/2014

Erfurt

13 Standorte

Wie alles begann - Bestimmung der Ausgangssituation

6

Projekt und seine Ziele Ausgangssituation Projekt CMS Adobe Day CQ 5.5 als Plattform der Mercedes-Benz Internetpräsenz und besteht aus 2 Teilprojekten: 1. Vollständige Neuentwicklung der Händlerwebseiten. 2. Migration der bestehenden Händlerdaten Ziele (technische und fachliche) • Konfigurieren statt programmieren • Inhalte auf Interessen der Händlernutzer zuschneiden • Überleitung von Händler auf Produktinformationen

7

Projekt und seine Ziele Ausgangssituation Projekt Das Projekt soll das neue strategische CMS Adobe Day CQ 5.5 als Plattform der Mercedes-Benz Internetpräsenz bereitstellen und besteht aus 2 Teilprojekten: 1.

Die vollständige Neuentwicklung der Händlerwebseiten.

2.

Ein Migrationsprojekt der bestehenden CMS Anwendung und des bestehenden, bereinigten Contents (Händlerdaten) auf das neue strategische CMS.

Ziele (technische und fachliche) • Es gilt “konfigurieren statt programmieren”

• Den Händler sichtbarer zu machen • Inhalte auf Interessen der Händlernutzer zuschneiden • Überleitung von Händler auf Produktinformationen

8

Basis für die Umsetzung Basis In einer vorgelagerten Phase wurden unter Berücksichtigung des Status Quo der aktuellen Lösung, Studien, Befragungen Online Trends eine Analyse durchgeführt. Daraus wurde das Grobkonzept durch eine WebAgentur erstellt welches schlussendlich die Grundlage für das Pflichtenheft war. Der Aufbau der Webseiten erfolgt hierarchisch und modular nach CQ5 Standard. Dabei entstehen vielschichtige Abhängigkeiten, die nicht einfach zu verstehen sind.

9

Projektplanung – ist alles einkalkuliert? Feinspezifikation Stages

Jan

Feb

2013

März

April

Mai

Juni

Entwicklung (CGI)

Juli

August

Kalibrierung

• Feinspezifikation • Systemdesign

GoLive Termin

QG Req

Testfallerstellung

QG Design

• Entwicklung

01

02

03

04

Test (CGI) • Testfallerstellung

01

• Funktionale Tests

02 01

03 02

04 03

04

Systemtest (Daimler) • DEV-Umgebung

GoLive Termin

• INT-Umgebung

Abnahme (Daimler) • Abnahme Tester

QG Real

• Abnahme Fachbereich

QG Go Live Deployment

Meilenstein

10

Sept

Projektplanung – Folgende Probleme konnten nicht eingebplant werden … Rahmen für die Planung bildeten die vorgegeben Meilensteine

01 : Feinspezifikation - Theoretisch abgeschlossen • Sprechen denn alle Beteiligten die gleiche Sprache oder • werden x-Abstimmungsrunden notwendig sein? • weiß jeder wie die Anforderungen zu definieren sind?

02 : Testfallerstellung • Einarbeitung : Wie schnell kann Tester sich einarbeiten ? (fachlich/ technisch) ? • Nicht bekannt : Anzahl Testfälle und zeitlicher Aufwand • TCs CGI TCs Daimler => zu unterschiedlich => lange Diskussionen

03 : Kalibrierung • Reicht die Zeit alleine für die Fehlerbehebung? • Was passiert wenn Änderungen gefordert werden?

04 : Meilenstein GoLive • Vorgegebener Fertigstellungstermin (MUSS Termin) • Reicht das enges Zeitkorsett? 11

Projektplanung – ist alles einkalkuliert? Feinspezifikation: • •

Stages

•

Theoretisch abgeschlossen Weiß jeder wie Anforderungen zu beschreiben sind? Jan alle Beteiligten Feb März Sprechen die gleiche Sprache?

2013 April

Mai

• Systemdesign • Entwicklung

Juni

Juli

August

Sept

Kalibrierung:

Entwicklung (CGI) • Feinspezifikation

GoLive Termin

•

Testfallerstellung: • Einarbeitungszeit der Tester? • Überarbeitungen eingeplant? • Testfälle CGI und Daimler unterschiedlich => Abstimmung nicht eingeplant.

Test (CGI) • Testfallerstellung

QG Req

• •

Wie hoch ist die erwartete offene Fehleranzahl ? Fixer Endtermin Reicht das enge Zeitkorsett?

QG Design Kalibrierung IT 01

IT 02

IT 03

IT 04

SW-Iterationen IT 01

• Funktionale Tests

IT 02 IT 01

IT 03 IT 02

IT 04 IT 03

IT 04

Systemtest (Daimler) • DEV-Umgebung GoLive Termin:

• INT-Umgebung

•

Abnahme (Daimler)

•

• Abnahme Tester

Nur theoretische zeitliche Planung bis zum MUSS Termin Reicht das enge Zeitkorsett?

QG Real

• Abnahme Fachbereich

QG Go Live Deployment

Meilenstein

12

Oje… das war anders geplant !

13

Probleme tauchen auf Abhängigkeiten

Auswirkung auf Entwicklung und Test

Templates, Komponenten und Schnittstellen zu Drittsystemen.

• Abhängigkeiten ziehen sich über mehrere Iterationen. • Änderungen werden in nachfolgenden Iterationen nicht

Projektlaufzeit

Anforderungen werden ständig überarbeitet

Nicht geplante verlängerte Projektlaufzeit.

• Umgesetzte Anforderungen werden nicht mehr benötigt -

Testdurchführung

Testteam steht ständig unter Druck

Fehlerraten steigen pro Iteration stetig an.

• Geblockte Ressourcen wegen permanenter

berücksichtig.

Neue sind plötzlich ein „Muss“.

• Nachträgliche Anpassung von Schnittstellen notwendig.

Auswertungen und Neuplanungen.

• Eingangskriterien für die Abnahme werden nie erreicht. 14

Probleme tauchen auf Abhängigkeiten – Auswirkungen auf TEST : • Kein VOLLSTÄNDIGER TEST innerhalb einer Iteration möglich • Keine BERÜCKSICHTUNG der Änderung in nachfolgenden Iterationen.

Projektlaufzeit – Änderung der Anforderungen : • Abnahmetests auf VERALTETEN Anforderungen • Entwicklung & Test halten mit Anforderungsänderungen nicht mehr Schritt. • ANPASSUNG der SCHNITTSTELLEN wegen bereits neuerer produktiver Releases (wegen fortgeschrittenem Zeitplan)

Testdurchführung – Änderung der Anforderungen : • Abnahmetests auf VERALTETEN Anforderungen > Anzahl Fehler steigt • EINGANGSKRITERIEN (max. Fehleranzahl) für Abnahme NIE erreicht.

15

Probleme tauchen auf Abhängigkeiten

Auswirkung auf Entwicklung und Test

Templates, Komponenten und Schnittstellen zu Drittsystemen.

• Abhängigkeiten ziehen sich über mehrere Iterationen  Kein vollständiger Test innerhalb einer Iteration möglich.

• Änderungen werden in nachfolgenden Iterationen nicht berücksichtig.

• Abnahmetests werden auf veralteten Anforderungen durchgeführt.

Projektlaufzeit

Anforderungen werden ständig überarbeitet

Nicht geplante längere Projektlaufzeit.

• Umgesetzte Anforderungen werden nicht mehr benötigt, Neue sind plötzlich ein Muss.

• Entwicklung + Test halten mit Anforderungsänderungen nicht mehr Schritt. • Schnittstellenänderungen wegen neuer Releases von Drittsystemen.

Testdurchführung

Testteam steht ständig unter Druck

Fehlerraten steigen pro Iteration stetig an.

• Permanente Auswertungen und Neuplanungen binden die Ressource TM • Neu Priorisierung von Fehlern, damit diese schneller behoben werden. • Geforderte Eingangskriterien an max. Fehleranzahl für die Abnahme wird nie erreicht.

16

Willkommen im Hamsterrad Go Live Termin

6

Kommunikation an die Märkte

Neuer Termin wird kommuniziert Weiterer Termin wird kommuniziert Projektplanung

Anforderungen als Basis

+ Fehler CGI + Fehler Daimler + CR + Systemänderung

Iteration 03 04 01 02

5

Iterative Implementierung

1

2

Basis sind die neuen KPIs aus CGI Test und Daimler Test.

CGI Test Testfallerstellung, Testen, nur Prio 1 Fehler werden gefixt

Nachjustierung

4

3

Status Test / Abnahme

Daimler Test

Rückmeldung der Fehler an CGI, Unzufrieden mit spezifizierten Funktionen => CRs

Systemtest auf Staging-Umgebungen, Fehler werden protokolliert.

17

Willkommen im Hamsterrad Go Live Termin

6

Kommunikation an die Märkte Neuer Termin wird kommuniziert Weiterer Termin wird kommuniziert

Projektplanung

Iteration 01 - n

5

Iterative Implementierung

1

Basis ist die Anforderung + Fehler CGI + Fehler Daimler + CR + Systemänderung

2

Basis sind die neuen KPIs aus CGI Test und Daimler Test. Nachjustierung

CGI Test Testfallerstellung, Abgleich mit Spezifikation, Testen, Fehler protokollieren, nur Prio 1 Fehler werden gefixt, Übergabe an Daimler Test

4

3

Status Test / Abnahme

Daimler Test

Rückmeldung der Fehler an CGI (Anzahl abnahmeverhindernder Fehler), Fehlerbehebung muss eingeplant werden, Unzufrieden mit spezifizierten Funktionen => CRs

Systemtest der gelieferten Iteration auf unterschiedlichen Umgebungen, Fehler werden protokolliert.

Kreislauf wurde fundiert und intensiv gelebt, dauerte aber länger als es im Projekt geplant war und es wurden zusätzliche Iterationen eingefügt um die Probleme in den Griff zu bekommen  ÄNDERUNGSBEDARF! 18

Wir ändern jetzt die Spielregeln

19

Neues Spiel – neues Glück? Anforderungen

Jetzt im agilen Vorgehen

• Getrenntes Team für Anforderung

• Entwicklung und Test sind „außen vor“.

Test • Ausführlichste KPIs • aufwendige Planung • “Jemand“ hat Fehler

Alle am Softwareprozess beteiligten Rollen arbeiten gemeinsam an der Spezifikation.

Bereits in der User-Story berücksichtigt Vom Managen von Fehlern machen wir den Sprung zu einem lösungsorientierten Ansatz.

gemacht.

Abnahme

Kunde verantwortlich für Akzeptanzkriterien

• Diskussionen bei Abnahme

• Fachbereich bekommt mit Zeitverzug die Funktion

Keine Nachforderungen - sind Akzeptanzkriterien erfüllt, gilt der Sprint als erfolgreich! Aufwendige Abnahmeprozeduren entfallen 20

Neues Spiel – neues Glück? Anforderungen – jetzt Agil: • Bewusstsein für die Stabilität der Software (per Negativ-Testfälle durch Tester) wird bei Entwicklern gestärkt. • Schnelle Klärung: bei Bedarf erfolgt zum nächsten Refinement eine Rückmeldung vom Kunden.

Test – Bereits berücksichtig in Story: • Test entlang der Akzeptanzkriterien:  Der Kunde zeigt bereits was im wichtig ist (Fachabteilung, nicht Testabteilung)  Fokus der Tests auf die Hauptfunktionalität.

Abnahme – Kunde verantwortlich für Akzeptanzkriterien: • Sprint Review : Fachabteilung wird sofort die umgesetzte Funktionalität. – inkl. offener Fehler präsentiert > offener Umgang ! 21

Neues Spiel bei der Anforderung und Entwicklung Wasserfall

Agile (Scrum)

Spezifikation

Spezifikation

• Eigenständiges Team spezifiziert mit

• Anforderunten werden in den Refinements

Anforderungsteam des Kunden. Entwicklung und Test sind „außen vor“.

gemeinsam innerhalb des Scrum Team und mit dem Product Owner besprochen.

• Lange Entscheidungswege bei Detailfragen. • Fehler in Spezifikation werden durch Test

• Schnelle Klärung: bei Klärungsbedarf erfolgt zum nächsten Refinement eine Rückmeldung vom Kunden.

nicht aufgedeckt. Entwicklung

Entwicklung

• Entwickler sind in die Fachlichkeit nicht

• Bewusstsein für die Stabilität der Software (per Negativ-Testfälle durch Tester) wird bei Entwicklern gestärkt.

involviert.

• Technische Probleme lassen sich nicht oder

• Technische Probleme werden früh

nur schwer durch Spezifikationsänderungen umgehen.

berücksichtigt.

Alle am Softwareprozess beteiligten Rollen arbeiten gemeinsam an der Spezifikation.

Alle am Softwareprozess beteiligten Rollen arbeiten gemeinsam an der Spezifikation

22

Neues Spiel im Test Wasserfall

Agile (Scrum)

Testmanagement

Testen

• Ausführlichste KPIs über: • Testfallerstellung, -durchführung und

• Keine KPIs mehr: • Testfälle werden zu eigenen Sub-Story

dessen Status.

Items und durchlaufen die Lines des Scrum Boards.

• Fehler (interne und die des Kunden) werden wöchentlich bis täglich berichtet.

• Fehler werden nur dokumentiert (im

• Zeitaufwendige Steuerung der Tester

• Das Team steuert sich selbst. • Besseres Verständnis für die Technik und

Story Item) wenn sie nicht innerhalb eines Tages behoben werden können.

(Projektpläne, Abstimmung mit den Schnittstellen)

Fachlichkeit.

• Negativ behaftet: “Jemand hat Fehler

• Test entlang der vom Kunden geforderten

gemacht”.

Akzeptanzkriterien. Das gesamte Team ist verantwortlich für die Qualität.

Vom managen von Fehlern machen wir den Sprung zu einem lösungsorientierten Ansatz. 23

Neues Spiel für die Abnahme Wasserfall

Agile (Scrum)

Auslieferung

Auslieferung

• Nach Auslieferung an Kunde und Staging-

• Während Sprint Review ist die Fachabteilung

Prozess bekommt Fachabteilung die Umsetzung mit erheblichem Zeitverzug.

vor Ort und sieht sofort die umgesetzte Funktionalität.

Abnahmekriterien

Abnahmekriterien

• Diskussion über die Abnahmekriterien. • Fachabteilung hat nun doch andere

• Bereits in der Story müssen die Akzeptanzkriterien dokumentiert werden (diese sind im Detail VOR der Umsetzung zu dokumentieren).

Vorstellungen oder nachträgliche Änderungen werden gewünscht => dadurch wird häufig die Abnahme verweigert.

• Nachforderungen gehen in neue Stories ein.

Keine Nachforderungen - sind Akzeptanzkriterien erfüllt, gilt der Sprint als erfolgreich! Aufwendige Abnahmeprozeduren entfallen. 24

Und nun?

25

CGI : Mindset Change und in der Organisation Neues Mindset

Eine Kopfsache ! • Testmanager: bisher gemanagt – jetzt nur noch

“Alte” Denkmuster bei

coachende Rolle !

Testmanager & Tester

• Tester: bisher passive Rolle -> jetzt aktive Rolle

Organisation

Was krempeln wir intern um?

Projektmanager steuerte und plante die Aufgaben / Releases.

• Das Team muss Verantwortung übernehmen (für

Neues Team

Mit Bedacht zusammenstellen

• Soft skills • Hard Facts

• Extreme (introvertiert extrovertiert) vermeiden. • Ausgebildete und erfahrene Tester einsetzen.

Schätzung, Planung, Lieferung und Eskalationen)

• Steuerung wird ins Team übertragen !

26

CGI : Mindset Change und in der Organisation NEUES MINDSET – Eine Kopfsache: • Klare Meilensteine wie Ready to Test, Release-Liefertermin mit denen Tester planen nicht mehr existent.

Organisation – Was krempeln wir um ? • Eskalationen werden direkt mit dem Kunden besprochen. • Jetzt muss das Team Verantwortung (für Schätzung, Planung und Lieferung) übernehmen.

Neues Team: • KOMMUNIKATION ist elementar wichtig (DoD, Schätzen, Infos einholen)

• „ALTE GEDIENTE“ haben Schwierigkeiten mit der neuen Vorgehensweise. 27

CGI : Mindset Change und in der Organisation Neues Mindset

Eine Kopfsache !

“Altes” Denkmuster bei

Testmanager: bisher: Steuerung der Tester und Planung der Tests , jetzt : Test Lead, unterstützt mit seinem Wissen die Anforderung, Entwicklung und Test.

• •

Testmanager und der Disziplin der Tester

Tester: bisher: Klare Meilensteine wie Ready to Test, Release-Liefertermin mit denen Tester planen, jetzt:

Organisation

Was krempeln wir intern um?

Die Projektleitung hatte bisher die Aufgabe der Schätzung, Planung, Steuerung und Eskalation mit dem Kunden.

• Bisher hatte das Team keine Aufgaben im Management. Jetzt muss das

Neues Team

Mit Bedacht zusammenstellen

• Soft skills • Hard Facts

• Extreme (introvertiert extrovertiert) sind zu vermeiden.

Team Verantwortung (für Schätzung, Planung und Lieferung) übernehmen.

• Eskalationen werden direkt mit dem Kunden besprochen. • Steuerung wird ins Team übertragen !

• Kommunikation ist elementar wichtig (DoD, Schätzen, Infos einholen) • „Alt Gediente“ haben Schwierigkeiten mit der neuen Vorgehensweise. • Ausgebildete und erfahrene Tester einsetzen. 28

Kundenseite : Notwendige Änderungen Neues Mindset

Erwartungshaltung Kunde

“Altes” Denkmuster:

• kein “bis zum Zeitpunkt x erwarten wir die Funktionen A, B & C”. • Wichtigkeit gemessen an Leitfragen - nicht an Kosten. • „Finished is better than Perfect“

• alles ist wichtig und • Basis der Umsetzung sind EUROS

Organisationskette

Die Gesamtkette muss funktionieren

• • • •

• Management überträgt Entscheidungskompetenz an PO • Sauber definierte Anforderungen müssen im Refinement direkt

> Management

> Anforderungen > Testen > Betrieb

Neues Team • Soft Skills • Hard Facts

entschieden und dokumentiert werden.

• Betrieb muss alle 2 Wochen deployen können.

Das Scrum Team mit Bedacht zusammenstellen • Vertrauen in eine bestimmte Person haben • Kommunikation ist elementar wichtig (DoD, Schätzen, Infos einholen)

• Ausgebildete und erfahrene Tester einsetzen. 29

Kundenseite : Notwendige Änderungen Neues Mindset

Erwartungshaltung Kunde

Altes” Denkmuster:

• kein “bis zum Zeitpunkt x erwarten wir die Funktionen A, B und C” mehr.

•

Viele Themen (Funktionen, Änderungen, Fehler) waren wichtig

•

Auf Basis von EURO wurde entschieden was umgesetzt wird

 direktes Ranking der Funktionen nach Wichtigkeit

• Wichtigkeit gemessen an Leitfragen nicht an Kosten

• „Finished is better than Perfect“

Organisationskette

Die Gesamtkette muss funktionieren

• Management

• Management überträgt Entscheidungskompetenz an den Product Owner

• Anforderungen

• Sauber definierte Anforderungen müssen im Refinement direkt entschieden und

• Testen

• Tests müssen parallel eingeplant werden

• Betrieb

• Betrieb muss in die Lage versetzt werden alle 2 Wochen zu deployen

Neues Team

Das Scrum Team mit Bedacht zusammenstellen

• Soft Skills • Hard Facts

• Vertrauen in eine bestimmte Person haben

dokumentiert werden

• Extreme (introvertiert extrovertiert) sind zu vermeiden. • Kommunikation ist elementar wichtig (DoD, Schätzen, Infos einholen) • „Alte Hasen“ haben Schwierigkeiten mit der neuen Vorgehensweise. • Ausgebildete und erfahrene Tester einsetzen. 30

Benefit des Game Changers

Funktionalität & Business Value

Schnelle Reaktionszeit

(stehen im Vordergrund) (auf Produktprobleme)

Gemeinsames Verständnis

CRs intensiv durchdacht

Team rückt zusammen

(von Kunde & Lieferant)

(liefert Fachabteilung)

(Spez., Dev., Test)

Welche Items sind wichtiger?

Verständnis für die Arbeitsweise und Probleme der jeweils anderen Rolle wird gefördert.

Fokus liegt auf der Funktionalität.

Der Fokus liegt auf Das neue Problemlösungen. Vorgehen fördert ein besseres Lösungsorientierter Es erfolgt eine gemeinsames Ansatz. dynamische Verständnis. Anpassung der Jedes Add-On wird Wichtigkeiten von Technische und hinterfragt: Bringt Items. fachliche es einen Mehrwert Notwendigkeiten für den Business werden im Dialog Value? ausgetauscht.

31

Kann etwas zurückgestellt werden? Funktioniert es nicht einfacher?

Sie wollen in Zukunft agil vorgehen ? Behutsam mit EINER Änderung beginnen – in der folgenden Reihenfolge: N1 Team aufbauen und schulen 2 Neues Vorgehen etablieren 3 Einarbeitung in die Fachlichkeit Gleichzeitige Einführung alle 3 Änderungen => Verständnis, dass die ersten Sprints nicht geschafft werden! 32

Sie wollen in Zukunft agil vorgehen ?  Dann muss man sich von alten Gewohnheiten trennen,

neue Wege erkunden und immer wieder überprüfen, wie man sich noch weiter verbessern kann.

33

Sie wollen in Zukunft agil vorgehen ? Dann beginnen Sie behutsam und führen Sie am Anfang nur eine neue Änderung ein. Überprüfen Sie danach immer wieder wie weit Sie mit dieser Änderung kommen. 1 Team aufbauen und schulen Ne

2 Neues Vorgehen etablieren Ne

3 Einarbeitung in die Fachlichkeit Ne

Sollten alle 3 Veränderungen gleichzeitig eingeführt werden, ist Verständnis für die ersten Sprints notwendig, dass diese vermutlich nicht wie geplant geschafft werden können. 34

35

Die wichtigste Person in Scrum ist der Product Owner. Nicht die Methoden scheitern, sondern das Mindset (weil die Menschen es nicht wollen). “Management of Change” ist kein Selbstläufer.

36

FAZIT Wichtigste Person, mit der Scrum steht und fällt :  Product Owner  Benötig „Standing“ im Unternehmen => kein PL darf „dazwischenfunkten“ und den Prozess ändern oder eigene ihm wichtige Themen hochpriorisieren

Nicht die Methoden scheitern „Ich habe immer so gearbeitet“, „Warum soll ich mich auch noch um die anderen und deren Probleme kümmern?“

Management of Change :  Die Menschen müssen immer wieder eingeschworen werden : durch einfaches TUN – und nicht ewig vorher planen und konzeptionieren. 37

Die wichtigste Person in Scrum ist der Product Owner: Benötig „Standing“ im Unternehmen => kein Projektleiter darf „dazwischenfunken“ und den Prozess ändern oder eigene ihm wichtige Themen hochpriorisieren. Nicht die Methoden scheitern, sondern das Mindset (weil die Menschen es nicht wollen): „Ich habe immer so gearbeitet“, „Warum soll ich mich auch noch um die anderen und deren Probleme kümmern?“ “Management of Change” ist kein Selbstläufer: Die Menschen müssen immer wieder eingeschworen werden: durch einfaches TUN – und nicht ewig vorher planen und konzeptionieren.

38

Vielen Dank.

Wir stehen zum Gespräch für Sie zur Verfügung!

Markus Schell Senior Consultant Mobile: +49 170 579 1369 E-Mail: [email protected]

40

Backup - Abhängigkeiten

41

Herausforderung auch in agilen Projekten Wie gehen wir mit nicht agilen Projektteilen um, wie z.B.: • Regressionstests?

• Spezialisten sind erforderlich (nicht über das Scrum Team zu stemmen) diese zu erstellen. • Eine permanente Pflege ist notwendig. • Performance- oder Lasttests ? Sie machen nur Sinn: • wenn diese auf fast vollständig entwickelten Systemen durchgeführt werden, oder • wenn sie auf produktionsnahen Umgebungen durchgeführt werden.

Ein Versuch, diese Probleme in den agilen Prozess zu integrieren wird als Hardening Iteration (nach iSQI - CAT) beschrieben. ABER: man verlässt den Scrum Prozess und damit die Fundamentals.

42