Tag Archives: scrum

Scrum und Kanban in der Praxis

Dieser Artikel erzählt einige Episoden aus dem Alltag eines „überwiegend“ fiktiven Scrum-Teams, den üblichen Anforderungen, Problemen und Erfolgen. Der Autor ist derzeit Entwickler und Scrummaster in einem agilen Team.

Das Scrum-Team, das wir die nächsten paar Tage begleiten besteht aus Karl, Markus und Georg (Java-Entwickler) sowie Hans (Tester) und Arne (Scrummaster).
Das Team entwickelt einen Online-Shop und arbeitet mit Scrum.
Scrum ist wahrscheinlich die bekannteste agile Vorgehensweise und erlaubt es, Produkte inkrementell in kleinen Schritten zu entwickeln.
Das Team arbeitet in Sprints, die üblicherweise eine Länge von zwei Wochen haben. Das Team vereinbart mit dem Kunden (den wir gleich kennenlernen werden), was am Ende jedes Sprints geliefert werden soll. Geliefert werden die mit dem Kunden vereinbarten Teilfunktionalitäten, diese aber tatsächlich fertig. Das bedeutet für unser Team – Unit-Tests vorhanden, Peer Review durchgeführt, dokumentiert, Acceptance Test auf definierter Testumgebung durchgeführt und jeder im Team ist so zufrieden mit der durchgeführten Arbeit, dass man sie sich am liebsten zu Hause an den Kühlschrank pinnen möchte.

Der erste und wichtigste Termin des Tages jedes Scrum-Teams ist das Daily Scrum.

10:30 – Das wichtigste Meeting des Tages

Das wichtigste Meeting des Teams ist das Daily Scrum. Das Daily Scrum dauert höchstens 15 Minuten und startet pünktlich um 10:30. Zu diesem Zeitpunkt sind auch die nachtaktiven Teammitglieder ausgeschlafen und können erste klare Gedanken fassen.
Das Daily Scrum ist deshalb so wichtig für das Team, weil es diese 15 Minuten nutzt, um sich für den Tag zu synchronisieren.

Heute startet das Daily Scrum mit Karl.

Karl erzählt, dass er seit gestern an einem Feature zur Validierung von Kundendaten im Frontend  des Online-Shops gearbeitet hat.
Das beantwortet Frage 1: Was habe ich seit gestern geschafft?
Anschließend erzählt Karl, dass er dieses Feature gerne zusammen mit Hans dem Tester auf eine Testumgebung deployen und ausführlich testen möchte.
Das beantwortet Frage 2: Was möchte ich heute machen?
Zuletzt erzählt Karl, dass er dringend auf eine Zulieferung aus der Grafikabteilung wartet um die Validerungsfehler im Frontend korrekt darstellen zu können.
Bis die Grafikabteilung die fehlenden Stylesheets liefert kann Karl das Feature nicht abschließen.
Damit beantwortet Karl Frage 3: Was behindert mich aktuell?
Als Karl die dritte Frage beantwortet, wird sofort Arne der Scrummaster hellhörig, denn genau das ist die Aufgabe und der Job eines Scrummasters. Der Scrummaster löst Probleme. Er sorgt dafür, dass das Team zu jedem Zeitpunkt  produktiv arbeiten kann.
Was wird Arne also machen? Er wird direkt nach dem Daily Scrum der Grafikabteilung ein paar Büros weiter einen Besuch abstatten (er wird nach Möglichkeit nicht anrufen und auch keine E-Mail schreiben) und versuchen, die dringend benötigte Lieferung irgendwie zu beschleunigen.

Diese 15 Minuten sind unglaublich wichtig für das Team, weil so sichergestellt ist, dass jeder zumindest grob die Aufgaben der anderen Teammitglieder kennt und der Fortschritt des Projektes täglich besprochen wird.

Das wichtigste Werkzeug

Wir haben das wichtigste Meeting eines Scrum-Teams kennengelernt, jetzt werden wir das wichtigste Werkzeug kennenlernen – das Board.

Abbildung 1: Das Board

Das Board visualisiert die Arbeit des Teams. Am Board ist jederzeit für jeden (auch beispielsweise für den Kunden) ersichtlich, welche Features aktuell umgesetzt werden, welches Features bereits abgeschlossen sind und was noch für den restlichen Sprint geplant ist.

Betrachten wir hierzu das Board des Teams ein wenig genauer.

Abbildung 2: Das Board des Teams

Das Board des Teams kann gar nicht groß genug sein. Es ist mehr als 4 Meter lang und bedeckt eine komplette Bürowand.
Es ist unterteilt in mehrere Spalten, die die einzelnen Schritte repräsentieren, die eine Anforderung bis zur Fertigstellung durchläuft.
Gibt der Kunde eine neue Anforderung in das Team, landet diese zunächst als Post-It Zettel in der TODO-Spalte (Abb. 3). Üblichweise verbraucht ein Scrum-Team Unmengen von Post-Its.

Abbildung 3: Anforderungen auf dem Board

Die TODO-Spalte wird vom Kunden priorisiert. Je weiter oben sich eine Anforderung in der TODO-Spalte befindet, desto wichtiger ist dem Kunden die Umsetzung und desto früher wird die Anforderung vom Team bearbeitet.
Sobald sich das Team entscheidet, eine neue Anforderung in Bearbeitung zu nehmen, wandert die diese aus der TODO- in die DEV-Spalte.

Damit ist sofort ersichtlich, dass aktuell an dieser Anforderung gearbeitet wird. Ist die Entwicklung abgeschlossen, wandert die Anforderung weiter in die QS-Spalte. Die QS-Spalte ist ein Entwicklungsschritt, der vom Team definiert wurde um die Qualität zu verbessern. Eine Anforderung in dieser Spalte ist bereits fertig entwickelt und wird nochmals von einem Entwickler überprüft, der nicht an der Umsetzung beteiligt war.
Irgendwann ist auch dieser Entwickler zufrieden und die Anforderung wandert erneut eine Spalte weiter in die TEST-Spalte. Hier wird Hans der Tester aktiv und testet die Anforderungen gegen die Akzeptanzkriterien des Kunden.
Ist Hans zufrieden gibt auch dieser grünes Licht und die Anforderung wandert wieder einen Schritt weiter in die DEPLOYMENT-Spalte.
Eine Anforderung in dieser Spalte ist fertig implementiert, vom Kunden abgenommen und auf dem Weg in das Produktiv-System.
Dieser Schritt wird leider nicht direkt vom Team selbst durchgeführt, sondern von einer externen Abteilung, die aber im gleichen Gebäude ist. Das bedeutet aber keinesfalls, dass das Team aus der Pflicht genommen wird, ein schnellstmögliches Deployment sicherzustellen.
Das Team unterstützt das Deployment und fordert ständig Informationen zum aktuellen Status ein.
Erst dann, wenn die Anforderung komplett umgesetzt, gereviewed und getestet ist und im Livesystem von echten Kunden verwendet wird, wandert die Anforderung in die DONE-Spalte und ist somit abgeschlossen.

Abbildung 4: Anforderungen wandern auf dem Board von links nach rechts

Der Kunde

Wir haben bereits öfter vom „Kunden“ gesprochen. Wer ist nun dieser Kunde?
Das Team arbeitet für den Product-Owner. Der Product-Owner des Teams ist Henning.  Henning war früher Projektmanager und ist heute Product-Owner mit Leib und Seele.
Henning entwickelt die Vision des Produktes. Er weiß genau, was vom Team wann umgesetzt werden muss, um den Online-Shop zum Erfolg zu führen. Er definiert die Anforderungen, die er dem Team übergibt.
Wie sieht jetzt eine typische Anforderung Scrum aus?
Eine Anforderung in Scrum wird User-Story genannt. Eine User-Story hat idealerweise die folgende Form:

Als X möchte ich Y um Z.

Das beantwortet die drei wichtigsten Fragen, die das Team braucht, um eine Anforderung umzusetzen.

Wer möchte etwas haben?
Was möchte derjenige haben?
Warum wird diese Funktionalität gebraucht?

Ein Beispiel für eine ausformulierte User-Story ist in Abb. 5 zu sehen. Dieser eine Satz genügt einem gut eingespielten Scrum-Team um eine Anforderung umzusetzen. Alle weiteren Fragen werden in separaten Planungs-Meetings geklärt.

Abbildung 5: Eine typische User-Story

Ein neuer Tag, ein neuer Sprint

Überspringen wir einige Tage. Das Team hat den laufenden Sprint abgeschlossen und sowohl Henning als auch das Team sind sehr zufrieden mit dem aktuellen Status des Projektes.
Für den neuen Sprint ist das Sprint-Backlog (die TODO-Spalte) gut gefüllt (ähnlich Abb. 3).
Das Team ist hochmotiviert und beginnt direkt mit der Arbeit und den ersten Stories, die auch direkt in die DEV-Spalte wandern.
Karl übernimmt Anforderung A („Als Kunde möchte ich meine Kundendaten ändern, um nach einem Umzug trotzdem Bestellungen an die richtige Adresse geliefert zu bekommen“), Markus Anforderung B („Als Kunde möchte ich alle Links im Online-Shop mit neuen Styles gerendert bekommen, damit ich diese besser finden kann.“).
Anforderung B ist von Markus sehr schnell umgesetzt und wandert weiter in die QS-Spalte, wo sie von Georg nochmals überprüft wird.
Markus nimmt inzwischen bereits die Anforderung C („Als Administrator möchte ich tägliche Reportings über eingegangene Bestellungen erhalten, um schnell auf Lagerengpässe reagieren zu können“) in Bearbeitung, denn er will keine Zeit verschwenden. Am Ende des ersten Tages ist auch Karl mit Anforderung A fertig, so dass sich auf dem Board das Bild aus Abb. 6 ergibt.

Abbildung 6: Das Scrum-Board in Aktion

Leider muss Markus sehr schnell feststellen, dass die Anforderung C nicht umgesetzt werden kann, da die Schnittstelle zur Anbindung an das Lagerhaltungssystem noch nicht bereit steht. Die Story ist also blockiert.
Markus weist Arne, den Scrummaster auf dieses Problem hin, markiert die blockierte Story auf dem Board mit einem roten Blitz und nimmt sofort die Anforderung D in Bearbeitung. Es ergibt sich das Bild aus Abb. 7.

Abbildung 7: Ein Problem zeichnet sich ab

Arne der Scrummaster betrachtet das Board und kann nur seinen Kopf schütteln.
Sein Bauchgefühl sagt ihm, dass zu viele Stories parallel in Bearbeitung sind.
Ein Scrum-Board dient zur Visualisierung der Arbeit des Teams. Die Stories auf dem Scrumboard verhalten sich wie Autos auf einer Autobahn. Eine Autobahn hat keinen anderen Zweck, als auf ihr möglichst schnell von Punkt A nach Punkt B zu gelangen.
Analog möchten die Stories auf dem Board möglichst schnell von der TODO- in die DONE-Spalte. Erst wenn ein Feature live ist und von echten Kunden verwendet wird, wird dadurch auch ein echter Wert für den Kunden, also für Henning geschaffen.
Was passiert auf einer Autobahn, wenn zu viele Autos gleichzeitig unterwegs sind? Es kommt zum Stau. Genau dasselbe geschieht auf dem Board. Sind zu viele Stories gleichzeitig in Bearbeitung werden die Stories dadurch nicht schneller, sondern viel langsamer abgeschlossen. Teammitglieder blockieren sich gegenseitig und die Reintegration von Features wird komplizierter (beispielsweise durch Konflikte beim Mergen von verschiedenen Änderungen).
Ein weiteres Problem das sofort jedem im Team auffällt: Hans der Tester legt bisher die Beine hoch und dreht Däumchen. Denn bisher hat es keine Story auch nur bis in die TEST-Spalte geschafft. Das Schlimmste, was Hans jetzt passieren kann ist, dass alle Anforderungen gleichzeitig fertiggestellt werden und sich das Bild in Abb. 8 ergibt.
Hans wird mit so viel Arbeit überhäuft, dass nun die TEST-Spalte das Board blockiert, und er keine weiteren Stories aufnehmen kann.
Und nach wie vor ist das Team weit davon entfernt, eine Story bis ins Live-System gebracht zu haben.

Der Scrummaster wird aktiv

Arne hat kürzlich ein Buch über Kanban gelesen. Kanban wird von vielen oft als Alternative zu Scrum verstanden. Arne aber versteht Kanban eher als ein Set von Spezialwerkzeugen, um die Produktivität des Teams zu steigern.
Eine erste Maßnahme, die Arne dem Team vorstellt ist das Messen der Lead-Time. Die Lead-Time ist eine hilfreiche Metrik, die sehr einfach zu erfassen ist und üblicherweise sehr schnell zu ersten „Aha-Momenten“ führt.
Das Team misst die Lead-Time für eine erste Story und das Ergebnis ist in Abb. 9 zu sehen.

Abbildung 9: Das Team misst die Lead-Time

Abbildung 9: Das Team misst die Lead-Time

Die Lead-Time bezeichnet die Zeit, die eine Story braucht, um von der TODO- bis in die DONE-Spalte zu gelangen. Sie wird gemessen, indem auf der jeweiligen Story am Board jedes Mal das Datum vermerkt wird, wenn die Story eine Spalte weiter wandert.
Beispielsweise wurde die Anforderung in Abb. 9 am 01.04. vom Product-Owner ins Team gegeben. Sie wurde am 02.04. in Bearbeitung genommen und am 08.04 an Hans den Tester übergeben.
Am Ende des Sprints kann über die Lead-Time aller Stories ein Mittelwert gebildet werden, der nichts anderes als eine Metrik für die Geschwindigkeit des Teams darstellt.
Insbesondere Engpässe lassen sich so auch sehr schnell erkennen. Dauert der Sprung von der DEV- in die TEST-Spalte jedes Mal sehr lange, wird dies am Board sofort sichtbar und man kann hinterfragen, wieso das so ist und was dagegen getan werden muss.
Das Team ist begeistert und nimmt sich vor, die Messung der Lead-Time zukünftig für alle Stories durchzuführen.

WIP-Limits für das Team
Allein durch die Einführung der Lead-Time wird dem Team schon viel klarer, wo die Engpässe liegen. Die Messung der Lead-Time macht Probleme sichtbar, löst diese aber nicht.
Arne macht einen weiteren Vorschlag.
Kanban bietet viele Werkzeuge, die zum Ziel haben, Arbeit fokussiert und konzentriert zum Abschluss zu bringen.
Das vielleicht wichtigste Werkzeug hierfür sind „Work in Progress“-Limits (WIP-Limits).
Durch die Definition von WIP-Limits limitiert das Team die Anzahl an Stories oder auch Tasks, die parallel in Bearbeitung sein dürfen.
WIP-Limits sind kein intuitives Werkzeug. Es braucht zu Anfang ein wenig Zeit, dieses Werkzeug effektiv einzusetzen.
Das Team und Arne haben das Problem auf dem Board zuvor schon richtig erkannt. Es wird zu viel Arbeit parallel gemacht.
Arne schlägt vor, einen Sprint lang mit WIP-Limits zu arbeiten um zu sehen, wie sich dieses Werkzeug auf die Produktivität auswirkt.

Dies geschieht ganz einfach dadurch, dass auf dem Board für jede Spalte oder auch zusammengefasst für mehrere Spalten definiert wird, wie viele Stories gleichzeitig in Bearbeitung sein dürfen (Abb. 10).

Abbildung 10: WIP-Limits begrenzen die parallele Arbeit

Das Team setzt sich zusammen und definiert, dass in der DEV- und QS-Spalte nicht mehr als zwei Stories gleichzeitig in Bearbeitung sein sollten.
Arbeitet Karl also an „Story A“ und Markus an „Story B“, ruht Georg sich in der Zwischenzeit aus? Keinesfalls. Da durch das definierte WIP-Limit nicht mehr als zwei Anforderungen gleichzeitig bearbeitet werden dürfen, wird das Team gezwungen, zusammen zu arbeiten. Georg unterstützt seine Teammitglieder um möglichst schnell eine Anforderung mindestens in die TEST-Spalte zu bringen. Dies schafft einen freien Slot und das Team kann „Story C“ in Bearbeitung nehmen.
Das Team definiert, dass Hans der Tester nur eine Story gleichzeitig bearbeiten sollte, um diese möglichst schnell an das Deployment-Team weiterreichen zu können.
Betrachten wir die Situation in Abb. 11.

Abbildung 11: WIP Limits fördern Team-Work

Hans ist mit dem Testen von „Story B“ beschäftigt. Die Stories „A“ und „C“ befinden sich bereits in der QS-Spalte. Das Board blockiert, denn das definierte WIP-Limit für die TEST-Spalte gestattet es nicht, weitere Stories aufzunehmen.
Können sich die Entwickler nun zurücklehnen? Ist das der Vorteil von WIP-Limits? Keinesfalls, denn um einen freien Slot zu schaffen und damit „Story D“ möglichst schnell in Bearbeitung nehmen zu können, unterstützen die Entwickler Hans bei technischen Problemen (Test-Umgebung funktioniert nicht), versorgen ihn mit Know-How über die Implementierung (erleichtert das Testen) oder bringen ihm einfach frischen Kaffee, um ihn wach zu halten.

Schon nach wenigen Tagen im Sprint zeichnet sich ab, dass die Lead-Time der Stories viel kleiner ist, als noch vor der Einführung von WIP-Limits.
WIP-Limits zwingen das Team, fokussiert an wenigen Anforderungen zu arbeiten und diese zum Abschluss zu bringen.

Scrum oder Kanban oder Scrumban?

Was ist nun besser und sollte verwendet werden? Scrum oder Kanban? Für das Team ist dies keine „Entweder-oder-Entscheidung“, sondern idealerweise verwendet man das Beste aus beiden Welten.
Das Team arbeitet weiterhin mit festen Sprintlängen, was Henning die Planung erleichtert und macht weiterhin Daily-Scrums.
Zusätzlich misst das Team die Lead-Time und arbeitet mit WIP-Limits.
Natürlich bieten sowohl Scrum als auch Kanban noch viel mehr Ansätze, Werkzeuge und Ideen als in diesem kurzen Artikel vorgestellt werden konnten.
Ich arbeite derzeit als Entwickler und Scrummaster in einem agilen Team. In diesem Team nutzen wir die Vorteile aus beiden Welten und alle Werkzeugen, die uns sinnvoll erscheinen.
Mein Rat ist, gehen Sie nicht dogmatisch sondern pragmatisch vor. Agil arbeitet man nicht schwarz oder weiß. Sie können aus einer Vielzahl an Werkzeugen wählen. Nutzen Sie diejenigen, die für Sie sinnvoll erscheinen und experimentieren Sie.
Stellt sich nach einem oder zwei Sprints heraus, dass ein Werkzeug nicht das erhoffte Ergebnis bringt, dann nehmen Sie das Thema in der Retrospektive auf und diskutieren Sie darüber.
Das Ziel ist immer das Gleiche. Schaffe Mehrwert für Deinen Kunden.
Das geht nur durch produktives Arbeiten und ständige Verbesserung.

Kontaktieren Sie mich, wenn Sie Fragen zum Artikel oder allgemein zu agiler Arbeit haben. Ich hoffe, das Lesen des Artikels hat Ihnen genauso viel Freude bereitet wie mir das Schreiben.

Vielen Dank an Wolfgang Wiedenroth für die wertvollen Tipps.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum das Team verantwortlich ist – immer

Im letzten Artikel habe ich um ein kleines Lächeln gebeten.

Heute geht es zurück zum Ernst des Lebens, denn wir Entwickler haben eine Aufgabe zu erfüllen. Wir machen das aber üblicherweise nicht allein, sondern hinter jedem Entwickler steht hoffentlich ein schlagkräftiges Team.

Gerade wir Agilisten haben hier sehr viel Glück, denn kaum einer hat jemals vom Ein-Mann-Scrum-Team gehört. Auch interessant wäre, wie die WIP-Limits in eine Ein-Mann-Kanban-Team gesetzt werden?:)

Was bedeutet es aber, im Team zu arbeiten?

Hat man hierdurch weniger Verantwortung? Kann man sich in der “Masse” verstecken? Machts jemand anders?

Definitv nein.

Es gibt einen schönen Spruch, dessen Autor ich leider nicht kenne:

„Wenn der Blinde den Lahmen trägt, kommen sie beide fort.“

Wenn ein Team arbeitet hat es genau zwei Möglichkeiten – entweder das Team arbeitet vereint auf ein Ziel hin – dann sind die meisten Teams kaum zu stoppen. Oder das Team behindert sich selbst (Neid, Misgunst, Misstrauen), dann sind sie nicht schneller oder besser als ein Einzelner Entwickler.

Das Team trägt die Verantwortung, Features, Produkte, Bugfixes bis dorthin zu bringen, wo sie dem Kunden echten Mehrwert generieren – Produktion.

Nicht ein einzelner Entwickler (“Wer hat diesen Bug eingebaut?”, “Ich bin für die Service-Schicht verantwortlich”), sondern das Team ist verantwortlich. Kommen Bugs ins System hat das Team versagt – fehlende Code-Reviews, fehlende Kommunikation oder einfach nur Faulheit.

Andererseits gibt es im Team keine Super-Heros – das Team sorgt dafür, dass das Know-How verteilt wird (ist nicht immer einfach, fällt mir auch manchmal schwer), so dass mit jedem Feature mindestens ein Entwickler etwas lernt.

So entwickelt das Team im Lauf der Zeit eine Kaizen-Kultur und entwickelt unglaubliche Schlagkraft.

Das Team ist verantwortlich – immer.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum Scrummaster keine Entwickler und Entwickler keine Scrummaster sind (gleichzeitig)

Im letzten Artikel habe ich darüber philosophiert, warum Unit Tests so unglaublich wichtig sind.

Heute möchte ich erklären, warum meiner Ansicht nach Scrummaster niemals Entwickler und Entwickler niemals Scrummaster sein sollten, gleichzeitig.

Ich bin in der glücklichen Situtation, dass ich schon seit langer Zeit in einem interessanten Projekt in einem agilen Umfeld arbeiten kann. In meinem jetzigen Projekt habe ich eine Doppelrolle inne. Ich bin sowohl Entwickler als auch Scrummaster. Leider ist kein Budget für einen dedizierten Scrummaster vorhanden.

Warum ist das ein Problem?

Jeder Entwickler im Team hat bestimmte Vorstellungen, wie das Projekt zu Laufen hat, wie neue Funktionalität implementiert werden soll und wie generell gearbeitet wird. Ich bin zusätzlich so etwas, wie der Technical Lead des Projektes. Ich kümmere mich um Architektur, Qualität und Kommunikation (immer zusammen mit dem Team natürlich).

Ein Scrummaster hingegen sollte keine eigenen Interessen verfolgen,  sondern das primäre Interesse des Scrummasters sollte sein, das Team in jeder Hinsicht zu unterstützen und generell voranzubringen.

In einer Doppelrolle ist das sehr schwierig bis hin zu unmöglich.

Bestes Beispiel ist die Retrospektive, die nach jedem Sprint durchgeführt wird.

In der Retrospektive reflektiert das Team über den Vergangenen Sprint, über Dinge die gut und Dinge die weniger gut gelaufen sind. Die Retrospektive dient dem Team als Gesprächsplattform, um Themen in ungezwungener Atmosphäre auf den Tisch zu bringen und zu diskutieren.

Idealerweise durchläuft eine Retrospektive die folgenden Phasen:

  1. Begrüssung
  2. Rahmen schaffen
  3. Daten sammeln
  4. Aktionen identifizieren
  5. Verabschiedung

Die einfachste Variante für Punkt 3 (das Herz der Retrospektive) sind beispielsweise folgende Aufgabenstellung:

  • Identifiziere 3 Punkte, die sehr gut gelaufen sind, die wie unbedingt beibehalten sollten
  • Identifiziere 3 Punkte, die verbesserungswürdig sind.

In der letzten Retrospektive bei uns im Team war ich wieder in der schwierigen Situation, sowohl Entwickler als auch Scrummaster zu sein.
Jedes Teammitglied hat einige Punkte auf Post-Its Notes notiert. Von mir kam der Punkt:

Meiner Ansicht nach haben wir zu viele Stories gleichzeitig in Bearbeitung.

Ein Punkt, der mir sehr auf der Seele brennt, und den ich unbedingt ändern möchte. Dieser Punkt ist im Team jedoch nicht auf Gegenliebe gestossen, da hier dieser Eindruck nicht unbedingt vorhanden ist.

Was mache ich jetzt als Scrummaster/Entwickler?

Als Scrummaster würde ich den Punkt zwar aufnehmen, evtl auch darüber diskutieren aber wenn der Konsens im Team klar dahin tendiert, dass dies kein Problem darstellt würden daraus wahrscheinlich keine Aktionspunkte entstehen.

Ich als Entwickler weiß, dass wir zu viele Stories in Bearbeitung haben und weniger Stories viel schneller dazu führen würden, dass Dinge wirklich abgeschlossen, lauffähig und in einem Produktivumgebung landen.

Beharre ich jetzt auf meinem Standpunkt und ignoriere meine Scrummaster-Rolle?

Akzeptiere ich meine Rolle als Scrummaster und schlucke meinen Entwicklerstolz herunter?

Die Doppelrolle als Scrummaster/Entwickler ist mehr als suboptimal. Am besten ist es, einen Scrummaster aus einem der anderen Teams (sofern vorhanden) zu bitten, die Leitung der Retrospektive zu übernehmen. Dann könnte ich meine Rolle als  Scrummaster für die Retrospektive vergessen und mich voll und ganz auf die Entwicklerseite und eine erfolgreiche Retrospektive konzentrieren.

Habt ihr damit Erfahrung?

 


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban