Category Archives: agile

Der Weg zum Meister – meine 10.000 Stunden als Entwickler

Ten thousand hours of practice is required to achieve the level of mastery associated with being a world-class expert — in anything.

Daniel Levitin

Die 10.000 Stunden Regel sollte jedem Entwickler (und auch jedem anderen) ein Begriff sein. Die Regel basiert ganz lose auf den Studien von Anders Ericcson und wurde hauptsächlich durch das Buch “Outliers” von Malcolm Gladwell bekannt.

Die Regel ist nicht wissenschaftlich belegt sondern ist eher als Richtlinie zu verstehen und besagt, dass jeder der auf seinem Fachgebiet führend sein oder werden möchte, mindestens 10.000 Stunden “Deep bzw. Delibate Practice” benötigt.

Was bedeutet Deep Practice?

Karl der Entwickler

Erstellt auf sp-studio.de

Nehmen wir zum Beispiel Karl.

Karl ist Entwickler und das seit 10 Jahren. Karl ist aber niemand, der sich intensiv mit seiner Arbeit und seiner Tätigkeit identifiziert, sondern ein 09:00 – 17:00 Entwickler.

Karl ist auch niemand, der sich in seiner Freizeit mit neuen Themen, Programmiersprachen und Problemstellungen auseinandersetzt.

Karl macht seinen Job – gut und zufriedenstellend – aber nicht herausragend.

Man könnte jetzt annehmen, das Karl die 10.000 Stunden schon lange geknackt hat und als Meister seines Faches zählt.

Mal im Kopf überschlagen:

220 (grob Arbeitstage pro Jahr abzgl. Urlaub) * 8 (Stunden pro Tag) * 10 Jahre = 17.600 Stunden

So gerechnet müsste Karl also ein Superstar und ein Held in seinem Metier sein. Das was Karl aber tagtäglich macht ist keine Deliberate Practice sondern sein Tagewerk, und Tagewerk zählt nicht in die 10.000 Stunden Regel.

Was wäre wirkliche Praxis in Karls Job als Entwickler:

  • Auseinandersetzung mit komplexen Problemen, die neue Denkmuster erfordern
  • Neue Programmiersprachen, Konzepte und Ansätze erlernen und meistern
  • komplexe Algorithmen verstehen
  • Pair Programming und Auseinandersetzung mit Kollegen
  • Konzepte lehren und schulen
  • Fokussierung und Konzentration

Was zählt nur in Teilen:

  • Wiederholte und oft gelöste Aufgabenstellungen (sich wiederholende Aufgaben können für Routine sorgen, aber nur wenn Sie bewusst gelöst werden und nicht “automatisch”)

Was zählt gar nicht:

  • Fachfremde Aufgaben (Rechnungsstellung etc.)

Stellen wir die Rechnung also nochmals auf:

220 (grob Arbeitstage pro Jahr abzgl. Urlaub) * 4 (Stunden pro Tag) * 10 Jahre = 8.800 Stunden

Nehmen wir vereinfacht an, Karl verbringt pro Tag 4 Stunden mit echter Praxis für seine Arbeit. An manchen Tagen vielleicht weniger, an manchen Tagen mehr. Im Mittel könnte das stimmen. Das bedeutet, Karl hat bis dato 8.800 Stunden Praxis gesammelt. Im fehlen also noch genau 1.200 Stunden zum Meister.

Da potentiell die Möglichkeit zur Konzentration und Fokussierung abnimmt, je länger man im gleichen Job arbeitet,  wird auch die Praxis, die Karl pro Jahr sammeln kann abnehmen. Das bedeutet, es ist sehr fraglich, ob er jemals den Status eines Meisters erreichen kann (und vielleicht auch will).

Ich stelle die Rechnung mal grob für mich auf. Ich habe im Jahr 2002 angefangen, mich mit Programmiersprachen zu beschäftigen (ungefähr..).

2002 (grob jeden zweiten Tag eine Stunde) – (250 / 2 * 1)
2003 (grob jeden dritten Tag eine Stunde, da ich hier viel gearbeitet habe) – (250 / 3 * 1)
2004 (im Studium jeden Tag ca. eineinhalb Stunden inkl Wochenenden) – (250 * 1.5)
2005 – (im Studium jeden Tag ca. zweieinhalb Stunden inkl Wochenenden)(250 * 2.5)
2006 – (Praxissemester – hier habe ich ein halbes Jahr lang extrem viel gelernt und gearbeitet)
(125 * 6) + (125 * 2.5)
2007 – (Annahme, 3 Stunden Praxis pro Tag + 150 Extrastunden für die Abschlussarbeit) (250 * 3) + 150
2008 – (Studienabschluss und erstes grosses Projekt mit steiler Lernkurve) (125 * 5)  + (125 * 6)
2009 – (extrem viel gearbeitet und gelernt – Annahme 270 Arbeitstage) (270 * 6)
2010 – (einige neue Projekte, viele unterschiedliche Programmiersprachen und Werkzeuge) 270 * 6 + 100
2011 – 280 * 6
2012 – (großes neues Projekt, neues Team, Teamlead und Scrummaster) – 280 * 6
2013 (Selbstständigkeit)- 80 * 10

Die Rechnung ergibt also folgendes:

(250 / 2 * 1) + (250 / 3 * 1) + (250 * 1.5) + (250 * 2.5) + (125 * 6) + (125 * 2.5) + (250 * 3) + 150 + (125 * 5)  + (125 * 6) + (270 * 6) + 270 * 6 + 100 + 280 * 6 + 280 * 6 + 80 * 10 = ~12.000 Stunden Praxis in 10 Jahren.

(Natürlich ist die Rechnung komplett an den Haaren herbeigezogen, aber trotzdem interessant, wenn man mal so grob zusammenrechnet)

Das entspricht in etwa auch den Erfahrungen anderer Menschen, die sich mit dieser Regel befasst haben. Typischerweise braucht man 10 Jahre und ~10.000 Stunden Praxis, um gut in etwas zu werden ( ich behaupte jetzt einfach mal, dass ich in dem was ich mache ganz OK bin).

Es ist extrem interessant, wenn man sich weiter mit dem Thema Deliberate Practice beschäftigt. Hier sind einige Buchempfehlungen zum Thema:

 

 

Malcolm Gladwell – Outliers

 

Robert Greene – Mastery

 

Doug Lemov – Practice Perfect

Weitere Links:

10.000 Stunden Regel

Was ich so mache um auf meine 10.000 Stunden zu kommen

 

 

 

 

Social Refactoring – das beste Investment

Im letzten Artikel  habe ich darüber philosophiert, warum das Team verantwortlich ist. Heute geht es um ein extrem wichtiges Thema, und zwar um das Thema “Social Refactoring”.

Viele von uns haben bereits die Erfahrung gemacht, was es bedeutet, in einem agilen Team zu arbeiten, völlig egal ob es nun um Scrum, Kanban oder um etwas völlig anderes geht.

Da ist seit längerem als Scrummaster in einem agilen Team beschäftigt bin (und zuvor auch bereits in sehr vielen unterschiedlichen Teams Scrummaster und auch Entwickler war) kann ich hier ein wenig aus der Erfahrung berichten.

Ich persönlich freue mich immer sehr, wenn Teams engagiert sind, sauberen Code zu produzieren, die gesamte Code-Basis in Clean-Code-Manier sauber zu halten und konstante Refactorings anstreben. Gibts nicht immer, habe ich aber tatsächlich schon erlebt.

Was ich aber auch sehr oft erlebt habe ist, dass die Code-Basis zwar sauber gehalten wird, die sozialen Strukturen im Team aber sträflich vernachlässigt werden. Wie macht sich das bemerkbar?

Kein Collective-Code-Ownershop

Der Code im Team gehört nicht allen, sondern es gibt sie, die Spezialisten. Hier haben wir den EJB-Experten, der sich nur um die Service-Schicht kümmert. Wir haben den JPA-Experten, der alles unterhalb der Repository-Schicht beherrscht. Es gibt den UI-Experten, der funky Oberflächen bastelt. Und insgesamt gilt, jeder verteidigt sein Revier. Da wird geknurrt und gefaucht, was das Zeug hält, sobald ein “Fremder” versucht, im Nachbarrevier zu wildern.

Fingerpointing und Blaming

Ich glaube, dass wir am besten lernen (zumindest ist es bei mir so), wenn wir Fehler machen können/dürfen/sollen, ohne dafür zur Rechenschaft gezogen zu werden. Gerade bei uns in der Entwicklung ist es extrem wichtig, zu experimentieren. Verschiedene Lösungsansätze funktionieren Problemabhängig besonders gut/schlecht, was sich aber meistens nicht sofort beurteilen lässt.

Oft erlebe ich aber, dass jeder Fehler gnadenlos ausgenutzt wird und beinahe unmittelbar der “Blame and Point”-Pattern angewandt wird. Am schlimmsten ist es, wenn dies nicht einmal direkt geschieht, sondern in der Kaffeeküche oder im Code.

Ein Commit-Kommentar den ich kürzlich gelesen habe, lautete in etwa so:

“Clean up this mess. This Code should not be refactored but deleted.”

Dont talk to Strangers

Manchmal finde ich es bedenklich, wie wenig tatsächlich in Teams während der täglichen Arbeit gesprochen wird. Oft erlebe ich es, dass sich jeder um “seinen Kram” kümmert, alles andere ist erst mal egal.

Das Daily-Scrum, dass meiner Ansicht eine Grundlage für nachfolgende Kommunikation sein soll wird oft nur betrachtet als die “nervigen 15 min, damit der Scrummaster Ruhe gibt”.

Jeder schnappt sich seinen Task, “Wiedersehen, wir sehen uns morgen um 10.”.

Nur die Starken kommen in Garten

Die meisten Teams sind durchaus unterschiedlich besetzt (zumindest anfangs). Es gibt die Entwickler mit viel Erfahrung, aber wenig Motivation. (Lieblingssatz: “Haben wir schonmal probiert, funktioniert nicht”).

Es gibt die mit viel Erfahrung und hoher Motivation (die “Keyplayer”, “King of the Hill”, “der Architekt”).

Es gibt Entwickler mit wenig Erfahrung und hoher Motivation (oft “Formbar” oder “Formfleisch” genannt).

Und die “Schlusslichter”, die Entwickler mit wenig Erfahrung und noch weniger Motivation (oft als “Bremsscheibe” tituliert).

Das ist zunächst prinzipiell überhaupt nichts schlimmes und völlig normal. Wenn sich dieses Gefüge aber im Lauf der Zeit nicht ändert und nach 5-6 Sprints immer noch die gleiche Konstellation vorherrscht, dann läuft etwas grandios schief.

Wie wirkt man gegen?

Ich hoffe es wurde klar, dass die Formulierungen von oben sehr überzogen und überspitzt sind. Aber in jeder Formulierung steckt zumindest ein Körnchen Wahrheit. Die Motivation, an bestehenden Misständen etwas zu ändern muss aus dem Team kommen. Wir als Scrummaster können / und sollten hier nur lenkend eingreifen (ich weiß, leichter gesagt, als getan).

Ich bezeichne dieses Vorgehen gerne als “Social-Refactoring” und halte es für genauso wichtig wie Refactoring im Code (und jeder der mich kennt, weiß dass ich Refactoring liebe:)).

Was ist nun die Geheimwaffe des Scrummasters?

Gewalt? Drohung? Blaming? Weinen?

Natürlich nicht, sondern die Retrospektive.

Ich als Scrummaster erlebe es sehr oft, dass die Retrospektive als relativ unnütz, unwichtig und zu langweilig erachtet wird. “Wieso, es läuft doch alles gut” bekomme ich des öfteren zu hören. Als Scrummaster sollte man hier hart bleiben, denn es gibt immer Punkte, über die man sprechen kann. Aus einigen Jahren agiler Erfahrung kann ich sagen, dass Retrospektiven in etwa so etwas wie “Pair-Programming beim Social-Refactoring” sind.

Es gibt zwei Bücher, die ich zum Thema Retrospektive empfehlen würde:

     

Und mein wichtigster Tipp aus der Praxis, denken Sie sich was aus! 

Der grösste Fehler den Sie machen können ist, immer das Gleiche Programm in der Retrospektive abzuspulen. Ich habe es schon erlebt, dass Teammitglieder, die 2 Min vorher da waren schon angefangen haben, ihre üblichen “Zettel” zu schreiben – was lief gut, was schlecht etc. Und das bevor die Retrospektive überhaupt angefangen hat. Da wird es Zeit, gegen zu steuern.

Die Retrospektive muss für die Teammitglieder interessant sein, damit sie wirklich effektiv wird.

Ein Erlebnis, eine Aha!

Beispiel:

Die Mittags-Retro

Wir machen regelmässig eine Mittags-Retro, das Team geht zusammen zum Mittagessen oder holt sich was und setzt sich irgendwo draussen hin und dann wird völlig zwanglos diskutiert. Der Vorteil hiervon ist, dass allein durch den Umgebungswechsel völlig neue Impulse entstehen können und interessante Punkte auf die Agenda gebracht werden.

Stammtisch-Retro

Wieso muss die Retrospektive immer förmlich ablaufen. Manchmal ist es durchaus in Ordnung, die Retrospektive auf kurz vor dem Feierabend zu legen und sich dann ein Bier dazu zu genehmigen. Schafft eine entspannte Atmosphäre und funktioniert erstaunlich gut. Natürlich sollten sich die Teilnehmer dabei nicht betrinken!:).

Hierzu gibt es viele Tipps in den obigen beiden Büchern und ich rate dringend, einfach mal ein wenig experimentierfreudig zu sein und das Eine oder Andere auszuprobieren. Die meisten Teilnehmer danken es einem.

Zu guter Letzt, was ich dringend empfehle ist der sogenannte Team-Radar.

Der Scrummaster liest zu Beginn jeder Retrospektive 5 Begriffe vor, und bittet alle Teammitglieder für diese 5 Begriffe anonym eine Wertung abzugeben auf einer Skala von 1-10. Was daraus entstehen kann, sieht man in diesem Foto.

Team Radar

Agiler Team Radar

Die 5 Begriffe sind immer diesselben. In diesem Fall haben wir die Begriffe

  • Qualität
  • Teamwork
  • Kommunikation
  • Pair-Programming
  • Zufriedenheit

gewählt. Das sind Eigenschaften, Praktiken, Vorgehen die dem Team wichtig erscheinen. Mit diesem Hilfsmittel lässt sich selbst aus Retrospektiven mit wenig Output (gibt es immer mal, beispielsweise kurz vor der Urlaubszeit) noch wichtige Information generieren.

Jeder Sprint bekommt eine eigene Farbe, und auf jeder Achse wird der Mittelwert aller abgegebenen Wertungen eingetragen.

Am Beispiel Qualität lässt sich folgende Entwicklung ablesen:

Entwicklung auf dem Radar

Entwicklung auf dem Radar

Das Team hatte das Gefühl, dass die Qualität über mehrere Sprints immer weiter abgenommen hat. Dies ist natürlich rein subjektiv und hat nicht unbedingt etwas mit der tatsächlichen Code-Qualität zu tun. Hier geht es allein darum, wie das Team empfindet.

Wir haben es über mehrere Sprints nicht hinbekommen, das Gefühl des Teams in dieser Hinsicht zu verbessern, bis wir schließlich irgendwann auf den Trichter gekommen sind, was dem Team so Bauchweh verursacht. Diese Ursache haben wir beseitigt und schließlich im “blauen Sprint” einen ersten Erfolg gefeiert.

Der Team-Radar ist ein wirklich exzellentes Mittel, um die Grundstimmung im Team einzufangen.

Insgesamtes Fazit eines Scrummasters – Social-Refactoring ist wichtig. Selbst das beste Team muss an sich arbeiten. Es funktioniert nicht einfach so, aber jede Minute die ein Team hierfür investiert zahlt sich meistens doppelt und dreifach aus. In diesem Sinne.

War dieser Blogeintrag für Sie interessant? Braucht Ihr Team Unterstützung? Kontaktieren Sie mich, ich bin hier um zu helfen.

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

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

Scrum & Kanban in der Praxis in der “Java Aktuell”

Ich wurde gebeten, für die Java Aktuell einen Artikel zum Thema “Scrum & Kanban” in der Praxis zu schreiben,

aber gerne doch!

Anmerkung:
Bisher habe ich leider kein Belegexemplar oder ähnliches erhalten. Der Artikel ist auch in meinem Blog veröffentlicht, und zwar hier.


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

Als wir einmal aus Versehen Scrum machten…

Manche Wochenenden sind wirklich hart, aber manche sind auch härter. Ein normales Wochenende beginnt irgendwann Freitag abends, man kommt aus dem Büro, schnuppert zum ersten Mal an diesem Tag den Duft und die Luft der Freiheit und freut sich auf zweieinhalb entspannte Tage.

Manche Wochenenden starten aber auch so, dass man am Freitag aus dem Büro kommt und genau weiß, dass ein sehr, sehr anstrengendes Wochenende bevorsteht.

So ein Wochenende war beispielsweise dieses. Folgendes ist passiert.

Das Projekt

Meine Schwägerin Sandra (die Schwester meine Frau) und deren Mann Steffen bauen ein Haus (Projekt!).

Normalerweise ist das Projekt fast ausschließlich mit externen Mitarbeitern besetzt (Bauarbeiter,Technische Zeichner, Maurer, Zimmermänner).

Um Kosten zu sparen werden jedoch kleinere Teilprojekte durch interne Teams vom Projektleiter (mein Schwiegervater) besetzt.

Eines dieser Teilprojekte sollte dieses Wochenende durchgeführt werden.

Die Vision

Das neue Haus bekommt einen vollständig aus Holz gebauten Dachgiebel mit Sichtbrettern (Epic). Um diesen Dachgiebel bauen zu können müssen gewisse Vorarbeiten geleistet werden.

Der technische Projektleiter und Architekt (Gerhard, der Zimmerermeister) hat bereits einige technische Stories mit seinem Team von externen (Zimmerersleut) abgeschlossen. Natürlich alles in Time und Budget. Zuletzt wurden die entsprechenden Stütz- und Sichtbalken angefertigt, genauso wie die Bretter zur Verkleidung des Daches zurechtgeschnitten.

Da das Errichten des Dachgiebels einen festen Abgabetermin hat, musste ein Team von internen (Schwager + Geschwister) aus anderen Projekten (Wochenend-Entspannung) abgezogen werden, in der Hoffnung durch die Erhöhung von Ressourcen Zeit- und Budget einsparen zu können.

Das Epic “Errichten des Dachgiebels nebst Dach” wurde vom Projektleiter in mehrere Stories mit festem Scope unterteilt. Eine dieser Stories wird dem frisch zusammengestellten Team vom technischen Projektleiter vorgestellt.

Das Team besteht aus Sandra + Steffen (Product-Owner, Häuslebauer und Arbeiter), Martin (Scrummaster + Arbeiter), Anita und Christine (Schwestern + Arbeiterinnen). Wir befinden uns also in der wunderbaren Position, dass die Product-Owner Teil des Teams sind und so für fachliche Fragen jederzeit zur Verfügung stehen.

Es sind zwei Sprints geplant (Dauer jeweils 1 Tag, Samstag + Sonntag) mit folgenden Stories im Scope:

Story 1: Als Häuslebauer möchte ich, dass meine Bretter für das Dach mit einem Schutzlack bestrichen werden, damit sie vor der Witterung geschützt sind.

Story 2: Als Häuslebauer möchte ich, dass alle nach außen sichtbaren Balken des Dachgiebels mit Schutzlack bestrichen werden, damit auch sie vor der Witterung geschützt sind.

Zunächst wird vom Team eine Estimation-Runde für die kommenden Sprints abgehalten (vor Sprintbeginn, Freitag abend). Leider jedoch mangels Pokerkarten nicht durch Planning-Poker:).

Das Team einigt sich auf die entsprechenden Tasks und gibt das Commitment ab, den Scope bis Sonntagabend zu schaffen.

Jede Story soll in einem eigenen Sprint abgearbeitet werden.

Zusätzlich werden noch die Verfügbarkeiten für den kommen Sprint geprüft, hierbei stellt sich heraus, dass die beiden Product-Owner am Samstag mindestens 3 Stunden nicht verfügbar sein werden, da sie bereits Stories für kommende Sprints planen werden (Beratung im Möbelhaus bzgl. neues Bad).

Das Team plant die Stories und definiert erste Tasks:

  • Beschaffung von Ressourcen (Pinsel, Lack, Malerkleidung, Folien)
  • Bereitstellung eines Repositories zur Lagerung von lackierten Brettern
  • Lackieren von gekennzeichneten Brettern
  • Qualitätssicherung
  • Pair-Lackiering zwecks Know-How-Verteilung

Der Sprint startet

Das Team trifft sich Samstag früh zum Daily Scrum (Frühstück) und bespricht die Aufgaben für den heutigen Tag.

Hierbei stellt sich zunächst heraus, dass der Technische Projektleiter Gerhard zunächst eine Einweisung für das Team geben wird, da Gerhard die technische Expertise hat und hierdurch Zeit und Kosten gespart werden können.

Zunächst erklärt Gerhard fachlich,was überhaupt gemacht werden muss (ich wundere mich sehr, denn die Expertise hier liegt tatsächlich beim Projektleiter und nicht bei den Product-Ownern).

Die Bretter müssen jeweils auf der Oberseite und den zwei Seitenkanten gestrichen werden. Hierfür stellt uns Gerhard die notwendigen Tools (2 Böcke um die Bretter aufzulegen, Lack-Eimer, Pinsel und eine Vorrichtung zum Trocknen der Bretter zur Verfügung).

Der Sprint startet, leider verlassen die zwei Team-Mitglieder (und Product-Owner) sofort den Ort des Geschehens und widmen sich der Bad-Beratung.

Das restliche Team (Martin, Anita und Christine) starten mit der Umsetzung. Es ist keine großartige Analyse notwendig, denn nach kurzer Beratung im Team ist klar, dass die Aufgabe verstanden ist und das Team sich auf ein gemeinsames Design geeinigt hat.

Die ersten Tasks sind schnell erledigt, denn für das Aufsetzen des Repositories wird einfach die leerstehende Lagerhalle des Projektleiters verwendet.

Das Team startet also zunächst zu dritt. Die Ressourcen (Bretter) wurden bereits angeliefert, aber bisher noch in Folie verschweist. Sofort beginnt das Team selbstverantwortlich damit, die entsprechenden Rollen zu verteilen. Martin organisiert zunächst einen Schraubenzieher und einen Holzstab um die Lackeimer zu öffnen und den Lack durchzurühren.

In der Zwischenzeit kümmern sich Anita und Christine darum, die Folie der verpackten Bretterstapel zu öffnen, so dass im weiteren Sprint sehr schnell auf die Ressourcen zugegriffen werden kann. Es wurde sehr wohl darüber diskutiert, welche Variante die performanteste ist (Öffnen der Folie erst direkt vor Verwendung oder Öffnen aller Folien). Da Martin aber ungefähr so lange brauchen wird, um den Lack vorzubereiten wir Anita und Christine um alle Folien zu öffnen einigt sich das Team auf diesen Weg.

Nachdem der Lack angerührt ist, starten Martin und Christine damit, Bretter auf die vorbereiteten Böcke zu legen.

Zunächst startet das Team mit 3 Brettern, die gleichzeitig bearbeitet werden. Das Team einigt sich darauf, dass Anita und Christine gemeinsam auf einer Seite anfangen (Pair-Lackiering) und Martin auf der anderen Seite. Sobald sich das Team in der Mitte trifft sind die Bretter fertig.

Martin, der Scrummaster fängt sofort an, die Geschwindigkeit des Teams zu messen und misst die Dauer für das Lackieren von 3 Brettern (WIP-Limit!). Die Dauer von 8 Minuten ist alles andere als zufriedenstellend. Martin macht eine Hochrechnung, zählt alle zu lackierenden Bretter und kommt auf 210 Stück, was an einem perfekten Tag (ohne Unterbrechungen) in ca. 9,5 Stunden zu erledigen wäre.

Der Arbeitsablauf gliedert sich in folgende Schritte:

  • Bretter auf die Böcke platzieren
  • 3 Seiten lackieren (obere Seite + 2 Seiten)
  • Bretter in die Trockenvorrichtung einbringen

Martin weiß aber auch, dass es keine perfekten Tage gibt, also wäre wohl eher mit 11 Stunden zu rechnen. Dies ist für keines der Teammitglieder akzeptabel und so wird bereits über mögliche Refactorings nachgedacht.

Eine Möglichkeit wäre, die Anzahl der Bretter zu erhöhen (WIP-Limit erhöhen), eine Erhöhung der Ressourcen (Teammitglieder) wäre leider erst in einigen Stunden möglich, sobald die Product-Owner zurückkommen. So lange will das Team aber nicht warten, also einigen sich alle gemeinsam ( mit dem Scrummaster), die WIP-Limits hochzusetzen auf 6 Bretter, die gleichzeitig bearbeitet werden.

Zusätzlich möchte das Team die Arbeit besser aufteilen, so dass das Teammitglied Anita sich darum kümmert, die dünneren aber schwieriger zu streichenden Seitenteile zu streichen, währendessen Christine und Martin die großen Flächen der Bretter lackieren. Die Arbeit wird also besser aufgeteilt und die Teammitglieder kommen sich weniger in die Quere.

Nach dem zweiten Durchlauf misst der Scrummaster erneut die Durchlaufzeit und kommt auf ca. 10 Minuten für 6 Bretter, was hochgerechnet eine Dauer von ca. 6 Stunden beträgt. Das Team hat also durch eine einfache Anpassung eine Steigerung um grob 30% erreicht.

Das Team legt los und merkt mit der Zeit richtig, wie sich die einzelnen Teammitglieder aufeinander einspielen. Nach vier Iterationen macht Anita ein (Code-) Review der bereits abgeschlossenen Bretter und stellt signifikante Qualitätsmängel fest, so dass hier leider nochmals nachgearbeitet werden muss.

Das Team beschließt, sofort eine Retrospektive zu machen um über die Mängel zu diskutieren (das Team ist sich natürlich im Klaren darüber, dass es sehr früh ist, nach ca. einer Stunde Sprintdauer eine Retrospektive durchzuführen, es spricht aber absolut nichts dagegen, wenn das Team sich gemeinsam darauf einigt.)

Das Team stellt sich also folgende Fragen:

Was lief gut?

  • Aufteilung der Aufgaben auf einzelne Teammitglieder
  • WIP Limits

Was lief nicht gut?

  • Qualitätssicherung
  • Ein Teil des Teams nicht verfügbar

An der Verfügbarkeit der Teammitglieder kann derzeit leider weder der Scrummaster noch der Projektleiter etwas ändern. An der Qualität jedoch durchaus. Das Team vereinbart, eine zusätzliche Qualitätssicherung nach jedem Durchgang. Dies soll zunächst von Anita durchgeführt werden, die nochmals ein kurzes Review für jedes Brett macht und ggf. nacharbeitet. Jedes Brett, dass durch das Review gekommen ist, wird von Martin und Christine auf die Trockungsvorrichtung gebracht.

Definition of Done

Das Team einigt sich hierfür zu folgender Definition of Done:

  • Jedes Brettoberseite ist vollständig mit Lack bedeckt
  • Die Seiten sind vollständig gestrichen
  • Es befinden sich keine Lack-Ansammlungen mehr auf Brettern, sondern diese sind sauber verstrichen.

Dadurch, dass das Team mittlerweile sehr gut aufeinander eingespielt ist, führt dieser zusätzliche Schritt zu keiner Verzögerung beim Fertigstellen der Story und doch wird eine signifikante und messbare Steigerung der Qualität erreicht.

Das Team arbeitet weiter für zwei Stunden und schafft es immer besser, die anstehenden Tasks abzuarbeiten als plötzlich Steffen (der vermisste Product-Owner) das Büro (also die Halle) betritt.

Zunächst stellt sich die Frage, ob eine Erhöhung der Teamstärke überhaupt Sinn macht, zumal das Team in der jetzigen Konstellation sehr gut aufeinander eingespielt ist und eine zusätzliche unerfahrene Ressource zunächst den Fluss bremsen dürfte. Ein weiteres Problem, das auftritt ist das Fehlen eines Pinsels, da momentan nur 3 verfügbar sind.

Das Team entscheidet sich dennoch, dass es Sinn macht, dass Steffen in die Story einsteigt. Das Fehlen eines Pinsels wird vom Team als Impediment an den Scrummaster (Martin) kommuniziert, der löst das Impediment temporär, indem er seinen Pinsel an Steffen abgibt, und so dafür sorgt, dass das Team zunächst problemlos weiterarbeiten kann.

Martin sucht in der Zwischenzeit den Projektleiter (Schwiegervater) auf, und bittet diesen um weitere Ressourcen. Der Projektleiter hat schnell ein einsehen, denn der Scrummaster argumentiert, dass er überzeugt ist, dass eine Erhöhung der Teamstärke sich positiv auf die Velocity auswirkt.

Die beiden lösen das Problem durch einen weiteren Pinsel (leider einen ziemlich schmalen), den der Scrummaster zurück zum Team bringt. Es stellt sich heraus, dass der schmale Pinsel ideal geeignet ist, um die Seiten der Bretter zu streichen, so dass sich jetzt 4 Teammitglieder aktiv am Sprint beteiligen können.

Das fünfte Teammitglied (Product-Owner Sandra) fragt zwar an, ob weitere Ressourcen benötigt werden, dies wird vom Team aber verneint, da dies die Koordination innerhalb des Teams stark erschweren würde. Das Team einigt sich also darauf, dass Sandra sich darum kümmern soll, das Team anderweitig zu supporten (Kaffee kochen, Kuchen bringen sowie schon mal das Abendessen vorbereiten).

Das Team einigt sich in der Zwischenzeit darauf, dass es besser ist, angefangene Aufgaben (einzelne Bretter) so schnell wie möglich fertig zu stellen und nicht alle Bretter gleichzeitig anzufangen. Sind zwei Bretter fertiggestellt, bringen die Teammitglieder die zuletzt an diesen gearbeitet haben diese auf die Trockenstation, während die anderen Teammitglieder weiterarbeiten und dann die nächsten Bretter auf die Trockenstation bringen.

Zwischendurch misst Martin der Scrummaster immer wieder die Performance des Teams (in der Zwischenzeit bei 4:40 für 6 Bretter), was das ganze Team zufrieden stellt.

Burn-Down-Trockenstation

An der Burn-Down-Trockenstation ist für jeden jederzeit ersichtlich, wieviel Tasks (Bretter) bereits abgeschlossen sind, was der Projektleiter auch des öfteren in Anspruch nimmt.

Scrum-Board

Weiterhin ist das Scrum-Board (Lager von nicht bearbeiteten Brettern) jederzeit ersichtlich, wieviele Tasks noch abzuarbeiten sind, um den Sprint-Scope zu erreichen.

Der erste Sprint endet…

Der erste Sprint endet und das Team schafft alle Tasks (Bretter) für diesen Sprint.

Am Ende des Tages macht das Team ein Review zusammen mit den Product-Ownern (Steffen und Sandra) sowie dem Projektleiter (Schwiegervater).

Hierbei führt das Team vor, wieviele Bretter lackiert wurden und wie diese zum Trocknen gelagert wurden. Sowohl Product-Owner, Projektleiter und technischer Projektleiter (Gerhard) erteilen die Abnahme und erklären den Sprint zum Erfolg.

Zur Feier des Tages treffen sich alle Projektbeteiligten und feiern den gelungenen Sprint (bei Brotzeit und Weißbier).

Sprint 2 startet

Allen Teammitgliedern sind zum Ende des Sprints die Strapazen anzumerken. Der Scrummaster macht sich Sorgen um sein Team und mahnt die Einhaltung des Sustainable Pace an. Das Team einigt sich darauf, dass es den Tag etwas später angeht (geplant war Sprint-Start um 08:00, das Team verschiebt zusammen mit den Product-Ownern und dem Projektleiter auf 09:00).

Zunächst trifft sich das Team wieder zum Daily Scrum (Frühstück) und bespricht die Aufgaben des Tages.

Hier nochmals die Story, die in diesem Sprint umgesetzt werden soll:

Story 2: Als Häuslebauer möchte ich, dass alle nach außen sichtbaren Balken des Dachgiebels mit Schutzlack bestrichen werden, damit auch sie vor der Witterung geschützt sind.

Das Team wird diesen Sprint nicht vor Ort arbeiten sondern in den Räumlichkeiten des technischen Projektleiters Gerhard (er ist der Zimmerermeister und hat die Balken bei sich im Holzlager).

Der Projektleiter organisiert also eine Mitfahrgelegenheit für das Team (mit beiden Familienautos) und das Team macht sich auf den Weg.

Vor Ort stellt sich sofort heraus, dass dem Team für den Sprint-Start nicht genügend Ressourcen zur Verfügung stehen. Der technische Projektleiter hatte 3 Eimer Lack organisiert mit der Zusicherung, dass diese für beide Stories reichen würden. Leider wurden durch fehlende Erfahrung im Team zu viel Ressourcen (Lack) im letzten Sprint verbraucht, so dass der Scope von Sprint 2 gefährdet scheint. Dies scheint zunächst ein großes Problem zu sein, denn es ist Sonntag und die Ressourcenbeschaffung scheint zunächst unmöglich.

Der Scrummaster und das Team sowie der technische Projektleiter einigen sich darauf, dass dieses Problem im Anschluss geklärt wird, da noch genügend Lack zur Verfügung steht, um zunächst mit dem Sprint zu starten.

Zunächst erläutert der technische Projektleiter, was genau zu tun ist (schon wieder ist es so, dass nicht die Productowner die fachlichen Anforderungen kennen, sondern der technische Projektleiter).

Gerhard erklärt, dass alle Balken an bestimmten Stellen mit Kerben versehen sind, an denen die Balken später am Dachgiebel ineinandergesteckt werden. Ausserdem sind alle Balken an den Stellen, an denen sie der Witterung ausgesetzt sind abgeschliffen. Diese Stellen sind leicht erkennbar, und Gerhard erklärt, dass genau diese Stellen lackiert werden müssen. Es gibt jedoch einige Ausnahmen, die Gerhard dem Team erklärt, so müssen manche Balken nur auf bestimmten Seiten, andere jedoch gar nicht lackiert werden).

Das Team (heute bestehend aus beiden Product-Ownern Steffen und Sandra, Martin, Anita und Christine) diskutiert kurz und stellt fest, dass die Anforderungen so weit klar sind und das mit dem Sprint gestartet werden kann.

Das Scrum-Board

Das Scrum-Board visualisiert die anstehenden Aufgaben für den Sprint.

Während das Team also beginnt, die ersten Tasks auf (aus) dem Scrum-Board (Stapel von unlackierten Balken) in die “In Progress”-Spalte (vorbereitete Böcke für die Balken zum Streichen) zieht, klärt der Scrummaster mit dem technischen Projektleiter, wie das Impediment des fehlenden Lacks gelöst werden kann.

Es findet sich eine einfache Lösung, da ein Projektleiter in einem anderen Projekt (ein Kollege von Gerhard, der ganz in der Nähe wohnt) Ressourcen zur Verfügung hat, die noch nicht direkt benötigt werden. Gerhard macht sich also schnell auf den Weg, und besorgt zwei weitere Eimer Lack.

Die Aufgabenverteilung im Team ist in diesem Sprint relativ klar, denn es gibt Aufgaben, die nur von Spezialisten im Team erledigt werden können (das Hin- und Herstapeln von fertigen bzw. neuen Balken können nur die Männer) während der Rest des Teams sich darauf konzentriert, die geschliffenen Stellen zu lackieren.

Es dauert nur ca. 15 Min. und der technische Projektleiter kommt mit den fehlenden Ressourcen, so dass auf jedenfall genügend für den Sprint vorhanden sind. Dieser verlässt dann aber das Teambüro (Hof) mit der Aussage, dass wichtige andere Aufgaben auf ihn warten (es ist Sonntag, und da gibts haufenweise besseres zu tun, als zuzuschauen, wie ein Haufen Balken lackiert wird).

Das Team arbeitet konzentriert ca. eine Stunde an den anstehenden Aufgaben, bis ein Teammitglied sich per Handzeichen meldet und über ein mögliches Problem informiert.

Impediment

Das Teammitglied ist sich nicht mehr sicher, wie und ob ein bestimmter Balken zu streichen ist. Das Team kommt zusammen, und diskutiert das Problem. Hierbei kommen folgende Lösungsvorschläge zusammen:

  • Gerhard meinte, der Balken muss gar nicht gestrichen werden
  • Gerhard meinte, der Balken muss komplett gestrichen werden
  • Gerhard meinte, der Balken muss nur am vorderen Ende gestrichen werden
  • Ich habe keine Ahnung

Es findet sich leider keine Lösung, da scheinbar niemand im Briefing des technischen Projektleiters besonders aufmerksam war. Der Scrummaster nimmt sich des Problems an und versucht, den technischen Projektleiter telefonisch zu erreichen. Martin versucht Gerhard zu erklären, welcher Balken genau gemeint ist (was sehr schwierig über das Telefon ist, da im Prinzip alle Balken genau gleich aussehen), aber er schafft es, sich technischen Rat einzuholen und so das Problem zu lösen (der Balken war komplett zu streichen).

Refactoring

Was bei dem Telefongespräch auch herauskommt ist, dass die gestrichenen Balken wieder genauso aufgestapelt werden müssen, wie sie vor dem Streichen gestapelt waren, damit sie mit kompatibel mit den Bestandssystemen (dem Gabelstapler) sind, um eine spätere Integration (das Verladen der Balken auf einen Ladehänger) zu ermöglichen.

Dies hatte das Team nicht bedacht, und so ist es nötig, bereits abgeschlossene Tasks im laufenden Sprint zu refactoren. Der Scrummaster ist damit zunächst nicht einverstanden, und bespricht mit dem technischen Projektleiter, wie damit umzugehen wäre – und sie einigen sich darauf, dass das Refactoring notwendig ist, damit die Tasks der Definition of Done genügen.

Definition of Done

  • Alle Balken sind nach den Vorgaben des technischen Projektleiters lackiert
  • Die Balken sind nach dem Lackieren wieder genauso gestapelt wie vor dem Lackieren

Die zwei Spezialisten im Team machen sich also sofort daran, die notwendigen Refactorings vorzunehmen. Der Scrummaster versichert sich beim Team, ob der Scope des Sprints trotzdem noch geschafft werden kann. Das Team ist sich sicher, den Scope trotzdem zu halten, da das Refactoring das Team nicht allzu lange aufhalten sollte.

Sprintabschluss und Review

Nach 6 Stunden mit 5 Personen ist die Story und der Sprint abgeschlossen. Pünktlich zum Sprintabschluss kommt der technische Projektleiter, um zusammen mit den Productownern eine Abnahme zu machen. Alle Aufgaben wurden erledigt und genügen der Definition of Done.

Das Scrum-Team hat einen weiteren Sprint erfolgreich abgeschlossen.

Retrospektive

Das Team veranstaltet eine letzte Retrospektive (Abendessen mit Hendl, Kartoffeln und Weißbier) und diskutiert die vergangenen Sprints. Das Team bemerkt vor allem, dass durch den letzten Sprint (das Streichen der Bretter) ein sehr guter Teamzusammenhalt entstanden ist und alle gemeinsam darauf hinarbeiten, das Sprintziel zu erreichen.

Der Projektleiter und die Product-Owner informieren das Team, dass die nächsten Sprints wieder von externen Teams (Bauarbeiter und Zimmerer) durchgeführt werden, dass aber mit Sicherheit schon sehr, sehr bald wieder die Schlagkraft des gut eingespielten internen Teams gebraucht wird.

Nachtrag:

Inzwischen hat das externe Scrum Team (Gerhard, der Zimmerermeister mit seinem eingespielten Team) nachgearbeitet und hat die vorbereiteten Bretter und Balken in einem Sprint von 6 Tagen in einen voll funktionierenden Dachstuhl verwandelt, das Projekt scheint relativ stabil zu sein. Ich gehe davon aus, dass das Team Test-Driven gearbeitet hat, weitere Refactorings sind derzeit nicht eingeplant.

 

 

 

 

 

 

 

 

 

 

 


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