Scrum – Die Tools der LMIS

Unsere LMIS AG entwickelt individuelle Software und realisiert so anspruchsvolle IT-Lösungen mit unseren hocheffizienten Teams. Als Vorgehensmodell bei unseren Projekten nutzen wir die Scrum-Methode. Dieses agile Entwicklungsverfahren setzen wir bereits seit vielen Jahren erfolgreich ein. Wie Scrum bei uns in der Praxis funktioniert, welche Termine und Rollen es gibt und welche Tools wir in der Scrum-Entwicklung nutzen, erläutern wir mit diesem Artikel genauer.

Was ist Scrum?

„Scrum“ ist ein englischer Begriff und bedeutet frei übersetzt „Gedränge“. Es handelt sich dabei um ein Vorgehensmodell des Projekt- und Produktmanagements, das insbesondere in der agilen Softwareentwicklung genutzt wird. Ursprünglich wurde es für die Softwaretechnik entwickelt, ist aber grundsätzlich unabhängig davon einsetzbar. Aus diesem Grund wird Scrum mittlerweile auch in vielen anderen Bereichen eingesetzt.

In unserer LMIS ist jedes Scrum-Teammitglied sein eigener Manager. Er oder sie organisiert sich selbstständig und ist gleichermaßen wichtig für das jeweilige IT-Projekt. Darüber hinaus ist jedes Teammitglied verantwortlich für den erfolgreichen Verlauf unseres gemeinsamen Vorhabens.

Agiles Mindset

Der Begriff „Mindset“ steht für eine Geisteshaltung oder Denkweise. Dieses Mindset ist im agilen Manifest definiert. Es besteht aus einer Präambel, gefolgt von vier Wertaussagen:
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte wie folgt schätzen gelernt:

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Scrum: Die Rollen

Die einzelnen Rollen in der Scrum-Methode sind:

  • Der Product Owner
    Der Product Owner erstellt und vermittelt die Vision des Produktes. Er maximiert den Wert des Produktes, indem er alle fachlichen Fragen zu dem Produkt beantworten kann und die Wertschöpfung kennt und optimiert.Nur der Product Owner ist letztendlich für das Product Backlog zuständig und trägt die Verantwortung für klar definierte und priorisierte Backlog Items. Zudem ist er der Hauptansprechpartner für die Stakeholder.
  •  Der Scrum Master
    Der Scrum Master ist der Servant-Leader für das Scrum Team. Eine seiner größten Aufgaben ist das Coaching des Entwicklungsteams in der Selbstorganisation. Dies bedeutet, das Team zu unterstützen in seiner Arbeit autonomer zu werden. Um die Arbeit des Scrum Teams zu erleichtern, beseitigt er die Hindernisse und hilft unserer LMIS bei der Umsetzung von Scrum. Unsere Scrum Master stimmen sich ständig gegenseitig ab. Sie arbeiten eng zusammen und tauschen ihre Erfahrungen aus.
  •  Das Entwicklungsteam
    Die Aufgaben des Entwicklungsteams variieren und richten sich größtenteils nach der „Definition of Done“. Das Entwicklungsteam arbeitet autark und besitzt alle Ressourcen um ein potentiell lieferbares Inkrement in einem Sprint zu entwickeln. Der Scrum Master betreut und unterstützt das Entwicklungsteam.

Für uns ist es sehr wichtig, dass die einzelnen Rollen im Scrum ernst- und die einzelnen Aufgaben von den Beteiligten wahrgenommen werden.

Das gesamte Scrum Team hat ein gemeinsames Ziel: Erfolgreich im Projekt zu sein. Dadurch werden wir als LMIS erfolgreich.

Scrum: Die Meetings

Im Allgemeinen gilt für alle Scrum-Meetings, dass bestimmte Timeboxen einzuhalten sind. Die Meetings werden frühzeitig vorbereitet. Die Teilnehmer werden rechtzeitig eingeladen. Außerdem ist das Ziel des Meetings klar definiert. So kann sich jeder Teilnehmer darauf vorbereiten.

Sprintplanung

Organisator:  Scrum Master

Teilnehmer: Entwicklungsteam, Scrum Master, Product Owner, (optional Stakeholder)

Dauer: Max. 8 Stunden für einen einmonatigen Sprint. (Planning I vormittags, Planning II nachmittags.)

Wann: Am Anfang des Sprints

Planning I

Ziel: Das „WAS“ klären

Planning II

Ziel: Das „Wie“ klären

Mit Hilfe des ersten Plannings werden die Aufgaben für den kommenden Sprint genau analysiert, so dass am Ende des Meetings klar ist, was der Kunde funktional umgesetzt haben möchte. Das Team kann so entscheiden, was genau in diesem Sprint geliefert werden kann. Das erste Planning ist ein wesentlicher Teil des Sprints. Dabei werden die Anforderungen mit Hilfe des Product Owners genauer analysiert. Ausgangslage für das erste Planning ist ein bereits vorbereitetes und priorisiertes Product Backlog. Die Prioritäten werden von dem Product Owner zusammen mit den Kunden festgelegt, so dass klar ist, welche funktionalen Aspekte den höchsten (Business-) Mehrwert bringen. Das Meeting sollte gegen Vormittag stattfinden, so dass das zweite Planning nahtlos angeschlossen werden kann.

Während des ersten Meetings stellt das Entwicklungsteam dem Product Owner aktiv Fragen um alle fachlichen Unklarheiten zu beseitigen.

Das zweite Planning dient der ersten, technischen, Lösungsfindung für die im ersten Planning definierten Features. Am Ende des zweiten Plannings sollte klar sein, wie die entsprechenden Funktionen umgesetzt werden. Im Rahmen des zweiten Plannings trifft sich das Team zusammen mit dem Scrum Master um den zuvor im ersten Planning festgelegten Umfang festzulegen und abzuschätzen. Dabei werden alle weitere Teilnehmer des Teams nicht mehr benötigt, können aber beratend konsultiert werden. Innerhalb des Plannings wird beispielsweise festgelegt, welche Schnittstellen geschrieben werden müssen, welche Datenbanken angesprochen werden oder wo sich das Feature in die bereits bestehende Anwendung integriert.

Anhand der ergebnisorientierten Diskussion des Entwicklungsteams werden die User Stories geschätzt. Die Schätzung wird mit Hilfe von verschiedenen Tools z.B. dem Planning Poker durchgeführt.

LMIS Planing Poker Karten

Daily Scrum

Organisator: Scrum Master

Teilnehmer: Entwicklungsteam (Optional Scrum Master und Product Owner)

Dauer: täglich max. 15 Minuten.

Wann: täglich

Ziel: Informationsaustausch von Entwicklungsteam untereinander.

Dieses Meeting gibt einen Überblick darüber, WER WAS tut. Dabei sollen diese Fragen beantwortet werden:

  1. Woran habe ich gestern (Tag vor dem heutigen Daily Scrum) gearbeitet?
  2. Womit beschäftige ich mich heute?
  3. Was behindert mich von meiner Arbeit?

Zur Unterstützung dieses Termins benutzen wir spezielle Scrum-Kärtchen:

Wichtig beim Daily Scrum: Dieser Termin stellt keine Fragerunde dar. Ebenfalls gibt es keine Statusberichte aus dem Team. Ein Daily Scrum wird in der Regel sehr locker gestaltet.

Sprint Review

Organisator: Product Owner

Teilnehmer: Product Owner, Stakeholder, (optional Entwicklungsteam)

Dauer: 4 Stunden für einen einmonatigen Sprint

Wann: Am Ende des Sprints

Ziel: Überprüfung des vergangenen Sprints und Bearbeitung des Product Backlogs bei Bedarf.
Das Sprint Review gewährleistet dem Kunden einen Blick auf das im Sprint entstandene Artefakt. Dabei werden gemeinsam Anpassungen, Fehler oder Verbesserungen identifiziert um das Produkt noch besser zu gestalten.

Das Sprint Review soll allen beteiligten Teilnehmern, also dem Entwicklungsteam, dem Scrum Master, dem Product Owner und dem Kunden, die Möglichkeit geben, alle neuen Funktionen auszuprobieren und das neue Artefakt zu testen. Das Ziel des Reviews ist, dass das Feedback vom Kunden, idealerweise auch von den End Usern, eingeholt und dokumentiert wird. Dabei können sowohl Punkte für das Backlog des Teams, als auch neue Anforderungen dokumentiert werden. Damit das Meeting zielgerichtet bleibt, wird am Anfang das Sprintziel an die Teilnehmer kommuniziert, so dass der Fokus auf die entsprechenden Funktionen gerichtet bleibt. Alle dabei präsentierten Funktionen müssen der gemeinsam erarbeiteten Definition of Done entsprechen, so dass ausschließlich potentiell auslieferbare Funktionen präsentiert werden. Kunden- bzw. Teamfeedback wird gesammelt und dokumentiert.

Definition Of Done

Aufgaben werden nur dann im Review gezeigt und am Ende des Sprints als fertig gewertet, wenn sie der eigenen Definition of Done entsprechen.

Nicht vollständig abgeschlossene Aufgaben werden in den nächsten Sprint verschoben.
Eine Aufgabe kann, im Sinne der Definition of Done, als fertig gewertet werden, wenn …
… die Aufgabe getestet wurde (programmatische und manuelle Tests).
… die abgeschlossene Aufgabe dem Kunden präsentiert werden könnte.
… die Aufgabe durch jemanden überprüft wurde (im Sinne eines Reviews).
… die Aufgabe dokumentiert ist.
… der Quellcode keine TODOs oder FIXMEs enthält.
… der Quellcode erfolgreich gepusht wurde.
… der Commit den Build nicht bricht.

Retrospektive

Organisator: Scrum Master

Teilnehmer: Product Owner, Entwicklungsteam, Scrum Master

Dauer: Max. 3 Stunden für einen einmonatigen Sprint

Wann: Am Ende des Sprints, nach Sprint Review

Ziel: Besprechung des Ablaufs des Sprints und Definition der effektiven Maßnahmen für die Verbesserung des Prozesses.

Die Retrospektive ist Teil einer jeden Iteration und dient der Etablierung eines kontinuierlichen Verbesserungsprozesses und der Stabilisierung der Zusammenarbeit des Teams.

Für dieses Meeting gibt es verschiedene Vorgehensweisen. Wichtig ist, dass das Scrum Team aus der Vergangenheit für die Zukunft lernt und die eigene Produktivität verbessert.

Primäres Ziel ist die Verbesserung der Produktivität, sowie die Verbesserung der Zusammenarbeit innerhalb des Teams. Dabei ist wichtig, dass nicht alle Teilnehmer des normalen Entwicklungsprozesses anwesend sein müssen. Zwingend erforderlich ist nur das Entwicklungsteam, sowie der Scrum Master. Hinderlich sind an dieser Stelle disziplinarische Vorgesetzte, da in einem solchen Fall nur selten unbedacht gesprochen wird. Im Rahmen der Retrospektive werden explizit nicht die Ergebnisse beurteilt, sondern nur die Zusammenarbeit innerhalb des Teams. Erkenntnisse des Meetings sollten nicht unbedarft nach außen getragen werden, Verbesserungen sollten direkt in das entsprechende Backlog einfließen.

 

Weitere wichtige Tools unserer LMIS

Die Bla Bla Karten: Können in rot oder gelb vom Scrum Master vergeben werden, wenn in Meetings (Sprintplanung oder Daily Scrum) ein Teilnehmer vom eigentlichen Thema abweicht.

Weitere Informationen: https://www.scrum.org/Resources/Scrum-Glossary

 

 

LMIS AG Softwareenwicklung IT Osnabrueck Hasehaus Hauptsitz Über die LMIS AG

Die LMIS AG ist seit dem Jahr 2000 zu einem professionellen IT-Dienstleister herangewachsen und bietet mit seinen rund 80 Mitarbeitern an den Standorten Osnabrück, Berlin, Wuppertal und Friedland (M-V) maßgeschneiderte IT-Lösungen, die auch noch nach Jahren ideal wachsenden und sich verändernden Anforderungen angepasst werden können.

Weitere Informationen zu unserer LMIS AG