Home > Allgemein, Entwicklung, Projektmanagement > Scrum (5) – in der Praxis

Scrum (5) – in der Praxis

Während ich in den Vorgängerartikeln zu Scrum hauptsächlich die Theorie rund um Scrum beschrieben habe, sind hier noch ein paar praktische Gesichtspunkte, die sich auf die verschiedenen Rollen in Scrum beziehen – und die auch in einem Nicht-Scrum-Umfeld Sinn machen.

Team

  • Ein häufiges Springen zwischen Projekten führt erwiesener Maßen zu Qualitäts- und Effizienzproblemen. Ein Team sollte deshalb im Rahmen eines Projektes nicht getrennt werden
  • Teams sollten nicht zu groß sein, da hierdurch vermehrter Kommunikations- und Abstimmungsaufwand entsteht
  • Mitarbeiter, die aufgrund ihres umfangreichen KnowHows in diversen Projekten unverzichtbar sind, erweisen sich häufig als Bottleneck. Sie sollten versuchen ihr Wissen mit anderen Kollegen zu teilen, so dass sie nicht zu häufig springen müssen. Paarweises Arbeiten kann hier sehr hilfreich sein.
  • Um möglichst effizient arbeiten zu können, sollten sich die Teammitglieder in fachlichen Fragen untereinander austauschen. Kein falscher Stolz an dieser Stelle, niemand ist perfekt!
  • Um die vereinbarten Ziele zu erreichen, ist es nicht zulässig Teammitglieder im laufenden Sprint zeitweise von einem Projekt abzuziehen. Falls dies im Ausnahmefall nötig ist, wird dies dem Product Owner mitgeteilt, so dass dieser die Ziele des Sprints anpassen kann.
  • Jedes Teammitglied verpflichtet sich im Scrum-Meeting bestimmte Aktivitäten im Rahmen des kommenden Sprints zu übernehmen. Das Teammitglied ist hierfür also verantwortlich und muss selbst sicherstellen, dass die Aktivitäten zum zugesagten Zeitpunkt fehlerfrei abgeschlossen sind. Wenn also noch Übersetzungstexte fehlen oder die Mithilfe eines anderen Teammitglieds notwendig ist, kümmert sich der zuständige Mitarbeiter selbst darum.

Product Owner in der Praxis

  • Bei einigen Projekten kann der Product Owner fast ausschließlich vom Kunden gestellt werden und benötigt nur leichte Unterstützung vom Auftragnehmer, da ausreichend technisches und wirschaftliches Know How vorhanden ist.
  • Bei anderen Kunden hingegen, sind oft nur vage Ideen vorhanden, die vom Auftragnehmer erst in eine Struktur gebracht werden müssen. In diesem Fall übernimmt ein Mitarbeiter des Auftragnehmers große Teile der Rolle des Product Owner. Der Kunde agiert in diesem Fall eher als Interessenvertreter, dessen Stimme großes Gewicht hat.

ScrumMaster

  • Der ScrumMaster entspricht häufig dem Projektleiter in traditionellen Unternehmen (das ist zwar nach der reinen Lehre nicht so gedacht, ist in der Praxis aber häufig so). Unter Umständen muss der ScrumMaster den ProductOwner stark unterstützen.
  • ScrumMaster an sich sollte kein Fulltime-Job für ein Projekt sein. Er soll das Team in dieser Rolle lediglich unterstützen und ihm den Rücken frei halten bzw. Hindernisse aus dem Weg räumen. Oft wird der Mitarbeiter neben seiner Rolle als ScrumMaster auch eine Rolle im Team ausfüllen (z. B. das Durchführen von Integrationstests).
blog comments powered by Disqus
  1. Bisher keine Kommentare
  1. Bisher keine Trackbacks
Du musst Dich anmelden um einen Kommentar zu schreiben

Switch to our mobile site