Scrum im Einsatz mit mehreren Entwicklungsteams

Abhängig von Projektumfang, Umsetzungsfrist und weiteren Rahmenbedingungen wird der Umfang eines Scrum-Entwicklungsteams dimensioniert. Dabei muss insbesondere darauf geachtet werden, dass das Team so zusammengesetzt wird, dass es gemeinsam in der Lage ist, alle Anforderungen zu realisieren. Zugleich ist darauf zu achten, dass das Team einfach zusammenarbeiten kann und nicht zu gross ist, um sich einfach abzustimmen. Untersuchungen haben gezeigt, dass grössere Teams tendenziell mehr Zeit durch einen höheren internen Abstimmungsbedarf verlieren und dadurch eine geringere Produktivität pro Teammitglied aufweisen. Entsprechend ist die Teamgrösse in Scrum auf 3-9 Teammitglieder limitiert. Werden für die Umsetzung eines Projektes mehr als neun Entwicklungsressourcen benötigt, so werden diese auf mehrere Teams aufgeteilt, welche alle Aufgaben aus demselben Produkt Backlog umsetzen. (Pro Produkt existiert immer nur ein Produkt- Backlog, unabhängig davon, wie viele Personen daran arbeiten.) Weiterlesen „Scrum im Einsatz mit mehreren Entwicklungsteams“

Monitoring

Oft wird das Thema «Monitoring» in einem falschen Kontext gesehen und teils auch falsch übersetzt. Es geht dabei nicht um Überwachung, sondern um Transparenz. In einer Form der Zusammenarbeit, bei der kein externer Leader die Umsetzung eines Produktes steuert, sondern ein Team sich selbst organisiert, ist es ein zentrales Erfolgselement, bei dem die beteiligten Rollen wissen, wo sie und ihre Kollegen stehen und wie die aktuelle Situation ist. Dabei sollte stets gelten: Jede Art des Monitorings ist nur dann sinnvoll, wenn sie dem Team (oder Teilen des Teams) hilft, ihre Arbeit besser zu machen und damit zum Gesamterfolg beizutragen. Wo dies nicht der Fall ist, sollte die Sinnhaftigkeit überprüft werden. Weiterlesen „Monitoring“

Schätzungen in Scrum

Das Schätzen von Anforderungen ist ein Kernthema agiler Entwicklung. Auf ihr basiert die gesamte Ablaufplanung. Anders als in herkömmlichen Techniken ist dabei das Schätzen ein fortlaufender Prozess, der parallel zum Entwicklungsprozess durchgeführt wird und bei dem einmal geschätzte Anforderungen auch mehrfach geschätzt werden, da sich basierend auf Kundenfeedback, aber auch auf den selbst gewonnenen Erkenntnissen während des Entwicklungsprozesses neue Gesichtspunkte ergeben können, die die Aufwandsschätzungen beeinflussen können. Weiterlesen „Schätzungen in Scrum“

Agile Planung

Planning Onion (die Planungs-Zwiebel)

Planung findet im Geschäftskontext auf ganz unterschiedlichen Ebenen statt. Sie reicht von der Ebene strategischer Planung bis hinunter zur Tagesplanung. Dabei ist von zentraler Bedeutung, dass Planung auf jeder Ebene immer mit jener auf den darüberliegenden Ebenen vereinbar ist. So wird eine Firma keine Produkte entwickeln, welche ihrer Unternehmensstrategie zuwiderlaufen. Dieses Prinzip der Planung auf verschiedenen Ebenen wird oft auch in einem zwiebelförmigen Schalenmodell dargestellt. Die Schale strategischer Planung umschliesst die darunterliegenden, welche im agilen Kontext oft mit Portfolio, Produkt, Release, Sprint (oder Iteration) und Tag überschrieben werden. Weiterlesen „Agile Planung“

Definition of Done

Die «Definition of Done» ist ein Teil der Qualitätssicherung in Scrum. Sie beschreibt die für alle Entwicklungspakete verbindlichen Qualitätsrichtlinien, wird vom Scrum-Team gemeinsam definiert und gilt ausnahmslos für alle umgesetzten Product Backlog Items. Weiterlesen „Definition of Done“

Sprint-Backlog

Der Sprint-Backlog wird jeweils im Sprint-Planungsmeeting vom Entwicklerteam erstellt. Er umfasst die für den Sprint geplanten Produkt-Backlog-Items sowie die Einzelaufgaben (Tasks), welche das Entwicklerteam zu deren Realisierung identifiziert hat. Idealerweise sollten Tasks in maximal einem Tag umsetzbar sein. Weiterlesen „Sprint-Backlog“

Der Product Backlog und die Features

Der Product Backlog

Der Product Backlog kann als ein Speicher für die Anforderungen (Features), aber auch alle anderen im Verlaufe der Projektentwicklung angedachten Aufgabenstellungen gesehen werden. Sein Inhalt wird vom Product Owner in Abstimmung mit dem Kunden erstellt. Dies geschieht oft im Rahmen eines Workshops, kann aber auch basierend auf bestehenden Anforderungsdokumenten (Lastenhefte, Anforderungskataloge etc.) geschehen, wobei es in jedem Fall ausschlaggebend für den Projekterfolg ist, dass Anforderungen mit dem Kunden besprochen und geklärt werden. Für eine erfolgreiche Umsetzung ist es wichtig, mit dem Kunden gemeinsam Umfang und Inhalt von Anforderungen festzustellen und gemeinsam festzulegen, was der Kunde erwartet und was nicht. Weiterlesen „Der Product Backlog und die Features“

Events in Scrum

Neben den Rollen sind die Events (Ereignisse) ein zentrales strukturelles Element von Scrum. Es gibt fünf solche formellen Scrum Events: Weiterlesen „Events in Scrum“

Die Rollen in Scrum

Viele Menschen verknüpfen mit agilen Frameworks die Vorstellung, dass es keine Prozesse, Zuständigkeiten oder Verantwortungen und auch keine Pläne gebe. In ihrer Vorstellung bedeutet Agilität und agile Vorgehensweisen, dass jeder das macht, was er für richtig hält, und am Ende grossartige Produkte entstehen würden. Diese Vorstellung ist komplett falsch. Der Erfolg des agilen Vorgehens basiert zu einem guten Teil auf der Tatsache, dass Prozesse eingehalten werden und Rollen mit Aufgaben, Verantwortungen und Kompetenzen klar definiert sind. Weiterlesen „Die Rollen in Scrum“

Grundlagen und Philosophie von «Scrum»

Scrum Grundlagen

Scrum Definition (Scrum Guide, 2017):
Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.

Scrum ist:

  • leichtgewichtig
  • einfach zu verstehen
  • schwierig zu meistern

Weiterlesen „Grundlagen und Philosophie von «Scrum»“