Planning Pattern II – Test Driven Sprint Planning

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks
Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen
Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

Planning Pattern I – Planen für den Flow

In dieser Artikelreihe möchte ich einige Pattern vorstellen, die agilen Teams helfen können, die Ergebnisse ihrer Sprint Plannings zu optimieren. Die meisten der Pattern sind bei der Arbeit mit Scrum Teams entstanden, sie lassen sich aber auch gut für Extreme Programming oder Kanban adaptieren.

20 Tasks am Board
20 Tasks am Board

Vor einigen Jahren kam ich als neuer Scrum Master zu einem Team, das schon eine geraume Weile zusammenarbeitete. Das Team arbeitete mit 2-Wochen-Sprints, hatte ein dreispaltiges Scrum Board, also auf den ersten Blick nichts außergewöhnliches. Allerdings hatte das Team in den letzten drei Sprints sein Commitment nicht geschafft. Was mich erstaunte, denn Aufgaben erschienen mir durchaus im Bereich des Machbaren und das Team war fit.

Als neuer Scrum Master halte ich mich immer erst mal mit Kommentaren zurück und beobachte viel. Beim Sprint Planning war ich dann erstaunt, dass das Team fast einen ganzen Tag dafür aufwendete und am Ende lediglich 20 Tasks am Scrum Board klebten. Ich fragte das Team also, ob sie sich sicher seien, dass das so ok war. Das Team meinte, ja, das wäre OK so. Es kam, wie es kommen musste – der Sprint lief schief, weil sich die Teammitglieder die ganze Zeit nur gegenseitig auf den Füßen standen und Tasks ewig „In Progress“ waren.

In einer Retrospektive konfrontierte ich das Team mit der Idee, dass ein Task nicht länger als einen Tag dauern sollte. Diese Idee kommt ja nicht von ungefähr, sie ist der Garant für einen guten Flow während des Sprints. Wir diskutierten eine ganze Weile darüber und schließlich kam eine recht interessante Betrachtung dabei heraus:

  • 1 Task <= 1 Tag
  • 1 Sprint = 10 Tage
  • 1 Team = 7 Personen
  • 1 Person benötigt >=10 Tasks (folgt aus (1) & (2))
  • 7 Personen benötigen >=70 Tasks (folgt aus (3) & (4))

Eines der Teammitglieder war Physiker und konnte das auf diese Weise kompakt zusammenfassen. Ein Team mit sieben Personen benötigt für einen 2-Wochen-Sprint mit 10 Arbeitstagen mindestens 70 Tasks am Scrum Board, um sicherzustellen, dass ein Task nicht mehr als einen Tag in Anspruch nimmt.

Diese Erkenntnis ist auch bereits das erste Planning Pattern:

Schneide die Tasks so, dass ihre Anzahl mindestens der Anzahl der Arbeitstage im Sprint multipliziert mit der Anzahl der Teammitglieder entspricht.

200 Tasks am Board
200 Tasks am Board

Das Team nahm die Herausforderung an und beim nächsten Planning befanden sich statt 20 plötzlich fast 200 Tasks auf dem Scrum Board. Nach einer Weile hat sich die Menge der Tasks auf 90 bis 120 Tasks pro Sprint eingependelt. Die kleinen Aufgaben führten zu einer sehr entspannten und kontinuierlichen Abarbeitung während des Sprints – das Team hatte seinen Flow gefunden. Ein angenehmer Nebeneffekt war, dass das Sprint Planning sich drastisch verkürzte.

Dieser Artikel erschien zuerst im adesso Blog.

Doch, das geht schon so. Eine Lanze für agile Job-Titel.

Im Laufe der Woche kam ein Artikel von Patrick Koglin in meinem Newsreader reingeflogen. Patrick beschreibt die Verwendung von Bezeichnungen wie Senior Scrum Master oder Junior Scrum Master als schlimm. Ich lese Patricks Artikel gern und teile seine Meinung häufig, aber in diesem Fall muss ich vehement mein Veto einlegen.

Zunächst der Aspekt, in dem ich dem Artikel zustimme: Nur, weil ein Board im Raum steht, bin ich nicht agil. Agil ist eben nicht Cargo Cult, sondern eine echte Kultur, ein Mindset. Ebenso denke ich, dass in einem agilen Team einem jungen Entwickler ebenso zugehört werden muss, wie der erfahrenen Kollegin und beide auf Augenhöhe zusammenarbeiten sollten. Gleiches gilt für Scrum Master, Product Owner und jeden Manager. Sowohl innerhalb eines Teams als auch in der Umwelt.

Dafür muss ich aber nicht agil sein, das ist schlicht und einfach der Respekt vor anderen Menschen, der diese Sichtweise gebietet.

Der Aspekt, bei dem ich grundlegend anderer Meinung bin, ist, dass es keine Senior oder Junior Scrum Master als Job-Bezeichnung geben darf. Ich bin der Meinung, dass so etwas völlig ok ist und viele Organisationen es sogar unbedingt benötigen. Ich zitiere gerne Tucholsky mit  „Erfahrung bedeutet nichts, man kann eine Sache auch dreißig Jahre lang schlecht machen.“ Für mich bedeutet das, dass Bezeichnungen wie Senior nicht an das Dienstalter gekoppelt sein dürfen.

Menschen orientieren sich an solchen Bezeichnungen, sie sind Teil der Struktur einer Organisation. Wenn ich dieses Argument aus dem Hut ziehe, kommt meistens das Gegenargument, dass in solchen Organisationen die Kultur kaputt sei. Und das ist  in meinen Augen schlimm.

Ich finde es völlig ok, zwischen Junior und Senior Scrum Mastern zu unterscheiden. Der Junior Scrum Master ist einer, dem ich helfe, großartig zu werden. Der Mensch ist es schon, der Scrum Master muss einiges erleben. Und damit der Scrum Master das kann, bekommt er Unterstützung von einem Senior, der schon war, wo der Junior noch hin will. So einfach ist das.

Und ja, ich finde es absolut gerechtfertigt, wenn jemand stolz darauf ist, ein Senior Scrum Master zu sein und sich diese Bezeichnung verdient hat, indem er ganz viele Teams großartig gemacht hat und jede Menge unerfahrene Scrum Master an seinem Wissen und Können hat teilhaben lassen. Das ist Agilität.
Die Ablehnung von Job-Titeln aus Prinzip ist hingegen Cargo Cult.

Einheit Story Points?

Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.
Einheit Story Points? weiterlesen

User Stories der Größe 1

Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.
User Stories der Größe 1 weiterlesen

Schätzereien

Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.
Schätzereien weiterlesen

Eine Lanze für Junior ScrumMaster

Zu Zeiten in denen ich als ScrumMaster von Team zu Team durch die Welt reiste, war eine Frage, die mir häufig begegnete:
Wieviel Entwicklungserfahrung haben Sie denn?

Ich fand das immer seltsam. Viel interessanter wäre doch die Frage gewesen:
Wieviele Teams sind mit Ihnen erfolgreich agil geworden?

Aus irgendeinem Grund regiert aber der Glaube, ScrumMaster müssten erfahrene Entwickler sein. Das habe ich auch in vielen Unternehmen, die ich begleitet habe, erlebt. Der Karrierepfad eines ScrumMasters begann in der Regel erst, wenn man bereits Senior Entwickler war. Dabei sind die Fähigkeiten eines Senior Entwicklers völlig andere als man die für die Rolle des ScrumMasters benötigten.
Eine Lanze für Junior ScrumMaster weiterlesen

Vortrag auf den Agile Testing Days 2013

Gestern hielt ich einen Vortrag auf den Agile Testing Days.
Das Thema war: Planning Pattern for Agile Testers.

In den letzten Jahren habe ich bei einger ganzen Reihe von Teams einige Pattern entdeckt, die bei der Integration von Testern in agilen Teams hilfreich sind.
Sehr oft stehen Teams vor dem Problem, dass die üblicherweise gelehrten Ansätze der Testplanung und des Testmanagements im agilen Kontext nicht funktionieren.
Um Teams diesbezüglich zu helfen, habe ich die Verhaltensweisen, die ich mit einger ganzen Reihe von Teams entwickelt habe, als Pattern beschrieben.

Die Folien stehen wie üblich auf Slideshare:

Vortrag auf den Agile Testing Days

Für die Saxonia Systems AG halte ich auf den Agile Testing Days in Potsdam am 30.10.2013 einen Vortrag zum Thema „Planning Patterns for Agile Testers“.

Inhalt ist die Frage, wie Tester im Spring-Planning und in der Release-Planung optimal beitragen können.
Dazu werde ich einige Pattern vorstellen, die ich im Laufe der Jahre in verschiedenen Teams gesammelt habe und die sich mehrfach bewährt haben.

Es wird deutlich werden, dass sich Tester nicht auf das pure Testen von Software anhand von Akzeptanzkriterien beschränken müssen, sondern dass sie durch ihren kritischen Blick weitaus mehr leisten können – wenn das Team das denn möchte.

Agile Workshop 2013 in Bishkek

Bereits 2012 habe ich, gemeinsam mit Sven Koble, einen Workshop zu Agiler Softwareentwicklung in Bishkek veranstaltet.
Das Feedback war ausgesprochen positiv, daher habe ich mich entschieden, den Workshop in diesem Jahr zu wiederholen.

Er wird im Zeitraum vom 16. bis 28. September in den Räumen der KSUCTA stattfinden. Insgesamt werden für den Workshop 8 Tage zur Verfügung stehen. Da im letzten Jahr die Sprachkenntnisse eines der größten Hindernisse darstellten, habe ich mir überlegt, den Workshop in zwei Schichten anzubieten. Vormittags wird der Workshop in Englischer Sprache stattfinden, am Nachmittag auf Deutsch.

Für alle Neugierigen habe ich hier ein paar Impressionen aus 2012 zusammengestellt:

Diese Diashow benötigt JavaScript.


Die Fotos wurden alle von Sven Koble gemacht.