Scrum-Breakfast Bern, 30.03.2011 Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum...
Aufbau und Agenda
Projektsicht Autraggeber – Product Owner <ul><li>Sortierung PostMail </li></ul><ul><li>Täglich 15 Millionen Briefe und Zei...
Projektsicht IT – Scrum Master I <ul><li>IT1-Softwareentwicklung in Zahlen </li></ul><ul><li>Personal: </li></ul><ul><li>1...
Projektsicht IT – Scrum Master II <ul><li>So ist IT1 aufgestellt </li></ul>Stand Januar 2011 IT1 Geschäftsanwendungen Urs ...
Projektsicht IT – Scrum Master III <ul><li>IT-Post offerierte die Softwarelösung auf der Basis der Systemanforderungen mit...
Ausgangslage und Einstieg Sicht Product Owner I Darf ich das? <ul><ul><li>IT Post „Wir wollten schon lange ein Projekt nac...
Ausgangslage und Einstieg Sicht Product Owner II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><ul><li>D...
Ausgangslage und Einstieg Sicht Scrum Master I <ul><li>Scrum Einführung /Schulung </li></ul><ul><li>Zu Beginn wurde eine S...
Ausgangslage und Einstieg Sicht Scrum Master II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><li>Die Ke...
Ausgangslage und Einstieg Sicht Scrum Berater I <ul><li>Einführung, Schulung, Know-How Transfer </li></ul><ul><li>Frühe Sc...
Ausgangslage und Einstieg Sicht Scrum Berater II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><li>Stake...
Ausgangslage und Einstieg Key Points <ul><li>QS ist intensiv ins Scrum-Team zu integrieren (erfordert ev. ein Überdenken d...
Scrum-Prinzipien Sicht Product Owner I <ul><li>Sprintzielvereinbarungen </li></ul><ul><ul><li>Die detaillierten Spezifikat...
Scrum-Prinzipien Sicht Product Owner II <ul><li>„ Fail fast, Learn fast“    weniger Stress für alle </li></ul><ul><ul><li...
Scrum-Prinzipien in der Einschätzung der Beteiligten: Sicht Product Owner III <ul><li>Einschätzung: das agile Vorgehen hat...
Scrum-Prinzipien Sicht Scrum Master I <ul><li>Sprintzielvereinbarungen und  Transparenz bei Erfolg und Misserfolg </li></u...
Impressionen  I  -  Burn Down Chart
Impression II  -  Stimmungsbarometer
Scrum-Prinzipien Sicht Scrum Master II <ul><li>Definition of Done, Sprint- und Task-Readiness </li></ul><ul><li>Im Projekt...
Scrum-Prinzipien Sicht Scrum Master III <ul><li>Eigenverantwortung  </li></ul><ul><li>Die Scrum-Philosophie basiert auf ei...
Scrum-Prinzipien Sicht Scrum Master IV <ul><li>Timeboxing </li></ul><ul><li>Eines der wichtigsten Scrum-Prinzipien überhau...
Scrum-Prinzipien Sicht Scrum Berater I <ul><li>Sprintzielvereinbarungen </li></ul><ul><li>Endlich ein Product Owner der Zi...
Scrum-Prinzipien Sicht Scrum Berater II <ul><li>Definition of Done </li></ul><ul><li>Definition of Done war in einem Dokum...
Scrum-Prinzipien  Sicht Scrum Berater III <ul><li>Eigenverantwortung </li></ul><ul><li>Von Person zu Person unterschiedlic...
Scrum-Prinzipien Key Points <ul><li>Timeboxing situativ anwenden </li></ul><ul><li>Fortwährende Feedbackloops erzwingen di...
Rahmenbedingungen Sicht Product Owner I <ul><li>Vertragsform </li></ul><ul><ul><li>Auftraggeber und –nehmer im gleichen Ko...
Rahmenbedingungen Sicht Scrum Master I <ul><li>Vertragsform  </li></ul><ul><li>Fixpreis vs Design to Cost </li></ul><ul><l...
Rahmenbedingungen Sicht Scrum Master II <ul><li>Infrastruktur (Jira, das Tool) </li></ul><ul><li>Das Projekt wurde in Jira...
Rahmenbedingungen Sicht Scrum Berater I <ul><li>Tooling </li></ul><ul><li>Ziele definieren! </li></ul><ul><li>Mehr Trainin...
Rahmenbedingungen Sicht Scrum Berater II <ul><li>Infrastruktur </li></ul><ul><li>Entwicklungsumgebung und Aufbau Plattform...
Rahmenbedingungen Key Points <ul><li>Auch bei den Infrastrukturverantwortlichen und dem  Change Management muss das Verstä...
Bilanz
Impression III  -  Stimmungsbarometer So macht es definitiv mehr Spass!
Nächste SlideShare
Wird geladen in …5
×

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

3.177 Aufrufe

Veröffentlicht am

Veröffentlicht in: Business, Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.177
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Management Attention Clinch Team („Scrum-But“) - QS („Lehrbuch“)
  • 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.
  • 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.
  • 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.
  • Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach

    1. 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
    2. 2. Aufbau und Agenda
    3. 3. Projektsicht Autraggeber – Product Owner <ul><li>Sortierung PostMail </li></ul><ul><li>Täglich 15 Millionen Briefe und Zeitungen, Zehntausende Briefbehälter, Hunderte Transporte </li></ul><ul><li>9 Briefzentren, 2 Retourenzentren </li></ul><ul><li>4‘600 Leute, 40 Sortiermaschinen, ca. 500 Handsortiergestelle </li></ul><ul><li>ca. 300 unterschiedliche Sortierprogramme </li></ul><ul><li>Sortierplanung </li></ul><ul><li>ca. 600 Mutationen/Monat </li></ul><ul><li>Simulationen für grössere Anpassungen Sortierung </li></ul><ul><li>Komplexe Zusammenhänge </li></ul>
    4. 4. Projektsicht IT – Scrum Master I <ul><li>IT1-Softwareentwicklung in Zahlen </li></ul><ul><li>Personal: </li></ul><ul><li>173 Mitarbeitende, PE = 161.99 </li></ul><ul><li>Softwareentwicklung: </li></ul><ul><ul><ul><li>4 Entwicklungsumgebungen (J2EE, .NET, SAP, Oracle) </li></ul></ul></ul><ul><ul><ul><li>2 ESB-Produkte (JCAPS von SUN & PI von SAP) </li></ul></ul></ul><ul><ul><ul><li>>10 SAP ERP-Systeme </li></ul></ul></ul><ul><li>Intranet: </li></ul><ul><ul><ul><li>über 300 Applikationen </li></ul></ul></ul><ul><ul><ul><li>pro Tag: ca. 3.2 Mio. Zugriffe, ca. 26 Mio. Seiten, ca. 1.3 Mio Besuche </li></ul></ul></ul><ul><li>Projekte/Dienstleistungen: </li></ul><ul><ul><ul><li>Weit über 100 Projekte pro Jahr </li></ul></ul></ul><ul><ul><ul><li>> 33 Mio. CHF. Umsatz im Bereich Dienstleistungen 2009 </li></ul></ul></ul>
    5. 5. Projektsicht IT – Scrum Master II <ul><li>So ist IT1 aufgestellt </li></ul>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. 6. Projektsicht IT – Scrum Master III <ul><li>IT-Post offerierte die Softwarelösung auf der Basis der Systemanforderungen mit 602 PT und einer Umsetzungszeit von rund 12 Monagen </li></ul>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. 7. Ausgangslage und Einstieg Sicht Product Owner I Darf ich das? <ul><ul><li>IT Post „Wir wollten schon lange ein Projekt nach Scrum abwickeln“. </li></ul></ul><ul><ul><li>Wie weit soll ich als PO Einfluss nehmen, um „Scrum-But“ zu verhindern? </li></ul></ul><ul><ul><li>Wie weit soll ich die Management Awareness über die Methode treiben? </li></ul></ul><ul><ul><li>Das Vorhaben (und der Hauptknowhowträger…) hat einen explorativen Charakter. </li></ul></ul><ul><ul><li>Eine Lösung ist dringend notwendig. </li></ul></ul>
    8. 8. Ausgangslage und Einstieg Sicht Product Owner II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Spezialisierung war wichtig, auch wenn wir als Team agieren (Lösungsarchitekt, SW-Architekt, GUI Verantwortlicher, DB-Verantwortlicher. u.a.). </li></ul></ul><ul><ul><li>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). </li></ul></ul>
    9. 9. Ausgangslage und Einstieg Sicht Scrum Master I <ul><li>Scrum Einführung /Schulung </li></ul><ul><li>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. </li></ul><ul><li>Funktionsweise der Methode Scrum wurde zum Teil missverstanden oder nicht einheitlich interpretiert. </li></ul><ul><li>Einführung Jira als Tool für agile Projekte erfolgte on-the-job. </li></ul>
    10. 10. Ausgangslage und Einstieg Sicht Scrum Master II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><li>Die Kernteammitglieder mussten sich in ihrer Rolle finden. </li></ul><ul><li>Der Product-Backlog Owner nimmt mehrere Rollen ein: - Auftraggeber Stellvertreter - Gesamtprojekt-Leiter - Scrumteam Mitglied </li></ul><ul><li>QS sehr weit weg vom Geschehen </li></ul><ul><li>Der Scrum-Master konnte die erforderliche Zeit in den ersten Sprints bei weitem nicht aufbringen. </li></ul><ul><li>Die Verantwortung des Scrum-Teams wurde teilweise massiv unterschätzt. </li></ul>
    11. 11. Ausgangslage und Einstieg Sicht Scrum Berater I <ul><li>Einführung, Schulung, Know-How Transfer </li></ul><ul><li>Frühe Schulungen des Teams zahlen sich aus </li></ul><ul><li>Neue Team Mitglieder wie in der Einführung schulen </li></ul>
    12. 12. Ausgangslage und Einstieg Sicht Scrum Berater II <ul><li>Rollen und Verantwortlichkeiten, inkl. QS </li></ul><ul><li>Stakeholder waren klar </li></ul><ul><li>Product Owner und Scrum Master definiert </li></ul><ul><li>Scrum Team </li></ul><ul><ul><li>Rollen haben sich im Scrum Team entwickelt </li></ul></ul><ul><ul><li>QS konnte leider nie richtig integriert werden </li></ul></ul><ul><li>Scrum Master zu Beginn Scrum-Know-How Träger oder nicht? </li></ul>
    13. 13. Ausgangslage und Einstieg Key Points <ul><li>QS ist intensiv ins Scrum-Team zu integrieren (erfordert ev. ein Überdenken des Rollenverständnis und der Arbeitsweise von QS). </li></ul><ul><li>Bei der Einführung von neuen Methoden sind entsprechend die Ressourcen einzuplanen (Ausbildung und die ersten Sprints). </li></ul><ul><li>Spezialisierte Rollen helfen dem Projekterfolg. </li></ul>
    14. 14. Scrum-Prinzipien Sicht Product Owner I <ul><li>Sprintzielvereinbarungen </li></ul><ul><ul><li>Die detaillierten Spezifikationen aus den Anforderungen werden mit einem kleinen zeitlichen Vorlauf auf die Entwicklung erarbeitet.  z.T. Verlagerung Termindruck von IT zu Fach </li></ul></ul><ul><ul><li>„ Ziele unterhalb des Radars“: Infrastruktur, Datenlogik, u.v.a. Achtung: QS betrachtet eventuell nur GUI‘s als „potentiell lieferbare und einsetzbare Software“ </li></ul></ul><ul><ul><li>Über die Sprintziele kann das Team an die Vision des PO herangeführt werden. </li></ul></ul><ul><ul><li>Koordination der Einzeltasks ist auch bei Scrum zwingend notwendig, um die Ziele zu erreichen. Persönliche Verantwortung jedes einzelnen ist ein (zu) hehres Ziel. </li></ul></ul>
    15. 15. Scrum-Prinzipien Sicht Product Owner II <ul><li>„ Fail fast, Learn fast“  weniger Stress für alle </li></ul><ul><ul><li>Ressourcen- und Knowhow-Engpässe früh adressierbar. </li></ul></ul><ul><ul><li>Viele kleine Fehler statt wenige grosse Fehler. </li></ul></ul><ul><ul><li>Deployment Prozess wird eingespielt. </li></ul></ul><ul><li>Transparenz bei Erfolg und Misserfolg </li></ul><ul><ul><li>Die erreichte Transparenz ist für den PO enorm wichtig und für den Projekterfolg massgeblich verantwortlich. </li></ul></ul><ul><ul><li>„ Misserfolg“? „Planungsfehler“? „Niederlage“? Nicht erreichte Ziele sind schwer als Chance kommunizierbar. </li></ul></ul>
    16. 16. Scrum-Prinzipien in der Einschätzung der Beteiligten: Sicht Product Owner III <ul><li>Einschätzung: das agile Vorgehen hat einen stark positiven Einfluss auf die Qualität der Lösung. </li></ul><ul><li>Positive Einschätzung ist mit zunehmender Erfahrung deutlich gestiegen. </li></ul>
    17. 17. Scrum-Prinzipien Sicht Scrum Master I <ul><li>Sprintzielvereinbarungen und Transparenz bei Erfolg und Misserfolg </li></ul><ul><li>Absolute Transparenz gegenüber dem Projektauftraggeber. </li></ul><ul><li>Offensichtliche Schwächen bezüglich der Stabilität in der Entwicklungsumgebung und bezüglich dem Ausbildungsstand der Entwickler. </li></ul><ul><li>Das Nichterreichen von Sprintzielen wird zu jedem Sprintende unmissverständlich aufgezeigt. </li></ul><ul><li>Beim Nichterreichen der Sprintziele entsteht der Eindruck, dass für die jeweilige Situation einzig und allein die IT verantwortlich ist. </li></ul>
    18. 18. Impressionen I - Burn Down Chart
    19. 19. Impression II - Stimmungsbarometer
    20. 20. Scrum-Prinzipien Sicht Scrum Master II <ul><li>Definition of Done, Sprint- und Task-Readiness </li></ul><ul><li>Im Projektkern- und im Scrumteam tat man sich schwer, die Definition of Done zu finden. </li></ul><ul><li>Die QS war bei der Defintion of Done nicht beteiligt. </li></ul><ul><li>Bezüglich den Anforderungspapiere wurde keine Definiton of Done formuliert, dies weder bei der Erstellung noch bei der Veränderung dieser. </li></ul><ul><li>Welcher Prozess läuft ab, wenn ein Module im Status “done“ infolge Fehler von der Entwicklung nochmals bearbeitet werden muss. </li></ul>
    21. 21. Scrum-Prinzipien Sicht Scrum Master III <ul><li>Eigenverantwortung </li></ul><ul><li>Die Scrum-Philosophie basiert auf einer hohen Selbstverantwortung vom Scrum-Team, resp. von jedem einzelnen Entwickler. </li></ul><ul><li>Inwiefern wird die Verantwortung vom Management entsprechend delegiert? </li></ul><ul><li>Inwiefern ist sich der Entwickler dessen bewusst? </li></ul>
    22. 22. Scrum-Prinzipien Sicht Scrum Master IV <ul><li>Timeboxing </li></ul><ul><li>Eines der wichtigsten Scrum-Prinzipien überhaupt. </li></ul><ul><li>Konnte fast nie eingehalten werden, beginnend mit den Ausführungen des Produkt Owners zu Beginn der Sprintplanung, bis hin zu den Abnahmetests. </li></ul><ul><li>Timeboxing bedeutet, genügend kleine Pakete zu definieren, welche in der geplanten Zeiten bearbeitet werden können. </li></ul><ul><li>Hängt sehr eng mit den Sprintzielen zusammen. </li></ul>
    23. 23. Scrum-Prinzipien Sicht Scrum Berater I <ul><li>Sprintzielvereinbarungen </li></ul><ul><li>Endlich ein Product Owner der Ziele formuliert! </li></ul><ul><li>Transparenz bei Erfolg und Misserfolg </li></ul><ul><li>Ziele wurden leider vom Team am Anfang zu wenig hinterfragt und/oder waren zu wenig SMART definiert… </li></ul><ul><li>… was zu Frustration beim Review-Meeting führte </li></ul>
    24. 24. Scrum-Prinzipien Sicht Scrum Berater II <ul><li>Definition of Done </li></ul><ul><li>Definition of Done war in einem Dokument… zu wenig transparent und zu wenig in den Köpfen </li></ul><ul><li>Sprint- und Task-Readiness </li></ul><ul><li>Product Owner muss mal spezifizieren, sonst… </li></ul><ul><li>Sprintlänge? </li></ul>
    25. 25. Scrum-Prinzipien Sicht Scrum Berater III <ul><li>Eigenverantwortung </li></ul><ul><li>Von Person zu Person unterschiedlich, jedoch durchwegs positiv! </li></ul><ul><li>Starke Persönlichkeiten/Leaders haben Verantwortung getragen </li></ul><ul><li>Timeboxing </li></ul><ul><li>… time over… </li></ul><ul><li>War schwierig durchzusetzen </li></ul>
    26. 26. Scrum-Prinzipien Key Points <ul><li>Timeboxing situativ anwenden </li></ul><ul><li>Fortwährende Feedbackloops erzwingen die Entdeckung und die Beseitigung von Hindernissen auf dem Weg zum Projekterfolg. </li></ul><ul><li>Die resultierende Transparenz dient dem Auftraggeber und –nehmer. </li></ul>
    27. 27. Rahmenbedingungen Sicht Product Owner I <ul><li>Vertragsform </li></ul><ul><ul><li>Auftraggeber und –nehmer im gleichen Konzern </li></ul></ul><ul><ul><li>Werk mit Fixpreis </li></ul></ul><ul><li>Change Managment </li></ul><ul><ul><li>Change Diskussion „wie klassisch“ </li></ul></ul><ul><ul><li>Auf Durchgängigkeit von Pflichtenheft  Angebot  Tasks achten.  Schätzung und erbrachter Aufwand vergleichen </li></ul></ul><ul><ul><li>Transparenz durch Scrum nützt Auftraggeber  Gegenleistung: Auftraggeber honoriert nachvollziehbare Mehraufwände konziliant </li></ul></ul>
    28. 28. Rahmenbedingungen Sicht Scrum Master I <ul><li>Vertragsform </li></ul><ul><li>Fixpreis vs Design to Cost </li></ul><ul><li>Vertrauen, resp. nicht das Gefühl zu haben, über den Tisch gezogen zu werden </li></ul><ul><li>Konfliktkultur zwisschen Auftraggeber und –nehmer </li></ul><ul><li>Auftraggeber und –nehmer im gleichen Konzern </li></ul><ul><li>IT-Post als NonProfitOrganisation ?! </li></ul>
    29. 29. Rahmenbedingungen Sicht Scrum Master II <ul><li>Infrastruktur (Jira, das Tool) </li></ul><ul><li>Das Projekt wurde in Jira zu kompliziert und zu aufwendig angelegt </li></ul><ul><li>Jira besitzt keine Schnittstelle zum Faktuierungssystem von IT-Post und somit müssen aufwände doppelt rapportiert werden </li></ul><ul><li>Zeitliche Abhängigkeiten können in Jira nicht dargestellt werden </li></ul><ul><li>Jira ist in der Handhabung nicht einfach und als Web-Applikation träge </li></ul><ul><li>Jira ist in einer reduzierten Form den Projekten möglichst einheiltich zur Verfügung zu stellen </li></ul>
    30. 30. Rahmenbedingungen Sicht Scrum Berater I <ul><li>Tooling </li></ul><ul><li>Ziele definieren! </li></ul><ul><li>Mehr Training, bessere Dokumentation </li></ul><ul><li>Vertragsform </li></ul><ul><li>Fakt </li></ul><ul><li>Linke rechte Hosentasche - Politikum </li></ul><ul><li>Konflikt: Vertrag mit IT oder? PO vs. SM… </li></ul>
    31. 31. Rahmenbedingungen Sicht Scrum Berater II <ul><li>Infrastruktur </li></ul><ul><li>Entwicklungsumgebung und Aufbau Plattformen </li></ul><ul><li>Zu spät ready… organisatorische und betriebliche Schnittstelle, resp. Abhängigkeit </li></ul><ul><li>Essentiell für agile Entwicklung </li></ul>
    32. 32. Rahmenbedingungen Key Points <ul><li>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 </li></ul><ul><li>Agiles Vorgehen lässt sich mit Fix-Preis Werkverträgen vereinbaren. </li></ul><ul><li>Ein Planungs- und Trackingtool ist zur Unterstützung des agilen Vorgehens zwingend erforderlich. </li></ul>
    33. 33. Bilanz
    34. 34. Impression III - Stimmungsbarometer So macht es definitiv mehr Spass!

    ×