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.

http://www.scrum-events.de/

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.

http://www.scrumguides.org/download.html


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


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.

http://www.splwin.com/jversion/shenhar_cv.pdf

http://howe.stevens.edu/pages/hsatm-conference/schedule/aaron-shenhar/

http://in.bgu.ac.il/fom/Management/StaffCV/Dov%20Dvir%20CV%20Feb_2013.pdf


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


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.


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


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

http://archiv.scrum-day.de/archiv/scrumdayjun13berlin/vortraegedownload/Mit_Projektprofilen_Scrum_besser_verkaufen.pdf



http://tastycupcakes.org/2012/05/lean-startup-snowflakes/


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/

http://availagility.co.uk/lego-flow-game/


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.


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)


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.


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


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.

http://www.commonsenseteam.de/


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

http://www.teamworkblog.de/

http://www.scrum-events.de/

http://www.scrum-day.de/

http://www.teamworkblog.de/