Good Practices beim Start mit Scrum
-
Upload
polariondeutschland -
Category
Software
-
view
43 -
download
1
Transcript of Good Practices beim Start mit Scrum
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.
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.
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
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.
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ätNeuheit
Technologie
Zeitdruck
BreakthroughDerivative PlatformAssemblyArray System
Regular
Fast/ Competitive
Time-Critical
Blitz
Super-High Tech
High-Tech
Medium-Tech
Low-Tech
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.
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
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
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/
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.
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)
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.
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
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.
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