Good Practices beim Start mit Scrum

492 Aufrufe

Veröffentlicht am

Die Aufzeichnung des Webinars zum Handout finden Sie hier http://hubs.ly/H012Vdz0

Schnelligkeit, Effizienzsteigerung, höhere Produktivität, bessere Zusammenarbeit und qualitativ hochwertige Ergebnisse sind die Anforderungen an moderne Software-Entwicklung. Teams können dies mit Scrum erreichen. Wenn Sie die Einführung von Scrum auf der Agenda haben, sollten Sie dieses Webinar nicht verpassen. Wollten auch Sie schon immer mal Scrum ausprobieren, wussten nur nie so genau, was es bei der Einführung der Methode zu beachten gilt?

Lt. Jeff Sutherland, dem Co-Erfinder von Scrum, sind von den vermeintlich agilen Firmen im Silicon Valley tatsächlich nur 40 % wirklich agil. Erfahren Sie, worauf Sie bei der Implementierung von Scrum achten müssen, welche Fallstricke Sie vermeiden sollten und wie Sie von Erfahrungen profitieren können.

Agenda

- Was Sie bei einer Scrum-Einführung beachten sollten
- Wie Sie erkennen, ob Scrum für Ihr Projekt geeignet ist
- Warum Custom-Scrum und Scrum nicht dasselbe ist
- Wie Sie Ihr Management für sich gewinnen
- Good Practices: Methoden und Instrumente

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

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
492
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Good Practices beim Start mit Scrum

  1. 1. HLSC GmbH Dornhalde 1 70597 Stuttgart Telefon: +49 711 720 717 9-0 www.scrum-events.de Vertretungsberechtigter Geschäftsführerin: Monika Berchez Registergericht: Amtsgericht Stuttgart, Registernummer HRB 734265 USt-IdNr. DE272417106 Polarion Webinar Agiles Projekt a age e t­ Good Pra ti es ei Start it S ru Version vom 04.08.2015 Schnelligkeit, Effizienzsteigerung, höhere Produktivität, bessere Zusammenarbeit und qualitativ hochwertige Ergebnisse sind die Anforderungen an moderne Software- Entwicklung. Teams können dies mit Scrum erreichen. Wenn Sie die Einführung von Scrum auf der Agenda haben, sollten Sie dieses Webinar nicht verpassen. Wollten auch Sie schon immer mal Scrum ausprobieren, wussten nur nie so genau, was es bei der Einführung der Methode zu beachten gilt? Lt. Jeff Sutherland, dem Co-Erfinder von Scrum, sind von den vermeintlich agilen Firmen im Silicon Valley tatsächlich nur 40 % wirklich agil. Erfahren Sie, worauf Sie bei der Implementierung von Scrum achten müssen, welche Fallstricke Sie vermeiden sollten und wie Sie von Erfahrungen profitieren können. Erfahren Sie mehr darüber, was Sie bei einer Scrum-Einführung beachten sollten, wie Sie erkennen, ob Scrum für Ihr Projekt geeignet ist, warum Custom-Scrum und Scrum nicht dasselbe sind und wie Sie Ihr Management für sich gewinnen.
  2. 2. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 2/15 1 Am Anfang gibt es immer Widerstand gegen Scrum Bei jeder Umstellung der Arbeitsweisen gibt es Widerstände. Wahrscheinlich kennen Sie selbst dazu genug Geschichten aus Ihren eigenen Unternehmen. Scrum wird zurzeit sehr über den grünen Klee gelobt und als Allheilmittel für alle möglichen Probleme angepriesen. Das macht viele Führungskräfte und Mitarbeiter automatisch skeptisch. Zudem sind die aktuellen Rollen, Abläufe und Werte im Unternehmen die Überbleibsel der gemeinsamen Erfahrungen aus der Vergangenheit. Die Führungskräfte und Mitarbeiter glauben, dass diese Elemente der Organisation sie erfolgreich gemacht hat. Wer diese Elemente in Frage stellt – und das tun wir automatisch, wenn wir Scrum einführen -, der stellt auch den Erfolg aus der Vergangenheit in Frage. Wer aus der bisherigen Kultur ausbricht, bedroht die Gruppe. Das sind ganz starke Kräfte, gegen die man mit Argumenten nicht ankommt. Um zu verstehen, warum Scrum vielleicht doch für Ihr Unternehmen nützlich sein könnte, brauchen wir zunächst ein gutes Verständnis davon, warum es immer schwieriger wird, gute Projektergebnisse zu liefern und dass unsere interne Organisation doch eine große Rolle spielt. Hinweis: Wenn Sie mehr über Scrum wissen wollen, lesen Sie sich den aktuellen Scrum Guide durch: http://www.scrumguides.org/download.html 2 Unsicherheit beeinflusst den Projekterfolg viel stärker als wir denken Viele Projektbeteiligten unterschätzen den Einfluss von Unsicherheit auf das Projektmanagement. Wie groß ist eigentlich die Auswirkung von Unsicherheit auf meine Projektplanung? Wie viel Puffer muss ich einplanen, wenn ich mir nicht genau sicher bin? 10%, 20%, 100%. Am Beispiel eines ganz einfachen Schiffe-Versenken-Spiels werden wir sehen, dass nicht einmal 100% Puffer reichen, um erfolgreich zu sein.
  3. 3. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 3/15 Abbildung 1: Beispiel "Schiffe versenken" Im Beispiel in Abbildung 1 sehen wir auf einem Feld von 5x5 Einheiten drei Schiffe. Die Experten sind sich einig, dass diese drei Schiffe mit 7 Schüssen versenkt werden können. Frage: Was kostet das Projekt „alle S hiffe erse ke “, e ei S huss . EUR kostet?  Die Kosten von 700.000 EUR sind nicht zu unterbieten. Das ist der Minimalbetrag.  Die Maximalkosten sind 2,5 Mio. EUR, d. h. alle 25 Felder werden beschossen. Im schlechtesten Fall schießt der Auftragnehmer 18mal vorbei. Der Auftraggeber muss also den 3,5fachen Betrag einplanen, um ganz sicher zu sein. Ein klassisches Wasserfallprojekt würde sich einen Schussplan für alle 25 Felder überlegen. Am Ende erfährt der Kunde, dass alle Schiffe versenkt wurden. Gibt es eine realistische Möglichkeit mit weniger Schüssen auszukommen? Wir hören oft, dass sich Entwickler darüber aufregen, dass ihre Kunden nicht genau sagen, was sie wollen. Die Frage nach den genauen Anforderungen in Softwareprojekten entspricht beim Spiel der Frage, auf welches Feld man denn genau zielen solle. Aber
  4. 4. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 4/15 können die Kunden diese Frage beantworten? Sie wissen ja auch nicht, ob auf B1 ein Schiff steht. Wie lässt sich Unsicherheit in IT-Projekten genauer beschreiben? Es gibt zwei Wissenschaftler, die in den letzten 25 Jahren sehr viel über Kategorisierungs- möglichkeiten von Projekten, über Risiko, Komplexität oder Zusammenhang von Planung und Projekterfolg geschrieben haben. Aaron Shenhar1 ist heute CEO der Beratungsfirma SPL Group. Davor war er an verschiedenen Universitäten als Professor tätig. Dov Dvir2 ist seit 2010 emeritierter Professor für Management an der Ben Gurion Universität in der Negev in Beer-Sheva, Israel (Guilford Glazer Faculty of Business and Management). Das Bu h „Rei e ti g Proje t Ma age e t“3 ist eine gute, lesbare und interessante Zusammenfassung ihrer forschenden und beratenden Tätigkeit. Shenhar und Dvir haben viel zu einem besseren Verständnis von Projekten beigetragen. Ein Projekt zu führen bedeutet, Ergebnisse unter Unsicherheit liefern. Wir kennen viele Formen von Unsicherheit. Interessant ist, dass Shenhar und Dvir von 4 Arten von Unsicherheit ausgehen und zwar nur von 4. Diese 4 Arten sind Neuheit, Technologie, Komplexität und Zeitdruck.  Neuheit: Wie gut kennen Sie Ihre Kunden und wie gut können Sie einschätzen, ob das Ergebnis angenommen wird?  Technologie: Wie gut kennen Sie sich mit Techniken, Methoden und Systemen aus, die Sie für die Projektarbeit brauchen?  Komplexität: Wie viele unterschiedliche Abteilungen und Organisationen arbeiten mit und wie gut müssen die Teilergebnisse für ein funktionierendes Gesamtsystem aufeinander abgestimmt sein? 1 Vita siehe http://www.splwin.com/jversion/shenhar_cv.pdf und http://howe.stevens.edu/pages/hsatm-conference/schedule/aaron-shenhar/ 2 Vita siehe http://in.bgu.ac.il/fom/Management/StaffCV/Dov%20Dvir%20CV%20Feb_2013.pdf 3 Siehe Shenhar/Dvir 2007: Shenhar, Aaron J., and Dov Dvir. Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation. 1st ed. Mcgraw-Hill Professional, 2007.
  5. 5. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 5/15  Zeitdruck: Wie hoch ist der Zeitdruck? Wie hoch ist der Schaden, wenn nicht rechtzeitig reagiert wird? Zur visuellen Darstellung haben Shenhar und Dvir ein Koordinatensystem mit 4 Achsen gewählt (siehe Abbildung 2). Abbildung 2: Das Rautenmodell von Shenhar und Dvir Jede Achse steht für eine Art von Unsicherheit. Jede Achse ist in 3 oder 4 Stufen unterteilt. Stufen nahe an der Mitte stehen für Projekte, die eher einfach zu führen sind. Stufen, die weiter außen sind, deuten auf schwierige Projekte mit hoher Unsicherheit hin. Abbildung 3 zeigt die Profile von zwei verschiedenen Projekten. Komplexität Neuheit Technologie Zeitdruck BreakthroughDerivative PlatformAssemblyArray System Regular Fast/ Competitive Time-Critical Blitz Super-High Tech High-Tech Medium-Tech Low-Tech
  6. 6. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 6/15 Abbildung 3: Profil von einem einfachen Projekt (blau) und einer Produktentwicklung (rot) Im blauen Projekt gibt es nicht so viel Unsicherheit. Die Anforderungen sind bekannt, weil der Kunde im Prinzip nur eine leichte Abwandlung dessen haben will, was er schon kennt. Auch technologisch ist das Projekt für das Team keine Herausforderung, denn es kennt alle Techniken, Systeme und Arbeitsmethoden, mit denen es das Projektproblem lösen will, sehr gut.
  7. 7. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 7/15 Im roten Projekt ist es schon ganz anders. Vieles vom gewünschten System ist für den Kunden sehr neu. Er hat zwar eine grobe Vorstellung, davon, was er erreichen will, aber die genauen Anforderungen kann er frühestens zur Mitte des Projekts fixieren. Auch das Team nicht mehr ganz sicher, ob die alten Designs und Zeitpläne noch funktionieren. Es setzt neben bekannten Technologien auch neue ein. Es muss sich nicht nur in die neuen Techniken und Methoden einarbeiten, sondern es muss auch eine Zeitlang mit mehreren Designs parallel arbeiten, weil es nicht sicher sein kann, welches am besten funktioniert. In Situationen hoher Unsicherheit gibt es keine Wahrheit. Das Projektteam hat nun zwei Möglichkeiten: entweder wartet es, bis alle Anforderungen zu 100 Prozent klar sind und bis es in die neuen Techniken komplett eingearbeitet ist. Oder schaltet auf eine iterative Arbeitsweise um, um schrittweise neue Dinge auszuprobieren und um dazu zu lernen. Warten kostet viel Zeit, die wir uns oft nicht mehr leisten können. Bei Scrum warten wir nicht mehr auf die perfekte Lösung. Stattdessen arbeiten wir in Sprints und holen uns am Sprintende Feedback über die aktuelle Lösung und steuern nach. Deswegen brauchen wir bei Scrum am Ende eines Sprints immer funktionierende Software, auch wenn ihr Funktionsumfang noch gering ist. Wenn Sie Scrum benutzen wollen, tun Sie das besser nicht aus ideologischen Gründen oder weil Sie der Mode folgen wollen. Scrum ist keine Modeerscheinung und Scrum ist kein Allheimmittel. Scrum ist eine Herangehensweise, mit der das Projektteam iterativ Zwischenergebnisse liefert. Eine iterativ-inkrementelle Arbeitsweise ist die einzige Methode, die bei hoher Unsicherheit funktioniert. 3 Custom Scrum und Real Scrum Sie verstehen nun, dass eine iterativ-inkrementelle Arbeitsweise besser geeignet ist, mit Unsicherheit in Projekten umzugehen. Dann können Sie auch folgende Anpassungen besser einschätzen, die wir oft in der Praxis sehen. Custom Scrum Real Scrum Scrum nutzen, aber keine funktionsfähige Software am Sprintende liefern. Mit jedem Sprint ein Produktinkrement liefern. Mit Scrum die alten Projekte abwickeln, aber keine Ziele setzen. Klare Projektvision, echte Sprintziele
  8. 8. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 8/15 In Streitfragen zum Produkt setzt sich der Projektmanager oder Chef durch. Empirisch arbeiten, Annahmen treffen und Daten sammeln. Scrum aus ideologischen Gründen einführen. Scrum nutzen, um besser mit Unsicherheit umzugehen. Tabelle 1: Vergleich Custom Scrum und Real Scrum Empfehlungen:  Sorgen Sie dafür, dass Mitarbeiter und Führungskräfte den Begriff Unsicherheit gut verstehen, bevor Sie über Scrum sprechen. Nutzen Sie dazu den Vergleich mit Schiffe versenken und das Rautenmodell von Shenhar und Dvir.  Eine etwas längere Beschreibung des Rautenmodells finden Sie im Vortragsarchiv des Scrum Days 2013: http://archiv.scrum- day.de/archiv/scrumdayjun13berlin/vortraegedownload/Mit_Projektprofilen_Sc rum_besser_verkaufen.pdf  Ma he die die Ü u g „Lea Startup S o flakes“ i Tea , um zu zeigen, dass man auch trotz unklarer Vorgaben gute Ergebnisse erreichen kann. Die Beschreibung finden Sie bei Tasty Cup Cakes: http://tastycupcakes.org/2012/05/lean-startup-snowflakes/ 4 Über die Art, wie wir zusammen arbeiten, können wir den Projekterfolg erheblich steuern Viele Mitarbeiter im Projektteam haben keine Vorstellung davon, wie stark geänderte Arbeitsabläufe zu besseren Ergebnisse führen. Aber wie viel Verbesserung bringt echtes Scrum? 10%, 30%, 50% oder gar 100%? In der Praxis haben wir keinen Blick für die Warteschlangen, die Losgrößen oder Übergabepunkte in unseren Geschäftsprozessen entwickelt. Wir wissen nicht, wie viel Zeit Multitasking oder das ständige Stören wirklich kostet. In unseren Betrieben haben wir uns (im Gegensatz zu unserem Privatleben) so sehr an Spezialisierung gewöhnt, dass wir uns ein Leben ohne sie gar nicht mehr vorstellen können. Wir haben selten erfahren, dass Priorisierung ein echtes Steuerungsinstrument für Projektarbeit ist. Erneut können wir Spiele nutzen, um diese Dinge in kurzer Zeit nachzuempfinden. Dazu brauchen wir ein Spiel, bei dem man am Anfang wie selbstverständlich verschiedene Spezialisten braucht, um ein Projekt erfolgreich abzuschließen. Das Projekt muss aus
  9. 9. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 9/15 verschiedenen Arbeitspaketen bestehen, die wiederum aus verschiedenen Schritten bestehen. Für unsere Trainings haben wir die Ideen und Abläufe von Karl Scotlands Lego Flow Game4 übernommen. Allerdings haben wir das Material geändert und die Regeln etwas vereinfacht. Die Spielidee ist einfach: Ein Team von mehreren Personen muss in 6 Minuten ein Projekt mit mehreren Arbeitspaketen abschließen. Die Arbeitspakete bestehen darin, eine vorgegebene Fläche mit Formen auszufüllen. Das Team muss einen Wert von 32 Punkten liefern. In drei Runden probieren wir verschiedene Konfigurationen der Zusammenarbeit. Wir starten mit einem klassischen Wasserfall mit festen Rollen und großen Stapeln. Rollen:  Auftraggeber: bestimmt das Ergebnis, nimmt es ab  Analyst: plant die Arbeitspakete (=sucht die Legetafeln zu den Aufträgen raus)  Lieferant: liefert die Teile  Entwickler: baut das Ergebnis zusammen  Tester: prüft das Ergebnis vor der Abnahme  Projektmanager: bittet nach der Hälfte der Zeit um einen Statusbericht. Ablauf:  Auftraggeber legt erst das Ergebnis fest  Analyst erstellt erst alle Arbeitspakete  Lieferant liefert erst alle Teile  Entwickler baut erst alle Objekte  Tester testet alles vor der Abnahme Ergebnis: Das Team liefert keine fertigen Aufträge ab. Das Team vermutet, dass das Projekt um ein Mehrfaches der Zeit verlängert werden muss, um die 4 Siehe http://availagility.co.uk/lego-flow-game/
  10. 10. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 10/15 Minimalanforderungen zu liefern. Selbst, wenn man die ungetestete Arbeit anrechnen würde, käme man gerade auf die Hälfte des Projektziels. Das Team merkt schon, dass die großen Arbeitsstapel hinderlich sind. Es will die Arbeit weitergeben, sobald etwas fertig ist. Um das System nicht zu überlasten, führen wir in der zweiten Runde an jeder Arbeitsstation zwei Pufferplätze ein. Rollen:  Auftraggeber: bestimmt das Ergebnis, nimmt es ab  Analyst: plant die Arbeitspakete  Lieferant: liefert die Teile  Entwickler: baut das Ergebnis zusammen  Tester: prüft das Ergebnis vor der Abnahme  Teamleiter: macht am Taktende ein Review und eine kurze Retro. Ablauf:  Auftraggeber priorisiert, gibt ein Paket nach dem anderen weiter  Analyst, Lieferant, Entwickler und Tester arbeiten, sobald Arbeit da ist.  Jede Station hat zwei Puffer. Arbeit darf nur in den Puffer, wenn dort ein Platz frei ist. Ergebnis: Das Team schafft das Projektziel. Allerdings wünscht es sich, mit der Spezialisierung flexibler umgehen zu können. Das machen wir in der dritten Runde. Rollen:  PO (Auftraggeber): bestimmt das Ergebnis, priorisiert, nimmt ab  Entwicklungsteam: plant die Arbeitspakete, besorgt die Teile, baut das Ergebnis zusammen, prüft das Ergebnis.  Scrum Master: organisiert am Sprintende ein Review und eine Retro. Ablauf:  PO legt erst das Ergebnis und die Reihenfolge fest (Bitte auf Wert und Aufwand achten!)  Entwicklungsteam organisiert sich selbst. Keiner testet seine eigene Arbeit.
  11. 11. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 11/15  Sprintlänge 2 Min. Ergebnis: Das Team schafft mehr als den doppelten Wert des Projektziels. Durch den kürzeren Takt gibt es eine Retrospektive mehr, in der etwas verbessert werden kann. Abbildung 4: Beispiel für die Prozessverbesserungen von zwei Teams (rot und blau) Beispielergebnis:  Runde 1: 0 Wertpunkte (Wert der ungetesteten Arbeit ist 16)  Runde 2: 48 Wertpunkte (Projektziel von 32 Wertpunkten übertroffen)
  12. 12. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 12/15  Runde 3: 84 Wertpunkte (Projektziel von 32 Wertpunkten schon nach 2 Minuten erreicht) In der Nachbesprechung stellt das Team fest, dass sich folgende Punkte verbessert haben:  Nach dem ersten Sprint wurde in der Retrospektive die Anordnung der Bauanleitungen geändert, sodass alle schneller darauf Zugriff haben. Zudem wurden bereits zu Beginn alle Legeplättchen aus den Tüten genommen. Das Material war so für alle leichter verfügbar.  Der PO hat bei den Aufträgen darauf geachtet, dass viel Wert bei gleichzeitig wenig Aufwand geliefert wurde.  Es gab ein interdisziplinäres Team, bei dem jedes Teammitglied alle Aufgaben übernommen hat.  Das Sprintbacklog war gut gefüllt. Jeder hat sich den nächsten Auftrag aus dem Backlog geholt, wenn er mit seiner Arbeit fertig war. Dadurch waren die Wartezeiten sehr gering.  Es war transparent, wer an welchem Auftrag gearbeitet hat.  Die Teammitglieder haben sich gegenseitig bei Bedarf geholfen. Es wurde offen kommuniziert.  Die Gruppe hat gemeinsam gelernt. Durch diese Simulation haben die Kollegen gemerkt, wie stark die Art der Zusammenarbeit das Ergebnis beeinflusst. Das Team hat im Vergleich zur ursprünglichen Konfiguration die fünffache Leistung geliefert. 5 Custom Scrum und Real Scrum Wenn Sie wissen, dass die Art der Zusammenarbeit ein langer Steuerungshebel ist, dann können Sie auch folgende Anpassungen besser einschätzen, die wir oft in der Praxis sehen. Custom Scrum Real Scrum Größe der Arbeitspakete nicht verändern. Viele kleine User Storys schreiben und schnell abschließen.
  13. 13. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 13/15 Spezialisierung aufrechterhalten. Multifunktionales Team aufbauen und konsequent am Wissenstransfer arbeiten (z. B. mit Pair Programming) Aufwand in Stunden schätzen. Aufwand relativ in Story Points und Velocity messen. Arbeit nicht priorisieren. Gemeinsam ein Gefühl für Wert entwickeln und konsequent priorisieren. Tabelle 2: Vergleich Custom Scrum und Real Scrum Empfehlungen:  Bevor Sie über Änderungen in den Abläufen sprechen, machen Sie sich bewusst, dass das ein langer Steuerungshebel ist. Spielen Sie zum Beispiel das o. g. Spiel in der Gruppe. Fragen Sie die Gruppe am Ende des Spiels, welche Kurve den Beteiligten am besten gefällt.  Bilden Sie Ihre Scrum Master gut aus, damit diese auf die Zusammenarbeit achten. 6 Zusammenfassung Scrum ist keine Modeerscheinung. Scrum ist eine Art, um auf die steigende Komplexität und Unsicherheit in den Unternehmen zu reagieren. Bevor Sie Scrum in Ihrem Unternehmen einführen, sorgen Sie dafür, dass alle Beteiligten – nicht nur das Entwicklungsteam – ein gutes Verständnis von Scrum bekommen. Ein gemeinsames Training ist sehr sinnvoll. Die wesentlichen Begriffe für Scrum sind Unsicherheit und Prozess. Unsicherheit hat einen erheblichen Einfluss auf unsere Projektarbeit. Das unterschätzen wir oft. In unsicheren Situationen ist es besser, schrittweise dazuzulernen. Gute Praxis ist es deshalb:  Mit jedem Sprint ein Produktinkrement zu liefern.  Eine klare Projektvision und echte Sprintziele zu definieren  Empirisch zu arbeiten, Annahmen zu treffen und zu Daten sammeln.  Scrum zu nutzen, um besser mit Unsicherheit umzugehen. Die Art, wie wir zusammenarbeiten, ist ein großer Steuerungshebel. Führen Sie Scrum nicht nur mechanisch ein. Machen Sie sich bewusst, dass die Scrum-Community viele
  14. 14. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 14/15 Experimente gemacht hat, um die Zusammenarbeit zu verbessern. Gute Praxis ist es deshalb:  Die Arbeit in viele kleine User Storys aufzuteilen, die man schnell abschließen kann.  Ein multifunktionales Team aufzubauen und konsequent am Wissenstransfer zu arbeiten (z. B. mit Pair Programming).  Den Aufwand immer und von Anfang in relativ in Story Points zu schätzen und die Velocity zu messen.  Gemeinsam ein Gefühl für Wert zu entwickeln und konsequent zu priorisieren. Viel Erfolg bei Ihrer Scrum-Einführung. Bei Fragen sprechen Sie uns an. 7 Über Scrum Events und den Autor, Kontakt Scrum Events (eine Marke der HLSC GmbH) bietet Weiterbildungen, Zertifizierungen und Beratung rund um das Thema agile Softwareentwicklung, insbesondere mit Scrum in Verbindung mit Projektmanagement, an. Unsere absoluten Highlights sind die Scrum- Workshops, Scrum-Trainings und Scrum-Schulungen mit Jeff Sutherland und Ken Schwaber, den beiden Erfindern von Scrum. Wir unterstützen Sie beim Einsatz von Scrum in Projekten, der unternehmensweiten Einführung von Scrum und Agilität. Wir beraten Ihr Management und geben Ihnen Feedback zum aktuellen Stand Ihres agilen Vorgehens. Scrum Events richtet jährlich den Scrum Day in Deutschland aus. Diese Konferenz über Scrum, Agilität und Skalierung von Scrum ist ein beliebtes Treffen der Scrum-Community mit mehreren hundert Teilnehmern. Jan Fischbach arbeitet als Trainer und Berater für die Firma Scrum Events und ist Geschäftsführer der Organisationsberatung Common Sense Team GmbH (www.commonsenseteam.de). Er ist Experte für Projektmanagement, IT-Betrieb, Dokumentenmanagement und IT-Verträge. Er hilft Teams bei der Einführung von Scrum und nutzt selbst Scrum in Prozessverbesserungsprojekten in der freien Wirtschaft und in der Verwaltung. Vor seiner Selbstständigkeit war er u. a. mehrere Jahre als Führungskraft in der IT eines internationalen Medienkonzerns tätig.
  15. 15. Agiles Projektmanagement - Good Practices beim Start mit Scrum Seite 15/15 Jan Fischbach ist Diplom-Ingenieur für Elektrotechnik/Technische Informatik. Er ist zertifizierter Scrum Master und Product Owner. Im Umfeld von IT-Projekten ist er zertifiziert in den Methoden PRINCE2 und Scaled Agile Framework. Er ist Fachautor und schreibt regelmäßig im www.teamworkblog.de. Kontakt: Scrum Events (HLSC GmbH) Dornhalde 1 70597 Stuttgart www.scrum-events.de www.scrum-day.de Jan Fischbach Mobil: +49 (172) 589 00 25 E-Mail: jan.fischbach [bei] scrum-events.de Blog: www.teamworkblog.de

×