Rollen: Scrum Master, Product Owner, Entwickler:Innen
Rituale: Sprint, Sprint Planungssitzung, Daily Scrum, Spint Review, Sprint Retrospektive
Artefakte: Product Backlog, Sprint Backlog, Produktinkrement

Fokus: Das Projektziel bzw. das jeweilige Sprintziel stehen im Fokus der Projektmitglieder. Eine Limitierung des WIP (Work in Progress) hilft hierbei. Eine der Hauptaufgaben des Scrum Master ist es, Unterbrechungen und Störungen vom Scrum Team fernzuhalten.

Commitment: Das gemeinsam vereinbarte Ziel wird von sämtlichen Mitgliedern respektiert, akzeptiert und angenommen.

Offenheit: Ein angenehmes Arbeitsklima in welchem Probleme offen angesprochen werden können, ist Grundvoraussetzung für die erfolgreiche Arbeit mit Scrum.

Mut: Mut haben, die eigene Meinung zu sagen und sich schwierigen Problemen zu stellen.

Respekt: Die Teammitglieder gehen respektvoll, konstruktiv und sachlich miteinander um.

Scrum basiert auf den drei Säulen: Transparenz, Inspektion und Anpassung.
Zunächst versuchen wir transparent zu machen, woran und wie wir arbeiten. Anschließend werden die Arbeitsweisen und Erzeugnisse regelmäßig überprüft und ggf. angepasst.

Scrum beruht darauf, dass die Entscheidungen von den handelnden Personen getroffen werden. Die Verantwortung wird somit zu einem großen Teil an das Team übertragen. Dies setzt voraus, dass das Team auch mit entsprechenden Handlungsbefugnissen ausgestattet ist. Somit verändert sich die Arbeitsweise von einem rein ausführenden zu einem selbstorganisierten Team. Neben der damit verbundenen Steigerung der Zufriedenheit der Mitarbeiter, bringt Scrum auch den Vorteil von kürzeren Feedbackzyklen und schnellere Anpassungen an notwendige Veränderungen. Hierdurch kann beispielsweise besser auf sich verändernde Kundenwünsche eingegangen werden.

Der Scrum Master sorgt dafür, dass das System vor äußeren Einflüssen geschützt wird. Er trägt die Prozessverantwortung und steht sowohl dem Scrum Team, als auch sämtlichen Stakeholdern als Ansprechpartner in administrativen Prozessfragen zur Verfügung. Darüber hinaus moderiert er in der Regel die Scrum Rituale. Als Servant Leader richtet er seine Tätigkeiten an den Wünschen und Bedürfnissen seines Teams aus.

Der Product Owner repräsentiert die Interessen der Kunden und Stakeholder an das Projekt. Er ist Hauptverantwortlich für das Produkt und dessen Erfolg. Er sorgt für die Definition der fachlichen Anforderungen aus Kundensicht und priorisiert sie in der Reihenfolge ihres Geschäftswerts. Hierbei ist es wichtig, dass der Product Owner sich auch eng mit den Entwickler austauscht, um ein gemeinsames Verständnis bei den Anforderung zu erzielen.

Die Entwickler sind für die Umsetzung der Anforderungen verantwortlich. Sie entscheiden über die umzusetzenden Anforderungen in dem jeweils kommenden Sprint und setzen diese entsprechend um.

Das Zertifikat dient als qualifizierter Nachweis der Weiterbildungsmaßnahme. Hiermit können Sie gegenüber Ihren Geschäftspartnern nachweisen, dass Sie die Inhalte verstanden und verinnerlicht haben, da das Bestehen einer Abschlussprüfung Voraussetzung für den Erhalt des Zertifikats ist.

Am Markt existieren zahlreiche Zertifizierungsstellen für Scrum, die teilweise National oder International gefragt und anerkannt sind. Als lizensierter Trainingsanbieter sind unsere Unterlagen so konzipiert, dass Sie diese auf die Prüfungen der ICO, des TÜV Süd und der Scrum.Org bestens vorbereiten. Gerne unterstützen wir Sie bei der Auswahl der passenden Zertifizierungsstelle.

Die Rolle des Projektleiters ist in Scrum nicht vorgesehen. Jedoch gibt es zahlreiche Projekte, die die Vorteile von Scrum und klassischem Wasserfallmodell vereinen. Hier kann neben den Rollen des Scrum Teams auch die Rolle des Projektleiters vergeben werden. Es besteht aber dadurch oft die Gefahr, dass durch die Rolle des Projektleiters im herkömmlichen Sinne die Selbstorganisation des Scrum Teams in Mitleidenschaft gezogen werden kann.

Ja, Scrum kann auch in Festpreisprojekten eingesetzt werden. Dies kann aber dazu führen, dass wichtige neue Anforderungen zu Gunsten des Festpreises nicht im Projekt umgesetzt werden. Ggf. hat man sich aber bei der Vertragsgestaltung die Möglichkeit offen gelassen, bestehende Anforderungen durch die neuen und nützlicheren Anforderungen zu ersetzen.

Die Einführung von Scrum bedeutet in der Regeln einen Wandel in der Unternehmenskultur. Dieser Wandel muss vom Unternehmesmanagement sichtbar unterstützt werden. Die Auswirkungen dieser Veränderung beschränken sich nicht nur auf das einzelne Scrum Team, sondern betreffen in der Regel sämtliche Abteilungen im Unternehmen. Beispiel: HR (neue Einstellungskriterien und Karrierepfade), Beispiel: Sales (Verkaufsargumente zu Scrum)

Die Einführung von Scrum kann selbst als Scrum Projekt gemanaged werden. Zunächst sollte das Bewusstsein für die Probleme geschaffen werden, die zu einer Scrum Einführung geführt haben. Im Rahmen eines Pilotprojekts sollte das Framework auf Eignung geprüft werden. Die hieraus gewonnenen Erkenntnisse sollten bei der unternehmensweiten Einführung Berücksichtigung finden. Positives Projektmarketing – bestenfalls durch einen Sponsor aus dem Management – ist unerlässlich für die Akzeptanz innerhalb der Belegschafft.

Hierfür reicht der Platz auf unserer Webseite nicht aus. Diese wie auch weitere Fragen beantworten wir Ihnen aber gerne im Rahmen unseres Seminars.

Nachdem Scrum in ausgewählten Bereichen Ihres Unternehmens eingeführt wurde, sollte überprüft werden inwieweit eine Ausweitung der Einführung in weitere Unternehmensbereiche sinnvoll ist. Dabei ist es besonders wichtig, dass das Stakeholdermanagement nicht zu kurz kommt und die Betroffenen zu Beteiligten gemacht werden, um eine breite Akzeptanz zu erzielen. Für das Unternehmensmanagement ergeben sich nach der Einführung auch Veränderungen, da die “alten” Mechanismen zur Unternehmenssteuerung für die nach Scrum arbeitenden Abteilungen auf den Prüfstand gestellt werden müssen.

Dem Wasserfallmodell und den agilen Methoden wie Scrum oder Kanban liegen grundlegend unterschiedlichen Ansätzen zu Grunde. Bevor man also sich dazu entschließt beide “Welten” zu verschmelzen, sollte man sich darüber im klaren sein, welche Vor- und Nachteile ein hybrides Projektmodell mit sich bringt. Besondere Herausforderungen liegen hier bei den Themen: Selbstorganisation vs. Weisungsgetriebene Arbeit, Selfreporting durch Scrum Boards vs. Projektstatusreporting & iterativ/inkrementelles Arbeiten vs. sequentielles Arbeiten.
Tatsächlich sind hybride Modelle inzwischen sehr häufig anzutreffen, jedoch sollte man dieses Projektmodell nur wählen, wenn man sich sowohl im Wasserfallmodell, wie auch in agilem Projektmanagement sehr gut auskennt. Ansonsten sind Konflikte zwischen den beiden Lagern vorprogrammiert. Ein erfahrener Projektmanagement Coach könnte hier bei der Implementierung einer hybriden Projektorganisation unterstützen.

Es ist natürlich möglich in Ihren Projekten mehrere Scrum Teams zu haben, die gemeinsam ein Produkt entwickeln. Ideal wäre es, wenn sich die Teams auf einen gemeinsamen Sprintzyklus einigen können. Bei Abhängigkeiten zwischen den Teams kann eine teamübergreifende Kommuniklation über das Scrum-of-Scrums sichergestellt werden. Darüber hinaus bietet dieser Termin auch die Möglichkeit von den anderen Scrum Teams zu lernen. Das Scrum-of-Scrums wird aus Teammitgliedern aus verschiedenen Scrum Teams gebildet und wird ähnlich wie das Daily Scrum – aber bspw. wöchentlich oder monatlich – abgehalten. Ggf. ist es sinnvoll ein Skalierungsframework wie bspw. Nexus, LeSS oder SAFe zu nutzen.

Scrum eignet sich für Projekte mit einem hohen Maß an Unsicherheit bei Projektbeginn oder einer hohen Komplexität. Die Unsicherheit und Komplexität wird durch das iterativ-inkrementelle Arbeiten und dem schnellen Kundenfeedback nach und nach aufgelöst. Bei Projekten mit geringer Unsicherheit und klaren Anforderungen, die sich über den Projektverlauf kaum oder nicht ändern sollten, kann das Wasserfallmodell die bessere Wahl sein.