SlideShare ist ein Scribd-Unternehmen logo
Scrum-Breakfast Bern, 30.03.2011 Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach Ferdinand Hodel, IT Post Joscha Jenni, mimacom ag Peter Stucker, CSC Post Mail Informationstechnologie
Aufbau und Agenda
Projektsicht Autraggeber – Product Owner Sortierung PostMail Täglich 15 Millionen Briefe und Zeitungen, Zehntausende Briefbehälter, Hunderte Transporte 9 Briefzentren, 2 Retourenzentren 4‘600 Leute, 40 Sortiermaschinen, ca. 500 Handsortiergestelle ca. 300 unterschiedliche Sortierprogramme Sortierplanung ca. 600 Mutationen/Monat Simulationen für grössere Anpassungen Sortierung Komplexe Zusammenhänge
Projektsicht IT – Scrum Master I IT1-Softwareentwicklung in Zahlen Personal: 173 Mitarbeitende,  PE = 161.99  Softwareentwicklung: 4 Entwicklungsumgebungen (J2EE, .NET, SAP, Oracle) 2 ESB-Produkte (JCAPS von SUN & PI von SAP) >10 SAP ERP-Systeme Intranet:  über 300 Applikationen pro Tag: ca. 3.2 Mio. Zugriffe, ca. 26 Mio. Seiten, ca. 1.3 Mio Besuche Projekte/Dienstleistungen: Weit über 100 Projekte pro Jahr > 33 Mio. CHF. Umsatz im Bereich Dienstleistungen 2009
Projektsicht IT – Scrum Master II So ist IT1 aufgestellt Stand Januar 2011 IT1 Geschäftsanwendungen Urs Rudolf von Rohr Stv. Andreas Blasenbrei IT101 Postapplikationen Jean-Louis Fatton IT102 ERP Systeme Christos Mitos IT103 Produktivitätslösungen Andreas Blasenbrei IT11  Projektmanagement Norbert Zurwerra Stv. Martin Sägesser IT12  Java Roland Räuftlin Stv. Markus Günther IT13  Microsoft/.net Kurt Jost Stv. Stefan Haefeli IT14  Oracle/JCAPS Martin Rohrer Stv. Claudio Baldussi IT15  CCC SAP Reto Gentinetta Stv. Michel Frey IT16  Standort Bellinzona Roger Mossier Stv. Paolo Casella Chef Architektur Martin Schwab Stv. Reto Pestoni Sekretariat Nadja Günthör * Jacqueline Marti * Betreuung lernender Person
Projektsicht IT – Scrum Master III IT-Post offerierte die Softwarelösung auf der Basis der Systemanforderungen mit 602 PT und einer Umsetzungszeit von rund 12 Monagen Dienstleistungen Aufwand PT Modul Persistenz 30 Modul Security/Visibility 16 Modul Traceability 2 Modul ReleaseMgmt 53 Modul Plandatenpflege 20 Modul ReleaseCalculation 48 Modul Änderungen zwischen zwei Release ermitteln 40 Modul ReleaseVerifikationDistribution 10 Modul Excel Import/Export 50 Modul Intf. Zstam -> SortPla 54 Modul Intf. SortPla -> Zstam (LPM/SPM) 26 Modul BO Reports 56 Modul Dokumentation 32 Architektur 18 Deploy 15 Einführung 22 Projektmanagement 66 Reserve 44 Total Aufwand in PT 602
Ausgangslage und Einstieg Sicht Product Owner I Darf ich das? IT Post „Wir wollten schon lange ein Projekt nach Scrum abwickeln“.  Wie weit soll ich als PO Einfluss nehmen, um „Scrum-But“ zu verhindern? Wie weit soll ich die Management Awareness über die Methode treiben? Das Vorhaben (und der Hauptknowhowträger…) hat einen explorativen Charakter.  Eine Lösung ist dringend notwendig.
Ausgangslage und Einstieg Sicht Product Owner II Rollen und Verantwortlichkeiten, inkl. QS Die meisten Entwickler sind nur 50-60% Ressourcen.    relativer Aufwand für Scrum „Meetings“ ist hoch    sichtbarer Fortschritt pro Sprint (3 bzw. 4 Wochen) eher gering Spezialisierung war wichtig, auch wenn wir als Team agieren (Lösungsarchitekt, SW-Architekt, GUI Verantwortlicher,  DB-Verantwortlicher. u.a.).  Für das agile Vorgehen ist eine entwicklungsnahe QS von Vorteil (mit technischen Skills im Bereich DB-Abfragen und idealerweise sogar Programmierskills für automatisierte Tests).
Ausgangslage und Einstieg Sicht Scrum Master I Scrum Einführung /Schulung Zu Beginn wurde eine Scrum-Ausbildung mit dem Kernteam durchgeführt, jedoch veränderte sich die Besetzung im Team aufgrund der knappen Ressourcen nachhaltig. Die neuen Teammitglieder konnten nicht genügend geschult werden.  Funktionsweise der Methode Scrum wurde zum Teil missverstanden oder nicht einheitlich interpretiert. Einführung Jira als Tool für agile Projekte erfolgte on-the-job.
Ausgangslage und Einstieg Sicht Scrum Master II Rollen und Verantwortlichkeiten, inkl. QS Die Kernteammitglieder mussten sich in ihrer Rolle finden. Der Product-Backlog Owner nimmt mehrere Rollen ein: -  Auftraggeber Stellvertreter -  Gesamtprojekt-Leiter -  Scrumteam Mitglied QS sehr weit weg vom Geschehen Der Scrum-Master konnte die erforderliche Zeit in den ersten Sprints bei weitem nicht aufbringen. Die Verantwortung des Scrum-Teams wurde teilweise massiv unterschätzt.
Ausgangslage und Einstieg Sicht Scrum Berater I Einführung, Schulung, Know-How Transfer Frühe Schulungen des Teams  zahlen sich aus Neue Team Mitglieder wie in der Einführung schulen
Ausgangslage und Einstieg Sicht Scrum Berater II Rollen und Verantwortlichkeiten, inkl. QS Stakeholder waren klar Product Owner und Scrum Master definiert Scrum Team Rollen haben sich im Scrum Team entwickelt QS konnte leider nie richtig integriert werden Scrum Master zu Beginn Scrum-Know-How Träger oder nicht?
Ausgangslage und Einstieg Key Points QS ist intensiv ins Scrum-Team zu integrieren (erfordert ev. ein Überdenken des Rollenverständnis und der Arbeitsweise von QS). Bei der Einführung von neuen Methoden sind entsprechend die Ressourcen einzuplanen (Ausbildung und die ersten Sprints).  Spezialisierte Rollen helfen dem Projekterfolg.
Scrum-Prinzipien Sicht Product Owner I Sprintzielvereinbarungen Die detaillierten Spezifikationen aus den Anforderungen werden mit einem kleinen zeitlichen Vorlauf auf die Entwicklung erarbeitet.    z.T. Verlagerung Termindruck von IT zu Fach „ Ziele unterhalb des Radars“: Infrastruktur, Datenlogik, u.v.a.  Achtung: QS betrachtet eventuell nur GUI‘s als „potentiell lieferbare und einsetzbare Software“  Über die Sprintziele kann das Team an die Vision des PO herangeführt werden.  Koordination der Einzeltasks ist auch bei Scrum zwingend notwendig, um die Ziele zu erreichen. Persönliche Verantwortung jedes einzelnen ist ein (zu) hehres Ziel.
Scrum-Prinzipien Sicht Product Owner II „ Fail fast, Learn fast“    weniger Stress für alle Ressourcen- und Knowhow-Engpässe früh adressierbar. Viele kleine Fehler statt wenige grosse Fehler. Deployment Prozess wird eingespielt.  Transparenz bei Erfolg und Misserfolg Die erreichte Transparenz ist für den PO enorm wichtig und für den Projekterfolg massgeblich verantwortlich.  „ Misserfolg“? „Planungsfehler“? „Niederlage“? Nicht erreichte Ziele sind schwer als Chance kommunizierbar.
Scrum-Prinzipien in der Einschätzung der Beteiligten: Sicht Product Owner III Einschätzung: das agile Vorgehen hat einen  stark positiven Einfluss auf die Qualität der Lösung. Positive Einschätzung  ist mit zunehmender Erfahrung deutlich gestiegen.
Scrum-Prinzipien Sicht Scrum Master I Sprintzielvereinbarungen und  Transparenz bei Erfolg und Misserfolg Absolute Transparenz gegenüber dem Projektauftraggeber. Offensichtliche Schwächen bezüglich der Stabilität in der Entwicklungsumgebung und bezüglich dem Ausbildungsstand der Entwickler. Das Nichterreichen von Sprintzielen wird zu jedem Sprintende unmissverständlich aufgezeigt. Beim Nichterreichen der Sprintziele entsteht der Eindruck, dass für die jeweilige Situation einzig und allein die IT verantwortlich ist.
Impressionen  I  -  Burn Down Chart
Impression II  -  Stimmungsbarometer
Scrum-Prinzipien Sicht Scrum Master II Definition of Done, Sprint- und Task-Readiness Im Projektkern- und im Scrumteam tat man sich schwer, die Definition of Done zu finden. Die QS war bei der Defintion of Done nicht beteiligt. Bezüglich den Anforderungspapiere wurde keine Definiton of Done formuliert, dies weder bei der Erstellung noch bei der Veränderung dieser. Welcher Prozess läuft ab, wenn ein Module im Status “done“ infolge Fehler von der Entwicklung nochmals bearbeitet werden muss.
Scrum-Prinzipien Sicht Scrum Master III Eigenverantwortung  Die Scrum-Philosophie basiert auf einer hohen Selbstverantwortung vom Scrum-Team, resp. von jedem einzelnen Entwickler. Inwiefern wird die Verantwortung vom Management entsprechend delegiert? Inwiefern ist sich der Entwickler dessen bewusst?
Scrum-Prinzipien Sicht Scrum Master IV Timeboxing Eines der wichtigsten Scrum-Prinzipien überhaupt. Konnte fast nie eingehalten werden, beginnend mit den Ausführungen des Produkt Owners zu Beginn der Sprintplanung, bis hin zu den Abnahmetests. Timeboxing bedeutet, genügend kleine Pakete zu definieren, welche in der geplanten Zeiten bearbeitet werden können. Hängt sehr eng mit den Sprintzielen zusammen.
Scrum-Prinzipien Sicht Scrum Berater I Sprintzielvereinbarungen Endlich ein Product Owner der Ziele formuliert! Transparenz bei Erfolg und Misserfolg Ziele wurden leider vom Team am Anfang zu wenig hinterfragt und/oder waren zu wenig SMART definiert… …  was zu Frustration beim Review-Meeting führte
Scrum-Prinzipien Sicht Scrum Berater II Definition of Done Definition of Done war in einem Dokument… zu wenig transparent und zu wenig in den Köpfen Sprint- und Task-Readiness Product Owner muss mal spezifizieren, sonst… Sprintlänge?
Scrum-Prinzipien  Sicht Scrum Berater III Eigenverantwortung Von Person zu Person unterschiedlich, jedoch durchwegs positiv! Starke Persönlichkeiten/Leaders haben Verantwortung getragen Timeboxing …  time over…  War schwierig durchzusetzen
Scrum-Prinzipien Key Points Timeboxing situativ anwenden Fortwährende Feedbackloops erzwingen die Entdeckung und die Beseitigung von Hindernissen auf dem Weg zum Projekterfolg. Die resultierende Transparenz dient dem Auftraggeber und –nehmer.
Rahmenbedingungen Sicht Product Owner I Vertragsform Auftraggeber und –nehmer im gleichen Konzern  Werk mit Fixpreis  Change Managment Change Diskussion „wie klassisch“  Auf Durchgängigkeit von Pflichtenheft    Angebot    Tasks achten.   Schätzung und erbrachter Aufwand vergleichen Transparenz durch Scrum nützt Auftraggeber   Gegenleistung: Auftraggeber honoriert nachvollziehbare Mehraufwände konziliant
Rahmenbedingungen Sicht Scrum Master I Vertragsform  Fixpreis vs Design to Cost Vertrauen, resp. nicht das Gefühl zu haben, über den Tisch gezogen zu werden Konfliktkultur zwisschen Auftraggeber und –nehmer Auftraggeber und –nehmer im gleichen Konzern IT-Post als NonProfitOrganisation ?!
Rahmenbedingungen Sicht Scrum Master II Infrastruktur (Jira, das Tool) Das Projekt wurde in Jira zu kompliziert und zu aufwendig angelegt Jira besitzt keine Schnittstelle zum Faktuierungssystem von IT-Post und somit müssen aufwände doppelt rapportiert werden Zeitliche Abhängigkeiten können in Jira nicht dargestellt werden Jira ist in der Handhabung nicht einfach und als Web-Applikation träge Jira ist in einer reduzierten Form den Projekten möglichst einheiltich zur Verfügung zu stellen
Rahmenbedingungen Sicht Scrum Berater I Tooling Ziele definieren! Mehr Training, bessere Dokumentation Vertragsform Fakt Linke rechte Hosentasche - Politikum Konflikt: Vertrag mit IT oder? PO vs. SM…
Rahmenbedingungen Sicht Scrum Berater II Infrastruktur Entwicklungsumgebung und Aufbau Plattformen Zu spät ready… organisatorische und betriebliche Schnittstelle, resp. Abhängigkeit Essentiell für agile Entwicklung
Rahmenbedingungen Key Points Auch bei den Infrastrukturverantwortlichen und dem  Change Management muss das Verständnis für das agile Vorgehen gefördert werden.  Auch hier gilt:  Agilität bedeutet nicht Chaos Agiles Vorgehen lässt sich mit Fix-Preis Werkverträgen vereinbaren. Ein Planungs- und Trackingtool ist zur Unterstützung des agilen Vorgehens zwingend erforderlich.
Bilanz
Impression III  -  Stimmungsbarometer So macht es definitiv mehr Spass!

Weitere ähnliche Inhalte

Was ist angesagt?

Agile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus NotesAgile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus Notes
Werner Motzet
 
Scrum & Kanban im Agenturgeschäft
Scrum & Kanban im AgenturgeschäftScrum & Kanban im Agenturgeschäft
Scrum & Kanban im Agenturgeschäft
Paul Herwarth von Bittenfeld
 
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgShades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Stefan ROOCK
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
Tilman Moser
 
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
Renate Pinggera
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUM
TechDivision GmbH
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
Tilman Moser
 
Agiles Projektmanagement mit Scrum - Einführung
Agiles Projektmanagement mit Scrum - EinführungAgiles Projektmanagement mit Scrum - Einführung
Agiles Projektmanagement mit Scrum - Einführung
Atilla Wohllebe
 
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie ScrumScrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Ralf Ohlenbostel
 
Scrum Überblick Teil 2
Scrum Überblick Teil 2Scrum Überblick Teil 2
Scrum Überblick Teil 2
Christof Zahn
 
Technologiemanagement Agile Transformationen
Technologiemanagement Agile TransformationenTechnologiemanagement Agile Transformationen
Technologiemanagement Agile Transformationen
Björn Schotte
 
Agiles Projektmanagement mit Scrum
Agiles Projektmanagement mit ScrumAgiles Projektmanagement mit Scrum
Agiles Projektmanagement mit Scrum
Florian Latzel
 
Lean Project Management
Lean Project ManagementLean Project Management
Lean Project Management
Jürgen Rohr
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
Ulf Mewe
 
Prince2 - Wissen kompakt
Prince2 - Wissen kompaktPrince2 - Wissen kompakt
Prince2 - Wissen kompakt
Frank Dostert
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
Zeljko Kvesic
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
SwissQ Consulting AG
 

Was ist angesagt? (19)

Agile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus NotesAgile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus Notes
 
Scrum
ScrumScrum
Scrum
 
Scrum & Kanban im Agenturgeschäft
Scrum & Kanban im AgenturgeschäftScrum & Kanban im Agenturgeschäft
Scrum & Kanban im Agenturgeschäft
 
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgShades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
 
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Worksheets only, ditact Nov 2013 (German)
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUM
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
 
Agiles Projektmanagement mit Scrum - Einführung
Agiles Projektmanagement mit Scrum - EinführungAgiles Projektmanagement mit Scrum - Einführung
Agiles Projektmanagement mit Scrum - Einführung
 
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie ScrumScrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
 
Scrum Überblick Teil 2
Scrum Überblick Teil 2Scrum Überblick Teil 2
Scrum Überblick Teil 2
 
Technologiemanagement Agile Transformationen
Technologiemanagement Agile TransformationenTechnologiemanagement Agile Transformationen
Technologiemanagement Agile Transformationen
 
Einführung in SCRUM
Einführung in SCRUMEinführung in SCRUM
Einführung in SCRUM
 
Agiles Projektmanagement mit Scrum
Agiles Projektmanagement mit ScrumAgiles Projektmanagement mit Scrum
Agiles Projektmanagement mit Scrum
 
Lean Project Management
Lean Project ManagementLean Project Management
Lean Project Management
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
 
Prince2 - Wissen kompakt
Prince2 - Wissen kompaktPrince2 - Wissen kompakt
Prince2 - Wissen kompakt
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
 

Andere mochten auch

Role of the Product Owner in State Government Agility
Role of the Product Owner in State Government AgilityRole of the Product Owner in State Government Agility
Role of the Product Owner in State Government Agility
Joseph Flahiff
 
Scrum Product Owner
Scrum Product OwnerScrum Product Owner
Scrum Product Owner
Vishal Prasad
 
Become a Product Owner
Become a Product OwnerBecome a Product Owner
Become a Product Owner
Radek Matěj
 
UX and Scrum
UX and ScrumUX and Scrum
UX and Scrum
Roman Pichler
 
10 Tips for Creating Great User Stories
10 Tips for Creating Great User Stories10 Tips for Creating Great User Stories
10 Tips for Creating Great User Stories
Roman Pichler
 
Why SAP HANA?
Why SAP HANA?Why SAP HANA?
Why SAP HANA?
SAP Technology
 
Become a Great Product Manager
Become a Great Product ManagerBecome a Great Product Manager
Become a Great Product Manager
Roman Pichler
 
Product Strategy and Product Success
Product Strategy and Product SuccessProduct Strategy and Product Success
Product Strategy and Product Success
Roman Pichler
 
The Product Canvas Tutorial V1.0
The Product Canvas Tutorial V1.0The Product Canvas Tutorial V1.0
The Product Canvas Tutorial V1.0
Roman Pichler
 

Andere mochten auch (9)

Role of the Product Owner in State Government Agility
Role of the Product Owner in State Government AgilityRole of the Product Owner in State Government Agility
Role of the Product Owner in State Government Agility
 
Scrum Product Owner
Scrum Product OwnerScrum Product Owner
Scrum Product Owner
 
Become a Product Owner
Become a Product OwnerBecome a Product Owner
Become a Product Owner
 
UX and Scrum
UX and ScrumUX and Scrum
UX and Scrum
 
10 Tips for Creating Great User Stories
10 Tips for Creating Great User Stories10 Tips for Creating Great User Stories
10 Tips for Creating Great User Stories
 
Why SAP HANA?
Why SAP HANA?Why SAP HANA?
Why SAP HANA?
 
Become a Great Product Manager
Become a Great Product ManagerBecome a Great Product Manager
Become a Great Product Manager
 
Product Strategy and Product Success
Product Strategy and Product SuccessProduct Strategy and Product Success
Product Strategy and Product Success
 
The Product Canvas Tutorial V1.0
The Product Canvas Tutorial V1.0The Product Canvas Tutorial V1.0
The Product Canvas Tutorial V1.0
 

Ähnlich wie Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach

Scrum - Einführung - Begriffe - Technik
Scrum - Einführung - Begriffe - TechnikScrum - Einführung - Begriffe - Technik
Scrum - Einführung - Begriffe - Technik
Manuel Marsch
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Sascha Böhr
 
SCRUM für Projektleiter
SCRUM für ProjektleiterSCRUM für Projektleiter
SCRUM für Projektleiter
edutrainment company
 
Infogem vortrag pohle_v1
Infogem vortrag pohle_v1Infogem vortrag pohle_v1
Infogem vortrag pohle_v1
Matthias Pohle
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
Thomas Moedl
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
QAware GmbH
 
Projekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meisternProjekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meistern
INM AG
 
Praes critical chain-pm-tpeil-neutral
Praes critical chain-pm-tpeil-neutralPraes critical chain-pm-tpeil-neutral
Praes critical chain-pm-tpeil-neutral
Thorsten Speil
 
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten ProduktentwicklungAgile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Rainer Gibbert
 
Scrum Mythen
Scrum MythenScrum Mythen
Scrum Mythen
Holger Becker
 
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
marcus evans Network
 
Agilität mit Scrum - Überblick
Agilität mit Scrum - ÜberblickAgilität mit Scrum - Überblick
Agilität mit Scrum - Überblick
Claudia Haußmann 🦋
 
Scrum im Marketing
Scrum im MarketingScrum im Marketing
Scrum im Marketing
Björn Schotte
 
Das erste PI Planning der Group IT
Das erste PI Planning der Group ITDas erste PI Planning der Group IT
Das erste PI Planning der Group IT
Joël Krapf
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
HOOD Group
 
Requirement Engineering & PDD
Requirement Engineering & PDDRequirement Engineering & PDD
Requirement Engineering & PDD
Cristina Vidu
 
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
Stephan Schillerwein
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
Phillip Oertel
 
Lean development 04
Lean development 04Lean development 04
Lean development 04
SuperB2
 

Ähnlich wie Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach (20)

Scrum - Einführung - Begriffe - Technik
Scrum - Einführung - Begriffe - TechnikScrum - Einführung - Begriffe - Technik
Scrum - Einführung - Begriffe - Technik
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
 
SCRUM für Projektleiter
SCRUM für ProjektleiterSCRUM für Projektleiter
SCRUM für Projektleiter
 
Infogem vortrag pohle_v1
Infogem vortrag pohle_v1Infogem vortrag pohle_v1
Infogem vortrag pohle_v1
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Projekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meisternProjekte mittels Scrum und agiler Software Entwicklung meistern
Projekte mittels Scrum und agiler Software Entwicklung meistern
 
Praes critical chain-pm-tpeil-neutral
Praes critical chain-pm-tpeil-neutralPraes critical chain-pm-tpeil-neutral
Praes critical chain-pm-tpeil-neutral
 
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten ProduktentwicklungAgile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
Agile UX - Wege zur agilen nutzerzentrierten Produktentwicklung
 
Scrum Mythen
Scrum MythenScrum Mythen
Scrum Mythen
 
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
Die agile Organisation: Inhalt, Wege und Hürden aus Sicht eines CEO – der Fal...
 
Agiles bpm
Agiles bpmAgiles bpm
Agiles bpm
 
Agilität mit Scrum - Überblick
Agilität mit Scrum - ÜberblickAgilität mit Scrum - Überblick
Agilität mit Scrum - Überblick
 
Scrum im Marketing
Scrum im MarketingScrum im Marketing
Scrum im Marketing
 
Das erste PI Planning der Group IT
Das erste PI Planning der Group ITDas erste PI Planning der Group IT
Das erste PI Planning der Group IT
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Requirement Engineering & PDD
Requirement Engineering & PDDRequirement Engineering & PDD
Requirement Engineering & PDD
 
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
Vorschau zum Seminar "Strategisches Intranet-Projektmanagement" [DE]
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
 
Lean development 04
Lean development 04Lean development 04
Lean development 04
 

Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach

  • 1. Scrum-Breakfast Bern, 30.03.2011 Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach Ferdinand Hodel, IT Post Joscha Jenni, mimacom ag Peter Stucker, CSC Post Mail Informationstechnologie
  • 3. Projektsicht Autraggeber – Product Owner Sortierung PostMail Täglich 15 Millionen Briefe und Zeitungen, Zehntausende Briefbehälter, Hunderte Transporte 9 Briefzentren, 2 Retourenzentren 4‘600 Leute, 40 Sortiermaschinen, ca. 500 Handsortiergestelle ca. 300 unterschiedliche Sortierprogramme Sortierplanung ca. 600 Mutationen/Monat Simulationen für grössere Anpassungen Sortierung Komplexe Zusammenhänge
  • 4. Projektsicht IT – Scrum Master I IT1-Softwareentwicklung in Zahlen Personal: 173 Mitarbeitende, PE = 161.99 Softwareentwicklung: 4 Entwicklungsumgebungen (J2EE, .NET, SAP, Oracle) 2 ESB-Produkte (JCAPS von SUN & PI von SAP) >10 SAP ERP-Systeme Intranet: über 300 Applikationen pro Tag: ca. 3.2 Mio. Zugriffe, ca. 26 Mio. Seiten, ca. 1.3 Mio Besuche Projekte/Dienstleistungen: Weit über 100 Projekte pro Jahr > 33 Mio. CHF. Umsatz im Bereich Dienstleistungen 2009
  • 5. Projektsicht IT – Scrum Master II So ist IT1 aufgestellt Stand Januar 2011 IT1 Geschäftsanwendungen Urs Rudolf von Rohr Stv. Andreas Blasenbrei IT101 Postapplikationen Jean-Louis Fatton IT102 ERP Systeme Christos Mitos IT103 Produktivitätslösungen Andreas Blasenbrei IT11 Projektmanagement Norbert Zurwerra Stv. Martin Sägesser IT12 Java Roland Räuftlin Stv. Markus Günther IT13 Microsoft/.net Kurt Jost Stv. Stefan Haefeli IT14 Oracle/JCAPS Martin Rohrer Stv. Claudio Baldussi IT15 CCC SAP Reto Gentinetta Stv. Michel Frey IT16 Standort Bellinzona Roger Mossier Stv. Paolo Casella Chef Architektur Martin Schwab Stv. Reto Pestoni Sekretariat Nadja Günthör * Jacqueline Marti * Betreuung lernender Person
  • 6. Projektsicht IT – Scrum Master III IT-Post offerierte die Softwarelösung auf der Basis der Systemanforderungen mit 602 PT und einer Umsetzungszeit von rund 12 Monagen Dienstleistungen Aufwand PT Modul Persistenz 30 Modul Security/Visibility 16 Modul Traceability 2 Modul ReleaseMgmt 53 Modul Plandatenpflege 20 Modul ReleaseCalculation 48 Modul Änderungen zwischen zwei Release ermitteln 40 Modul ReleaseVerifikationDistribution 10 Modul Excel Import/Export 50 Modul Intf. Zstam -> SortPla 54 Modul Intf. SortPla -> Zstam (LPM/SPM) 26 Modul BO Reports 56 Modul Dokumentation 32 Architektur 18 Deploy 15 Einführung 22 Projektmanagement 66 Reserve 44 Total Aufwand in PT 602
  • 7. Ausgangslage und Einstieg Sicht Product Owner I Darf ich das? IT Post „Wir wollten schon lange ein Projekt nach Scrum abwickeln“. Wie weit soll ich als PO Einfluss nehmen, um „Scrum-But“ zu verhindern? Wie weit soll ich die Management Awareness über die Methode treiben? Das Vorhaben (und der Hauptknowhowträger…) hat einen explorativen Charakter. Eine Lösung ist dringend notwendig.
  • 8. Ausgangslage und Einstieg Sicht Product Owner II Rollen und Verantwortlichkeiten, inkl. QS Die meisten Entwickler sind nur 50-60% Ressourcen.  relativer Aufwand für Scrum „Meetings“ ist hoch  sichtbarer Fortschritt pro Sprint (3 bzw. 4 Wochen) eher gering Spezialisierung war wichtig, auch wenn wir als Team agieren (Lösungsarchitekt, SW-Architekt, GUI Verantwortlicher, DB-Verantwortlicher. u.a.). Für das agile Vorgehen ist eine entwicklungsnahe QS von Vorteil (mit technischen Skills im Bereich DB-Abfragen und idealerweise sogar Programmierskills für automatisierte Tests).
  • 9. Ausgangslage und Einstieg Sicht Scrum Master I Scrum Einführung /Schulung Zu Beginn wurde eine Scrum-Ausbildung mit dem Kernteam durchgeführt, jedoch veränderte sich die Besetzung im Team aufgrund der knappen Ressourcen nachhaltig. Die neuen Teammitglieder konnten nicht genügend geschult werden. Funktionsweise der Methode Scrum wurde zum Teil missverstanden oder nicht einheitlich interpretiert. Einführung Jira als Tool für agile Projekte erfolgte on-the-job.
  • 10. Ausgangslage und Einstieg Sicht Scrum Master II Rollen und Verantwortlichkeiten, inkl. QS Die Kernteammitglieder mussten sich in ihrer Rolle finden. Der Product-Backlog Owner nimmt mehrere Rollen ein: - Auftraggeber Stellvertreter - Gesamtprojekt-Leiter - Scrumteam Mitglied QS sehr weit weg vom Geschehen Der Scrum-Master konnte die erforderliche Zeit in den ersten Sprints bei weitem nicht aufbringen. Die Verantwortung des Scrum-Teams wurde teilweise massiv unterschätzt.
  • 11. Ausgangslage und Einstieg Sicht Scrum Berater I Einführung, Schulung, Know-How Transfer Frühe Schulungen des Teams zahlen sich aus Neue Team Mitglieder wie in der Einführung schulen
  • 12. Ausgangslage und Einstieg Sicht Scrum Berater II Rollen und Verantwortlichkeiten, inkl. QS Stakeholder waren klar Product Owner und Scrum Master definiert Scrum Team Rollen haben sich im Scrum Team entwickelt QS konnte leider nie richtig integriert werden Scrum Master zu Beginn Scrum-Know-How Träger oder nicht?
  • 13. Ausgangslage und Einstieg Key Points QS ist intensiv ins Scrum-Team zu integrieren (erfordert ev. ein Überdenken des Rollenverständnis und der Arbeitsweise von QS). Bei der Einführung von neuen Methoden sind entsprechend die Ressourcen einzuplanen (Ausbildung und die ersten Sprints). Spezialisierte Rollen helfen dem Projekterfolg.
  • 14. Scrum-Prinzipien Sicht Product Owner I Sprintzielvereinbarungen Die detaillierten Spezifikationen aus den Anforderungen werden mit einem kleinen zeitlichen Vorlauf auf die Entwicklung erarbeitet.  z.T. Verlagerung Termindruck von IT zu Fach „ Ziele unterhalb des Radars“: Infrastruktur, Datenlogik, u.v.a. Achtung: QS betrachtet eventuell nur GUI‘s als „potentiell lieferbare und einsetzbare Software“ Über die Sprintziele kann das Team an die Vision des PO herangeführt werden. Koordination der Einzeltasks ist auch bei Scrum zwingend notwendig, um die Ziele zu erreichen. Persönliche Verantwortung jedes einzelnen ist ein (zu) hehres Ziel.
  • 15. Scrum-Prinzipien Sicht Product Owner II „ Fail fast, Learn fast“  weniger Stress für alle Ressourcen- und Knowhow-Engpässe früh adressierbar. Viele kleine Fehler statt wenige grosse Fehler. Deployment Prozess wird eingespielt. Transparenz bei Erfolg und Misserfolg Die erreichte Transparenz ist für den PO enorm wichtig und für den Projekterfolg massgeblich verantwortlich. „ Misserfolg“? „Planungsfehler“? „Niederlage“? Nicht erreichte Ziele sind schwer als Chance kommunizierbar.
  • 16. Scrum-Prinzipien in der Einschätzung der Beteiligten: Sicht Product Owner III Einschätzung: das agile Vorgehen hat einen stark positiven Einfluss auf die Qualität der Lösung. Positive Einschätzung ist mit zunehmender Erfahrung deutlich gestiegen.
  • 17. Scrum-Prinzipien Sicht Scrum Master I Sprintzielvereinbarungen und Transparenz bei Erfolg und Misserfolg Absolute Transparenz gegenüber dem Projektauftraggeber. Offensichtliche Schwächen bezüglich der Stabilität in der Entwicklungsumgebung und bezüglich dem Ausbildungsstand der Entwickler. Das Nichterreichen von Sprintzielen wird zu jedem Sprintende unmissverständlich aufgezeigt. Beim Nichterreichen der Sprintziele entsteht der Eindruck, dass für die jeweilige Situation einzig und allein die IT verantwortlich ist.
  • 18. Impressionen I - Burn Down Chart
  • 19. Impression II - Stimmungsbarometer
  • 20. Scrum-Prinzipien Sicht Scrum Master II Definition of Done, Sprint- und Task-Readiness Im Projektkern- und im Scrumteam tat man sich schwer, die Definition of Done zu finden. Die QS war bei der Defintion of Done nicht beteiligt. Bezüglich den Anforderungspapiere wurde keine Definiton of Done formuliert, dies weder bei der Erstellung noch bei der Veränderung dieser. Welcher Prozess läuft ab, wenn ein Module im Status “done“ infolge Fehler von der Entwicklung nochmals bearbeitet werden muss.
  • 21. Scrum-Prinzipien Sicht Scrum Master III Eigenverantwortung Die Scrum-Philosophie basiert auf einer hohen Selbstverantwortung vom Scrum-Team, resp. von jedem einzelnen Entwickler. Inwiefern wird die Verantwortung vom Management entsprechend delegiert? Inwiefern ist sich der Entwickler dessen bewusst?
  • 22. Scrum-Prinzipien Sicht Scrum Master IV Timeboxing Eines der wichtigsten Scrum-Prinzipien überhaupt. Konnte fast nie eingehalten werden, beginnend mit den Ausführungen des Produkt Owners zu Beginn der Sprintplanung, bis hin zu den Abnahmetests. Timeboxing bedeutet, genügend kleine Pakete zu definieren, welche in der geplanten Zeiten bearbeitet werden können. Hängt sehr eng mit den Sprintzielen zusammen.
  • 23. Scrum-Prinzipien Sicht Scrum Berater I Sprintzielvereinbarungen Endlich ein Product Owner der Ziele formuliert! Transparenz bei Erfolg und Misserfolg Ziele wurden leider vom Team am Anfang zu wenig hinterfragt und/oder waren zu wenig SMART definiert… … was zu Frustration beim Review-Meeting führte
  • 24. Scrum-Prinzipien Sicht Scrum Berater II Definition of Done Definition of Done war in einem Dokument… zu wenig transparent und zu wenig in den Köpfen Sprint- und Task-Readiness Product Owner muss mal spezifizieren, sonst… Sprintlänge?
  • 25. Scrum-Prinzipien Sicht Scrum Berater III Eigenverantwortung Von Person zu Person unterschiedlich, jedoch durchwegs positiv! Starke Persönlichkeiten/Leaders haben Verantwortung getragen Timeboxing … time over… War schwierig durchzusetzen
  • 26. Scrum-Prinzipien Key Points Timeboxing situativ anwenden Fortwährende Feedbackloops erzwingen die Entdeckung und die Beseitigung von Hindernissen auf dem Weg zum Projekterfolg. Die resultierende Transparenz dient dem Auftraggeber und –nehmer.
  • 27. Rahmenbedingungen Sicht Product Owner I Vertragsform Auftraggeber und –nehmer im gleichen Konzern Werk mit Fixpreis Change Managment Change Diskussion „wie klassisch“ Auf Durchgängigkeit von Pflichtenheft  Angebot  Tasks achten.  Schätzung und erbrachter Aufwand vergleichen Transparenz durch Scrum nützt Auftraggeber  Gegenleistung: Auftraggeber honoriert nachvollziehbare Mehraufwände konziliant
  • 28. Rahmenbedingungen Sicht Scrum Master I Vertragsform Fixpreis vs Design to Cost Vertrauen, resp. nicht das Gefühl zu haben, über den Tisch gezogen zu werden Konfliktkultur zwisschen Auftraggeber und –nehmer Auftraggeber und –nehmer im gleichen Konzern IT-Post als NonProfitOrganisation ?!
  • 29. Rahmenbedingungen Sicht Scrum Master II Infrastruktur (Jira, das Tool) Das Projekt wurde in Jira zu kompliziert und zu aufwendig angelegt Jira besitzt keine Schnittstelle zum Faktuierungssystem von IT-Post und somit müssen aufwände doppelt rapportiert werden Zeitliche Abhängigkeiten können in Jira nicht dargestellt werden Jira ist in der Handhabung nicht einfach und als Web-Applikation träge Jira ist in einer reduzierten Form den Projekten möglichst einheiltich zur Verfügung zu stellen
  • 30. Rahmenbedingungen Sicht Scrum Berater I Tooling Ziele definieren! Mehr Training, bessere Dokumentation Vertragsform Fakt Linke rechte Hosentasche - Politikum Konflikt: Vertrag mit IT oder? PO vs. SM…
  • 31. Rahmenbedingungen Sicht Scrum Berater II Infrastruktur Entwicklungsumgebung und Aufbau Plattformen Zu spät ready… organisatorische und betriebliche Schnittstelle, resp. Abhängigkeit Essentiell für agile Entwicklung
  • 32. Rahmenbedingungen Key Points Auch bei den Infrastrukturverantwortlichen und dem Change Management muss das Verständnis für das agile Vorgehen gefördert werden. Auch hier gilt: Agilität bedeutet nicht Chaos Agiles Vorgehen lässt sich mit Fix-Preis Werkverträgen vereinbaren. Ein Planungs- und Trackingtool ist zur Unterstützung des agilen Vorgehens zwingend erforderlich.
  • 34. Impression III - Stimmungsbarometer So macht es definitiv mehr Spass!

Hinweis der Redaktion

  1. Management Attention Clinch Team („Scrum-But“) - QS („Lehrbuch“)
  2. B) Faktisch stehen nur ca. 2.9 FTE für die Entwicklung zur Verfügung. Dadurch ist der sichtbare Fortschritt pro Sprint (3 bzw. 4 Wochen) eher gering. Dies erklärt z.T. die Befindlichkeit der Qualitätsverantwortlichen, siehe Kommentare von I.Ryter oben.
  3. Wir wären mit einem klassischen Vorgehen (HERMES SE, sogar mit RUP) mit Sicherheit noch nicht so weit. Auch qualitativ wären etliche Fehler erst später entdeckt worden und hätten mit mehr Aufwand gefixt werden müssen.
  4. Ich würde in einem SW-Entwicklungsprojekt jederzeit wieder mit SCRUM arbeiten. Es macht mir Freude, nahe am Entwicklungsteam zu arbeiten und Fortschritte aber auch Rückschläge direkt zu erleben. Der intensive Austausch von Fachspezialisten und Auftraggebervertreter mit dem SCRUM Team führt dazu, dass Probleme, Missverständnisse und unklare Anforderungen früher erkannt und aus dem Weg geräumt werden können. Qualität: Hier bin ich ganz sicher, bin auch überzeugt, dass wir diverse Fehlentwicklungen gemacht hätten. Ohne Agiles Vorgehen (Scrum oder etwas anderes) wäre es hoffnungslos gewesen den heute erreichten Stand zu erreichen. Der grosse Einsatz aller Beteiligten konnte optimal genutzt werden, weil Scrum als Methode grosse Blindleistungen systematisch zu verhindern versucht. Die zeitnahe Steuerung, sowohl durch dauernden Kontakt, als auch über das Werkzeug JIRA, ist einer der Erfolgsfaktoren gewesen.