SCRUM-Schulungen – In München, Online und als Inhouse Training

Zertifizierungsinstanzen für SCRUM beim mITSM

Die ICO – International Certification Organization – ist unsere Zertifizierungsstelle für die Personenzertifizierung im Bereich agiles Projektmanagement nach SCRUM.

Bei der Zertifizierungsprüfung unserer SCRUM-Seminaren handelt es sich um eine Online-Prüfung, die durch die ICO abgenommen wird. Du entscheidest selbst, wann und wo du die Prüfung ablegst.

Nein.

Auch wenn SCRUM seinen Ursprung in der Softwaretechnik hat, gilt SCRUM heute als Vorgehensmodell des Projekt- und Produktmanagements allgemein.

Selbstverständlich.

Jedoch empfehlen wir auch hier eine maximale Anzahl von 12 Teilnehmern pro SCRUM-Schulung.

Ja, ist es. Folgende Grundlagen-Zertifizierungen können anerkannt werden:

• Professional Scrum Master Level I (PSM I) oder höher nach scrum.org
• Certified Scrum Master (CSM) oder höher der Scrum Alliance
• Agile Scrum Foundation oder höher der EXIN
• Scrum Foundation oder höher der International Certification Organization AG
• Scrum Master nach TÜV SÜD Akademie
• ScrumMaster certified by bg / Product Owner certified by bg

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.

Ausbildung zum SCRUM Master

Dafür benötigst du 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önntest du dann auch das Zertifikat zum SCRUM Product Owner erhalten, da der allgemeine Teil der SCRUM-Schulung und Prüfung für den Master bzw. Product Owner identisch ist.

Ausbildung zum SCRUM Product Owner

Dafür benötigst du die zweitägige SCRUM-Foundation-Ausbildung mit der entsprechenden Prüfung. Danach empfiehlt es sich die zweitägige Schulung zum SCRUM Master Professional Ausbildung zu besuchen. Mit dem eintägigen SCRUM Product Owner Add-on erlangst du zusätzlich das rollenspezifische Wissen, das du als SCRUM Product Owner benötigst. Wenn du nur SCRUM Product Owner werden möchtest, kannst du den zweiten Tag der SCRUM Master Professional Schulung auslassen – dieser vermittelt das rollenspezifische Wissen des SCRUM Masters. In diesem Fall, melde dich gerne bei uns – wir lassen dir ein maßgeschneidertes Angebot zukommen!

Als Mitglied eines Entwicklerteams benötigst du aus unserer Sicht nur die SCRUM-Foundation-Schulung.

Dieses Seminar solltest du aber unbedingt mit Prüfung abschließen, da du ja eventuell noch andere Rollen in der Organisation übernehmen wirst. Anschließend kannst du – aufbauend auf das Zertifikat der SCRUM Foundation – innerhalb von zwei Tagen SCRUM Master oder Product Owner werden, bzw. kannst 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. Hingegen ist es für Unternehmen, die nach SCRUM vorgehen, oft 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. Demgegenüber erkennt man den Erfolg eines SCRUM Masters  daran, dass sich diese Rolle mit der Zeit entbehrlich macht.

Drei Gründe für ein ICO-Zertifikat

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

Anders als bei einigen anderen Anbietern, gilt das ICO-Zertifikat lebenslang und muss nicht rezertifiziert werden.

Ja! Für jede Stunde Training erhältst du 1 PDU. Ein zweitägiger Foundation-Kurs bringt dir also 14 PDUs. Eine genaue Anleitung, wie du die PDUs in deinem PMI-Konto erfasst, findest du hier.

Nein, wir akzeptieren keine Bildungsgutscheine. Allerdings sind wir von der Agentur für Arbeit anerkannt (AZAV zugelassener Träger) und erstellen dir als Arbeitssuchenden gerne ein individuelles Angebot zur Vorlage bei deinem Ansprechpartner.

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.
• SCRUM 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. Dabei sollte das Tool 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, Entwickler 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, die Entwickler 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 der Entwickler 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 die Entwickler 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 die Entwickler gestellt werden. Also ist der Product Owner der einzige, der Vorgaben an die Entwickler stellen darf.

Nur die jeweiligen Entwickler 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.

Die Entwickler müssen 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 Team der Entwickler 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)
• Unter den Entwicklern gibt es keine Hierarchiestufen und andere Ausnahmen
• Im Team der Entwickler 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 SCRUM-Team mehr als drei Entwickler 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.

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.

Der Sprint 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 Entwicklern 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. Demnach würde ein erhöhter Zeithorizont 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. Mehr dazu in unseren SCRUM-Schulungen oder unter 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. Mehr dazu in unseren SCRUM-Schulungen oder unter http://scrumprouk.tumblr.com/post/52537981825/my-5-tips-for-scrum-adoption

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, sicher.

Die Vorteile von SCRUM (bessere Zusammenarbeit, Steuerbarkeit, schnelle Resultate etc.) sind auch mit anderen Projekttypen realisierbar. Unsere SCRUM-Schulung 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.