Wie agile Entwicklung mit der Scrum Methode funktioniert.

Bei BRICKMAKERS arbeiten wir agil. Agiles Arbeiten hat den Vorteil, dass man flexibel und proaktiv auf Veränderungen reagieren kann. Das langfristige Ziel ist hier grob bekannt, doch die Umsetzung wird in kleinere Intervalle, sogenannte Sprints, unterteilt und so Schritt für Schritt zurückgelegt. Das bringt die Freiheit mit sich, im Projekt flexibel auf Veränderungen zu reagieren.

Das funktioniert so: zwischen den einzelnen Sprints werden die Ergebnisse begutachtet und Anforderungen an das Produkt hinzugefügt, entfernt oder die bereits vorhandenen neu priorisiert. Dabei ist auch der Kunde anwesend und kann bereits sehr früh im Prozess Feedback geben. So entsteht im Arbeitsprozess eine weitreichende Transparenz. Außerdem können gemeinsam direkt Ideen für weitere Funktionen entwickelt werden. Ebenso sind eine hohe Nutzenmaximierung sowie funktionierende Software sichergestellt. In diesem Prozess gibt jedoch nicht nur der Kunde Feedback. Auch innerhalb des Teams geschieht dies regelmäßig. Aber wie sind solche Teams überhaupt aufgebaut?

Scrum

Trotz aller Flexibilität bewegen wir uns beim agilen Arbeiten in dem jeweiligen Rahmen eines Projekt- bzw. Produktmanagements. Dies ist bei BRICKMAKERS je nach Projekt SAFe, Kanban oder Scrum. Anhand von Scrum möchten wir Ihnen hier kurz die Rollen in diesem Framework agilen Arbeitens näherbringen, um Ihnen einen besseren Einblick über Zuständigkeiten und Arbeitsablauf zu geben.

Das Scrum Team

Das Scrum-Team besteht aus dem Product Owner, dem Scrum Master sowie dem Development Team. Das Development Team ist crossfunktional aufgestellt. Es kann demnach alle Aufgaben vom Design bis zum Betrieb selbst durchführen.

Product Owner Entwicklungsteam Scrum Master

Product Owner

Der Product Owner legt gemeinsam mit dem Kunden die Anforderungen fest und behält diese sowie das Ziel des Projekts im Blick. Dabei achtet er vorrangig auf die Kundenwünsche und -bedürfnisse. Er ist also verantwortlich dafür, dass das Produkt die Ansprüche des Kunden erfüllt und es marktfähig ist. Der Product Owner fungiert hierbei jedoch nicht als Vorgesetzter, sondern ist ein gleichwertiges Mitglied im Team.

Scrum Master

Der Scrum Master ist, wie der Name schon sagt, Experte für die Abläufe von Scrum. Dabei ist er nicht direkt an der Entstehung des Produkts beteiligt, doch er sorgt im Team für den ungehinderten Ablauf der Prozesse durch die Beseitigung von Hindernissen sowie einen stetigen Kommunikationsfluss innerhalb des Teams. Er fungiert hierbei als Servant Leader und Moderator des Verfahrens.

Development Team

Mit „Development Team“ werden meist die Parteien bezeichnet, die die Umsetzung des Projekts in Angriff nehmen. Das Development Team bespricht vor jedem Sprint gemeinsam mit dem Product Owner sowie dem Scrum Master, welche Elemente im nächsten Sprint umgesetzt werden sollen. Während eines Sprints organisiert sich das Team selbst. Normalerweise bestehen diese Teams aus 3 bis 9 Personen.

Weitere Rollen

Es gibt noch weitere Rollen, die Interesse an der Entwicklung des Produkts haben, allen voran die Stakeholder. Das können beispielsweise Kunden, das Management oder sogar die Anwender sein. Diese nehmen zwar Einfluss auf das Produkt, sind jedoch nicht direkt an der Umsetzung beteiligt.

Der Scrumprozess

Product Backlog
Retrospektive
Planning
Review
Sprint
Increment
  • Rückblick des letzten Sprints
  • Verbesserung der zukünftigen Zusammenarbeit
  • Werkzeuge, Prozesse und Fähigkeiten werden reflektiert
  • Gemeinsam wird ein Scope für den nächsten Sprint festgelegt
  • Ein Sprintziel wird entworfen
  • Das Team plant, wie die Anforderungen umgesetzt werden
  • Produktfunktionalität wird dem Product Owner und den Stakeholdern präsentiert
  • Erzeugt Transparenz und direktes Feedback
  • Ideen für weitere Funktionen werden gemeinsam entwickelt
Daily
Scrum
Planning
  • Gemeinsam wird ein Scope für den nächsten Sprint festgelegt
  • Ein Sprintziel wird entworfen
  • Das Team plant, wie die Anforderungen umgesetzt werden
Sprint
Daily Scrum
Review
  • Produktfunktionalität wird dem Product Owner und den Stakeholdern präsentiert
  • Erzeugt Transparenz und direktes Feedback
  • Ideen für weitere Funktionen werden gemeinsam entwickelt
Retrospektive
  • Rückblick des letzten Sprints
  • Verbesserung der zukünftigen Zusammenarbeit
  • Werkzeuge, Prozesse und Fähigkeiten werden reflektiert