Agiles Projektmanagement nach SCRUM – auch als Online Live Training

Die SCRUM-Prüfungen werden durch den TÜV SÜD als Paperbased-Prüfung und durch die ICO als Onine-Prüfung abgenommen. Sowohl das TÜV SÜD Examination Institute als auch die ICO sind beim mITSM die Zertifizierungsstellen für die Personenzertifizierung im Bereich agiles Projektmanagement nach SCRUM. Sie entscheiden, welches Prüfungsformat Sie ablegen müssen und damit welche Stelle Sie zertifiziert.

Sie haben bei unseren SCRUM-Schulungen die Wahl zwischen einer Online-Prüfung durch die ICO und einer Paperbased-Prüfung des TÜV SÜD. Bei der Online-Prüfung entscheiden Sie, wann und wo Sie die Prüfung ablegen. Die Paperbased-Prüfung findet direkt im Anschluss an die Schulung statt.

Für unsere SCRUM-Kurse SCRUM Foundation, SCRUM Master und SCRUM Product Owner können Sie sich PDUs (Professional Development Units) für PMP^® und PgMP^® Zertifizierungen des Project Management Institute über „Category B: Continuing Education“ anrechnen lassen. Die genaue Anzahl an PDUs können Sie über das CCRS bestimmen. Grundsätzlich ist dafür die Teilnahmebestätigung und die Angabe der Schulungsdauer, die in der Anmeldebestätigung und auf unserer Website steht, ausreichend. Wir stellen Ihnen aber auch gerne eine Bestätigung über die Stundenanzahl des Trainings aus.

Nein, auch wenn SCRUM seinen Ursprung in der Softwaretechnik hat. Heute gilt SCRUM als Vorgehensmodell des Projekt- und Produktmanagements allgemein.

Selbstverständlich. Bitte beachten Sie aber, dass wir auch hier eine maximale Anzahl von 12 Teilnehmern pro Schulung empfehlen.

Leider nicht. Ob andere gleichwertige Zertifikate als Zugangsvoraussetzung anerkannt werden können, wird derzeit geklärt.

Ja, definitiv! Obwohl die Wurzeln von SCRUM in der Softwareentwicklung liegen, bietet SCRUM viele Methoden, die auch für andere Disziplinen sehr nützlich sind. In der SCRUM Foundation Schulung wird hierauf genauer eingegangen.

Für die Ausbildung zum SCRUM Master benötigen Sie die zweitägige SCRUM-Foundation-Ausbildung mit der entsprechenden Prüfung sowie die zweitägige SCRUM-Master-Schulung mit der dazu gehörigen Prüfung. Mit dem eintägigen Product Owner Add-on könnten Sie dann auch das Zertifikat zum SCRUM Product Owner erhalten, da der allgemeine Teil der SCRUM Master bzw. Product Owner Schulungen und Prüfungen identisch ist.

Für die Ausbildung zum SCRUM Product Owner benötigen Sie die zweitägige SCRUM-Foundation-Ausbildung mit der entsprechenden Prüfung sowie die zweitägige Schulung zum SCRUM Product Owner mit der dazu gehörigen Prüfung. Mit dem eintägigen SCRUM Master Add-on könnten Sie dann auch das Zertifikat zum SCRUM Master erhalten, da der allgemeine Teil der SCRUM Master bzw. Product Owner Prüfungen identisch ist.

Als Mitglied eines Entwicklerteams benötigen Sie aus unserer Sicht nur die SCRUM-Foundation-Schulung. Dieses Seminar sollten Sie aber unbedingt mit Prüfung abschließen, da Sie ja eventuell noch andere Rollen in der Organisation übernehmen werden. Aufbauend auf das Zertifikat der SCRUM Foundation, haben Sie dann die Möglichkeit, innerhalb von zwei Tagen SCRUM Master oder Product Owner zu werden bzw. können einen dreitägigen Kurs mit dualer Abschlussmöglichkeit besuchen.

Diese Frage lässt sich nicht so einfach beantworten. Bei Beratern steht die SCRUM Master Ausbildung ganz klar im Vordergrund. Für Unternehmen, die nach SCRUM vorgehen, ist es allerdings wesentlich wichtiger, gute Product Owner mit im Boot zu haben. Denn diese Rolle ist letztendlich dafür verantwortlich, den optimalen Mehrwert aus der agilen Methodik zu generieren. Den Erfolg eines SCRUM Masters hingegen erkennt man daran, dass sich diese Rolle mit der Zeit entbehrlich macht.

1. Die Akkreditierung des TÜV SÜD Examination Institute nach ISO/IEC 17024 garantiert Ihnen die Qualität und Neutralität der SCRUM-Zertifizierung. Das SCRUM-Zertifizierungsangebot des TÜV SÜD ist das erste auf diesem Gebiet von einer Zertifizierungsstelle, die sich nach der Norm ISO/IEC 17024 richtet. Die europaweit anerkannte Personenzertifizierung auf Grundlage dieser Norm ist eines der besten Kriterien um die Kompetenz zertifizierter Experten prüfen zu können.

2. Die ITEMO (IT Education Management Organisation) hat sich die Ausbildung im Bereich IT-Management auf die Fahne geschrieben. Neben Spezialisten für Fachthemen wie SCRUM, gibt es hier auch Experten für die Aus- und Weiterbildung an sich. Schulungen und Prüfungen sind kein „Nebenprodukt“, sondern das Kernthema der Organisation und seiner Partner.

3. Anders als bei einigen anderen Anbietern, gilt das TÜV-SÜD-Zertifikat lebenslang und muss nicht rezertifiziert werden.

SCRUM ist eine Projektmanagement-Methode, die Teams dabei hilft, Produkte mit höherer Qualität und in kürzerer Zeit zu liefern.

Einige der wichtigsten Gründe sind:

• SCRUM ist schnell anwendbar. Es ist einfach, hat nur drei Rollen und klare Vorgaben.
• Es gibt sehr viele erfolgreiche Referenzprojekte für SCRUM.
• Es ist weit verbreitet und es gibt viele Anbieter für Kurse und praktische Unterstützung.

Für die meisten Projekte gilt, dass sich ihre Anforderungen (Kundenwünsche, Marktanforderungen, Regulatorien etc.) während der Projektphase ändern. Agile Methoden sind speziell dafür geeignet, mit diesen Änderungen umzugehen und die Entwicklung dem Kunden gegenüber transparent darzustellen.

• Häufigere und realistischere Informationen über den Status der Projekte, da nach jeder der (maximal dreißig-tägigen) Iterationen ein testbares Resultat vorliegt.
• Daraus folgt auch eine höhere Transparenz und die Möglichkeit des früheren Eingreifens bei sich abzeichnenden Problemen.
• Durch enge Zusammenarbeit mit und Feedback vom Kunden kann ein höherer Wert des Endproduktes erreicht werden.
• Schnellere Marktreife durch Kunden-Feedbacks, erhöhte Motivation des Teams und weniger Leerlaufzeiten.

Am Anfang – und wenn das ganze Team am selben Ort ist – ist ein Whiteboard oft ausreichend. Bei komplexen oder verteilten Teams, ist ein Tool unverzichtbar. Das Tool sollte so flexibel sein, dass es den speziellen Anforderungen des Teams / der Organisation angepasst werden kann.

In SCRUM gibt es drei Rollen mit verschiedenen Verantwortungsbereichen: Product Owner, Entwicklungsteam und SCRUM Master.

In SCRUM gibt es fünf sich wiederholende Verfahren: SPRINT, SPRINT Planning, SPRINT Review, Daily SCRUM und SPRINT Retrospective.

In SCRUM gibt es die folgenden drei Arbeitsergebnisse: Product Backlog, SPRINT Backlog und Product Increment.

SCRUM ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Aufgabenstellungen, das die Anwender in die Lage versetzt, kreativ Produkte mit dem höchstmöglichen Wert zu liefern.

SCRUM ist leichtgewichtig und einfach zu verstehen, dennoch meist schwierig zu meistern.

Ja. Die Regeln in SCRUM beschreiben die Wechselwirkungen zwischen den Ereignissen, Rollen und Artefakten. Die Regeln von SCRUM werden im Scrum Guide definiert.

Die für das Ergebnis Verantwortlichen müssen das Projekt durchschauen können. Es ist daher erforderlich, Aspekte nach einem gemeinsamen Standard zu definieren, um den Beteiligten die Möglichkeit zu geben, ein gemeinsames Verständnis für das transparente, also durchschaubare Vorgehen zu ermöglichen.

In SCRUM muss der Fortschritt ständig in Bezug auf die definierten Ziele des SPRINT überprüft werden, um rechtzeitig unerwünschte Abweichungen zu identifizieren und sie anpassen zu können. Natürlich sollen diese Überwachungen angemessen erfolgen, so dass sie die tägliche Arbeit nicht behindern. An die Prüfer wird daher bezüglich ihrer Fähigkeit eine hohe Anforderung gestellt.

Durch den Prüfer werden bei einem Review gegebenenfalls Abweichungen festgestellt, die nicht mehr tolerierbar sind. In diesem Fall muss der Prozess oder das Objekt entsprechend angepasst werden.

Ja. In den Ereignissen SPRINT Planning, SPRINT Review, Daily SCRUM und SPRINT Retrospective schreibt SCRUM eine formale iterative Überprüfung, Anpassung und Dokumentation vor.

Die Mitglieder des SCRUM Teams sind Product Owner, das Entwicklungsteam sowie der SCRUM Master.

Unter Interdisziplinären Teams versteht man Teams, in denen alle Fähigkeiten, die erforderlich sind, um die gestellten Aufgaben zu erledigen, in sich vereinen. Das Team darf nicht von externen Ressourcen abhängig sein. In selbstorganisierenden Teams wird die Entscheidung, wie, wer und wann man die gestellten Ziele am besten meistern kann, durch das Team getroffen.

Die SCRUM Teams liefern regelmäßig und wiederholt Produkt-Inkremente von fertigen Produkten aus.

Die Hauptverantwortung des Product Owners ist die Wert-Maximierung des zu erstellenden Produkts. Er ist aber auch für die Arbeit und somit die Ergebnisse des Entwicklungsteams verantwortlich und hat die Aufgabe, das Product Backlog zu verwalten.

• Klare Formulierung der Einträge
• Priorisierung, Sortierung und Kategorisierung des Product Backlog, so dass die Aufgaben und Ziele effektiv und effizient erreicht werden können
• Sichtbarkeit (Transparenz) des Product Backlogs sicherstellen, so dass die nächsten Aktivitäten klar erkennbar sind
• Verständlichkeit der Anforderungen sicherstellen, so dass die Team-Mitglieder ein ausreichendes Verständnis für die jeweilige Aufgabe besitzen

Der Product Owner ist für die oben genannten Tätigkeiten accountable. Dies bedeutet, dass er dafür verantwortlich ist, dass sie „richtig“ gemacht werden. Jedoch kann er das Doing der einzelnen Aufgaben an Personen oder Mitglieder des Entwicklungsteams delegieren. Sollte das von ihm gewählte Mitglied die Aufgabe nicht korrekt und/oder rechtzeitig bearbeiten, so hat der Product Owner dies zu verantworten (Auswahlverschulden bzw. Überwachungsverschulden).

Der Product Owner muss immer eine Einzelperson sein. Er kann zwar die Wünsche eines Komitees vertreten bzw. berücksichtigen, aber die letztendliche Entscheidung über Eintragung und Veränderungen im Product Backlog trifft ausschließlich die Einzelperson.

Der Product Owner muss innerhalb der Organisation von allen anderen Beteiligten respektiert werden. Zum Beispiel darf es nicht vorkommen, dass Anforderungen direkt an das Entwicklungsteam gestellt werden. Der Product Owner ist also der einzige, der Vorgaben an das Entwicklungsteam stellen darf.

Nur Mitglieder des jeweiligen Entwicklungsteams sind für die Erstellung des Produktinkrements am Ende eines jeden SPRINTs verantwortlich und dürfen demzufolge an der Erstellung mitarbeiten.

Der Scrum Guide definiert, dass ein Inkrement potenziell auslieferbar sein muss. Dies bedeutet, zwar nicht, dass jedes Produktinkrement ausgeliefert wird, da noch andere Voraussetzungen nicht realisiert sein könnten. Zum Beispiel ist es möglich, dass ein anderes Produkt, das benötigt wird, nicht rechtzeitig fertig wurde.

Das Entwicklungsteam muss die Abarbeitung der ihm zugeteilten Aufgaben selbst organisieren und managen.

• Es ist selbstorganisierend und entscheidet allein, wie aus dem Product Backlog potenziell auslieferbare Produktinkremente gemacht werden. Selbst der SCRUM Master hat hier keine Einflussmöglichkeit
• Das Entwicklungsteam muss interdisziplinär sein. Dies bedeutet, dass das Team als Gesamtes alle Fähigkeiten besitzen muss, um ein Produktinkrement zu erzeugen (keine Abhängigkeit nach außen)
• Innerhalb eines Entwicklungsteams gibt es nur Entwickler. Vor allem sind keine Hierarchiestufen und andere Ausnahmen zu akzeptieren
• Innerhalb des Entwicklungsteams gibt es auch keine Unterteilung nach Tätigkeiten, wie z.B. testen, programmieren oder untersuchen. Für jede Aufgabe, die man theoretisch einer dieser Phasen zuordnen könnte, wird, je nach Anforderung, die derzeit beste Ressource zugeteilt
• Die Rechenschaftspflicht über das Product Increment liegt beim gesamten Entwicklerteam, auch, wenn einzelne Teammitglieder eventuell spezielle Fähigkeiten haben, sind sie nicht als Individuen für einzelne Fehler verantwortlich

Eine absolute Zahl ist hier schwierig zu nennen. Man geht davon aus, dass ein Entwicklerteam mehr als drei Personen haben sollte. Auf jeden Fall müssen alle Fähigkeiten vorhanden sein, um das Produktinkrement liefern zu können. Ebenso gilt als Standard, dass ein Team nicht mehr als neun Mitglieder haben sollte, da dann der Koordinationsprozess zu komplex würde. Product Owner und SCRUM Master werden übrigens nicht mitgezählt, außer, sie erledigen in Personalunion auch die Aufgaben eines Entwicklers.

Der SCRUM Master ist dafür verantwortlich, die Zusammenarbeit innerhalb der Organisation so zu optimieren, dass der Wert für das Unternehmen maximiert wird. Er ist kein zwingendes Mitglied des Entwicklungsteams, sondern eher ein „Servant Leader“.

Servant Leadership bedeutet, dass der Leader die Führerschaft kompromisslos auf die Interessen der Geführten ausrichtet. Friedrich der Große legte für dieses Prinzip den Grundstein mit dem Satz: „der Herrscher ist der erste Diener des Staates“. Die Aufgabe des Servant Leaders ist es, die Bedürfnisse anderer zu identifizieren und zu bestmöglich zu erfüllen.

• die Vermittlung von Techniken für die effektive Verwaltung des Product Backlogs
• Verständnis für die Notwendigkeit klarer Product Backlog Einträge im SCRUM Team schaffen
• Verständnis für die Produktplanung in einem empirischen (anwendungsbezogenen) Arbeitsumfeld schaffen
• Beratung des Product Owner bei der Priorisierung des Product Backlogs, um den optimalen Wert zu erreichen
• Verständnis für Agilität (Anpassungsfähigkeit) und deren Anwendung vermitteln
• Unterstützung bei der Durchführung von SCRUM Ereignissen

• Coaching des Entwicklungsteams in Bezug auf Selbstorganisation und funktionsübergreifende Teamarbeit
• Unterstützung des Teams bei der Erstellung erstklassiger Produkte
• Dafür sorge tragen, dass das Entwicklungsteam bei seiner Arbeit nicht behindert wird
• Hilfestellung bei der Durchführung von SCRUM Ereignissen leisten
• Coaching von Entwicklungsteams in Organisationen, denen der Begriff und das Prinzip SCRUM noch neu ist bzw. die es noch nicht ganz angenommen oder verstanden haben

• Leitung des Coachings von Organisationen bei der Einführung von SCRUM
• Planung der SCRUM-Implementierung in einer Organisation
• Unterstützung der Kollegen und Stakeholder (Anspruchsberechtigte) beim Verständnis von SCRUM und der empirischen Produktentwicklung
• Initiierung von Veränderungen zur Produktivitätssteigerung im Team
• Zusammenarbeit mit anderen SCRUM Masters, um die Wirksamkeit von SCRUM-Implementierungen innerhalb einer Organisation zu steigern.

Ein SCRUM Ereignis ist eine formale Möglichkeit zur Anpassung und Überprüfung an kritischen Stellen. Ereignisse sorgen in SCRUM für Regelmäßigkeit und Verringerung der Notwendigkeit von nicht in SCRUM definierten Besprechungen. Sie haben eine zeitliche Beschränkung (Time Box) und damit eine maximale Dauer. Die Dauer wird bei Sprintbeginn festgelegt und darf nicht verändert, also auch nicht gekürzt oder verlängert werden.

Der SPRINT ist das „Herz“ von SCRUM. Er ist eine Time Box von maximal einem Monat, in dem ein potenziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprints innerhalb eines Entwicklungsprojekts sollen von gleicher Dauer sein. Sprints starten direkt hintereinander, also der nächste Sprint folgt unmittelbar nach Abschluss des Vorherigen. Jeder Sprint hat einen definierten Leistungsumfang, einen Entwurf und einen Plan zu Umsetzung, Arbeit und Ergebnis.

Ein Sprint beinhaltet die Ereignisse Sprint Planning, Daily SCRUMS, Entwicklungsarbeit, Sprint Review und Sprint Retrospective.

Innerhalb eines Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden könnten Der Qualitätsanspruch wird nicht vermindert Bei neuen Erkenntnissen kann der Anforderungsumfang zwischen Product Owner und Entwicklungsteam neu ausgehandelt werden.

Mit der eindeutigen zeitlichen Festlegung eines Sprints wird die Vorhersagbarkeit eines Projekts durch Überprüfung und Anpassung des Fortschritts eines bestimmten Sprint-Ziels ermöglicht. Zudem verringern die 30-tägigen Sprints das Kostenrisiko auf nur einen Monat. Ein erhöhter Zeithorizont würde demnach auch das Risiko (Kosten, Komplexität, Ergebnis) erhöhen.

Ja, allerdings ist nur der Product Owner berechtigt, dies auszulösen.

Während SCRUM dafür verwendet wird, innerhalb von Projekten flexibel auf Änderungen reagieren zu können, ist Kanban mehr darauf ausgerichtet, bestehende betriebliche Abläufe kontinuierlich zu optimieren. Siehe auch http://blogs.versionone.com/agile_management/2012/07/30/scrum-or-kanban/

Weil SCRUM eine Projektmethode ist, die speziell gut dafür geeignet ist, mit sich schnell ändernden Anforderungen umzugehen.

Nein.

Ein analoges SCRUM-Board ist eine physische Repräsentation der Aufgaben eines Sprints (z.B. ein Whiteboard mit Post-its), das deren Bearbeiter und Status für alle anschaulich darstellt. Siehe auch http://scrumprouk.tumblr.com/post/52537981825/my-5-tips-for-scrum-adoption

Ja, da es sonst zu einem Effektivitätsverlust und mangelnder Identifikation mit den Projekten kommen kann. Siehe auch http://agileworld.blogspot.de/2009/12/scrum-faq.html

Davon wird stark abgeraten, aufgrund des inhärenten Interessenskonflikts zwischen diesen beiden Rollen.

Ja, solange gewährleistet ist, dass sie/er die Rolle als SCRUM Master weiterhin wahrnehmen kann.

30 Kalendertage.

Das Team kann den Product Owner um neue Tasks bitten oder die Qualität des Produkts verbessern, z.B. durch Refactoring.

In SCRUM werden Iterationen Sprints genannt.

Wenn Ihre IT-Projekte oft nicht die vom Kunden erwarteten Ergebnisse liefern, die Anforderungen erst im Laufe der Projekte mit dem Kunden erarbeitet werden können, oder die gegenwärtigen Methoden zu schwerfällig erscheinen, sind agile Methoden eine gute Option.

Agile Methoden sollten dann nicht verwendet werden, wenn

• es keine Probleme mit den derzeitigen Methoden und deren Resultaten gibt.
• Unsicherheit generell nicht akzeptabel ist. Dies gilt speziell, wenn die Konsequenz eintretender Risiken zu groß ist – Krankenhaussysteme, Raumfahrt, etc.
• zu große Unsicherheit herrscht, das heißt, wenn noch nicht einmal die groben Ziele feststehen. Dann gilt es, die Unsicherheit auf ein vernünftiges Maß zu reduzieren z.B. durch Pilotierung.
• kaum Unsicherheit herrscht, d.h. wenn klar ist, was geliefert werden soll.

Man benötigt fast immer die Unterstützung der Geschäfts- und IT-Leitung. Gutes Informationsmaterial und fundierte Argumentation sind unverzichtbar. Den Anfang macht oft ein für die Organisation wenig kritisches, kleines Pilotprojekt.

Sie sollten jemanden haben, der als SCRUM-“Evangelist” auftritt, d.h. die Vorteile und Aspekte der agilen Softwareentwicklung mit SCRUM anschaulich erklären und effizient in einem Pilotprojekt einführen kann.

Ja, die Vorteile von SCRUM (bessere Zusammenarbeit, Steuerbarkeit, schnelle Resultate etc.) sind auch mit anderen Projekttypen realisierbar. Unser SCRUM-Kurs richtet sich sogar speziell an Organisationen, die ein weiteres Spektrum an Projekten mit agilen Methoden durchführen wollen – wie zum Beispiel das Einführen von ITIL / Service Management.

Nein, aber die Rolle als SCRUM Master ist viel operativer, dynamischer und näher am Team als die eines klassischen Projektmanagers.