Post on 13-May-2020
transcript
Einführung des Scaled Agile Framework bei ista – eine Retrospektive der Tester
17. November 2016 ▪ ASQF ▪ Thomas Rinke ▪ ista International GmbH
Agenda
� ista und das Scaled Agile Framework (SAFe)
� Einführung von SAFe – die Timeline
� Bewertung der Einführung
� Ideen und Empfehlungen
� Maßnahmen
Folie 217.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Unser Mission Statement
In Zeiten, in denen Ressourcen wie Energie und Wasser immer teurer und kostbarer werden, helfen unsere Produkte und Dienstleistungen, diese Ressourcen intelligent einzusparen. Dies ist unsere zentrale Mission, unsere unternehmerische und gesellschaftliche Aufgabe:
„WE MANAGE AND SAVE VALUABLE
RESOURCES SUSTAINABLY“
Folie 3
17.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Mietersicherheit
Lösungen zur Steigerung von Prozess-und Energie-Effizienz
Energiemanagement
Energielieferung / Smart Metering
Heizungs-EKG
Contracting
Energiedatenmanagement
Energieausweis
Webportal
Verbrauchsabrechnung
Messtechnik
Rauchwarnmelder
Trinkwasseranalyse
Energieabrechnung
Folie 4
Der ista Entwicklungsprozess basiert auf dem Scaled Agile Framework
Folie 517.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Die Einführung von SAFe wurde in der Retrospektiveals Timeline zusammengetragen
Teilnehmer: 6 Tester der Programm-Ebene
6 Tester der Team-Ebene
Facilitator
Betrachteter Zeitraum: November 2013 bis Januar 2016
Folie 617.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Vor Beginn der Einführung wurde das gesamte (interne) Team in einem Kick-Off informiert und involviert
November 2013
Alle internen Mitarbeiter der IT
Ziel der Veranstaltung
� Kommunikation
� Rollout Planungen
� Diskussion
Folie 717.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Verschiedene Schulungsmaßnahmen begleiteten die Einführung von SAFe, Agilität und agilem Test
Agile Schulungen
� Basisschulung
� Rollenspezifische Schulungen
Test-Schulung für Entwickler
ISTQB FLE Agile Tester
Folie 817.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Das erste Release Planning Event des DMI Release Train fand mit Beteiligung eines Coaches im April 2014 statt
Teilnehmer
� 3 Teams der Teamebene
� System Team
� Product Management Team
Zeitdauer: 2 Tage
Im Laufe der Zeit auf Basis von Inspect & Adapt viele Anpassungen am RPE
Folie 917.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
SAFe wurde schrittweise in die Teams ausgerollt –seit 2015 auch international
Rollout im 2. Releasetrain erfolgte teamweise
� Mai 2014 bis August 2014
� Ab 2015 internationale Teams
Folie 1017.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Im Verlauf der Einführung gab es immer wieder Umzüge, damit die Teams möglichst nah beieinander sitzen
Teams sollen möglichst nah beieinander sitzen
1 Team = 1 Raum
Teilweise benachbarte Räume
Standortübergreifende Teams
Folie 1117.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Nach der Timeline wurden einzelne Aspekte bewertet und klassifiziert
Folie 1217.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Die einzelnen Punkte wurden von den Teilnehmern bewertet, klassifiziert und präsentiert
Folie 1317.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Erwartet gute Aspekte
Automatisierung früher nur punktuell
Nun in einigen Teams sehr hoher Automatisierungsgrad
Teams schätzen die Räumliche Nähe
Effiziente Kommunikation
Folie 1417.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Unerwartet gute Aspekte
Unerwartete Etablierung des Meetings
Hoher Nutzen und Effizienz
Keine Frontalbeschallung
Hoher interaktiver Anteil
Gute Vermittlung der wesentlichen Konzepte
Folie 1517.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Erwartet schlechte Aspekte
Teamübergreifende Lösungskonzeption nicht einfach
Informationsverteilung insbesonderebei Planänderungen
Wenige Agile Master in Vollzeit
Rollenkonflikte
Zu geringes Ausfüllen der Rolle
Folie 1617.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Unerwartet schlechte Aspekte
Verschiedene Coaches
Coaching eher defensiv
Teilweise widersprüchliche Ratschläge
Fokus lag auf der Team-Ebene
Übertragung der Vorgehensweisen auf die Programm-Ebene schiwerig
Folie 1717.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Unerwartet schlechte Aspekte
Feature Times eher selten
Feature Times sehr kurz vor dem RPE
� Unklare Zielesetzungen
� Konzeptionslücken
Seit 2016 deutlich mehr Feature Times
Folie 1817.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Neutrale Aspekte
Selbstorganisation muss gelernt werden
Voraussetzungen für ein agiles Arbeiten müssen geschaffen werden
deutlich weniger Dokumentation
Unterschiedliche Einschätzungen, ob die Dokumentation ausreichend ist
Folie 1917.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Noch ein paar Anmerkungen
Im Rahmen der Retrospektive keine Aussagen zu
� Softwarequalität
� Kundennutzen
� Persönliche Zufriedenheit
Folie 2017.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Da diese Aspekte aber vermutlich auch interessant sind:
� Release heute mit deutlich mehr Gelassenheit
� Weniger Tickets aus Produktion
� Bessere Einschätzung durch den Kunden
� Höhere Mitarbeiterzufriedenheit
Auf Basis der Bewertungen wurden Ideen für eine optimierte Einführung und Weiterentwicklung generiert
Folie 2117.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Die Themenbereiche „Agile Master“ und „Infrastruktur“ erhielten beim Dot Vote die meisten Stimmen
Die Testsysteme müssen sich weiterentwickeln, um die Vorgehensweisen nach SAFe optimal unterstützen zu können.
Keine Rollenkonflikte
Agile Master als Wunschrolle
Folie 2217.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Bezogen auf die Einführung wird empfohlen, mit ersten konkreten Vorgaben für alle Ebenen zu starten
Programm-Ebene und das Zusammenspiel der Ebenen sollten besser berücksichtigt werden
Wunsch nach
� mehr Sicherheit
� weniger Ausprobieren
Folie 2317.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Weiterentwicklung der Agilität Agile Office
Zum 01. Juli 2017 wurde die Abteilung Agile Office gegründet
� Vollzeit Agile Master
Die Abteilung befindet sich im Aufbau
� ab 2017 vermutlich auch Agile Master auf Programm-Ebene
Folie 2417.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Weiterentwicklung der Agilität Tester werden Teil der Teams
Keine eigenständige Testabteilung mehr, ebenso keine Entwicklungsabteilung mehr
System-Team bleibt eigene (teamübergreifend tätige) Einheit
Austausch zur Disziplin „Testen“ in Community of Practice
Folie 2517.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Testsysteme entwickeln sich weiter
Die Testsysteme werden selbstorganisiert durch die einzelnen Teams auf verschiedenen Ebenen weiterentwickelt
� Keine zentrale Verantwortung der Testsysteme
� Relativ hoher Abstimmungsbedarf
� Budgetfragen
Beispiel:
� Feature zur Weiterentwicklung im aktuellen Release
Folie 2617.1
1.20
16 ▪
Tho
mas
Rin
ke ▪
Ein
führ
ung
des
Sca
led
Agi
le F
ram
ewor
k be
i ist
a
Vielen Dank für Ihre Aufmerksamkeit
Haben Sie noch Fragen?
Thomas Rinke
Expert Test Engineer
thomas.rinke@ista.com
Folie 27