Scrum und Kanbanvortrag in den Softwareforen Leipzig

Mittwoch, 14. April 2010 von  
unter News

Auf dem 3. Arbeitstreffen der User Group „Agile Methoden in der Softwareentwicklung“ der Softwareforen Leipzig wird Carsten Czeczine über Scrum und Kanban referieren. Weitere Information dazu gibt es hier.

Die „richtige“ Sprintlänge

Donnerstag, 11. März 2010 von  
unter Fachartikel Scrum

Eine Frage, vor der alle Scrumteams schon mal standen ist: wie lang soll die Sprintlänge sein?
Was durch die Bank hinweg die gesamte Scrumliteratur vorschreibt ist, dass die Länge der Sprints zumindest über einen gewissen Zeitraum hinweg fix sein soll. Die Länge der Sprints will damit also im Vorhinein schon mal gut überlegt sein.

Stöbern wir durch die Bücher von Ken Schwaber oder durch verschiedene Artikel von Jeff Sutherland, dann stoßen wir da meist auf eine vorgeschlagene Länge von 30 Tagen. Bei Schwaber wird es nicht genauer erklärt, aber ich vermute mal, dass er mit diesen 30 Tagen einfach auf einen Kalendermonat abzielt, also ca. vier bis fünf Wochen und nicht auf 30 Werktage, was sechs Wochen ergeben würde. Etwas weiter geforscht ergibt sich aber scheinbar ein allgemeiner Konsense bei der Aussage, ein Sprint sollte zwischen einer bis vier Wochen lang sein.

Aber was bedeutet das jetzt für uns, wenn wir unser Projekt neu aufsetzen und die Sprintlänge festlegen wollen? Wann nehmen wir eine Woche? Wann vier? Und wann irgendwas dazwischen? Damit wollen wir uns in diesem Artikel befassen.

Rufen wir uns erstmals in Gedächtnis zurück, warum wir in Scrum überhaupt mit Iterationen arbeiten: Wir wollen in einem definierten Zeitraum ein in sich sinnvoll abgeschlossenes Ergebnis erreichen, das sogenannten potentiell auslieferbaren Produktinkrement.
Vielen Neueinsteigern in Scrum fällt es schwer, sich vorstellen zu können innerhalb einer Woche ein sinniges in sich abgeschlossenes Produktinkrement erstellen zu können. Dadurch geht die Tendenz eher zu längeren Sprints. Gleichzeitig scheinen sich aber mittlerweile in vielen Unternehmen die Prioritäten von Anforderungen im Stundentakt zu ändern, meist weil ständig neue und natürlich wichtigere-wie-alles-andere Anforderungen auftauchen. Die manchmal fast schon panisch anmutende Angst, irgendwelche Markttendenzen verpassen zu können und deshalb möglichst innerhalb von Stunden auf neue Erkenntnisse oder Vermutungen reagieren zu wollen, kann Projektverantwortliche schon mal in den Wahnsinn treiben und drückt die angestrebte Sprintlänge wieder nach unten.

Wir sehen uns scheinbar einem Zielkonflikt gegenüber und das alleine macht schon deutlich, dass es auf die Frage der richtigen Sprintlänge keine Pauschalantwort gibt.

Versuchen wir die Faktoren mal einzeln zu betrachten, sodass jeder von Ihnen die Möglichkeit hat, seine aktuelle oder zukünftige Projektsituation unter den einzelnen Gesichtspunkten zu bewerten.

Fangen wir mit der Frage an, was bedeutet eine möglichst kurze Sprintlänge für ein Projekt?
Zuerst fällt positiv auf, dass wir mit einer kurzen Sprintlänge auch eine recht kurze Reaktionszeit auf geänderte Anforderungen haben. Wenn wir die Regeln von Scrum hart spielen und der Sprint damit gegen Änderungen von außen geschützt ist, dann beträgt die durchschnittliche Reaktionszeit auf geänderte Umstände die Hälfte der Sprintlänge. Bei einer Sprintlänge von einer Woche also 3 ½ Tage.
Als nächstes Sticht der Umstand ins Auge, dass in einen kurzen Sprint natürlich auch nur entsprechend wenige Anforderungen passen und diese außerdem auch entsprechend klein sein müssen. An der Bewertung, ob dies positiv oder negativ ist, scheiden sich die Geister und es hängt auch von den Projektumständen ab. Es mag tatsächlich Projekte geben, in denen Anforderungen nicht auf die erforderliche Maximalgröße runter gebrochen und dann noch isoliert voneinander umgesetzt werden können. Objektiv ist das allerdings wirklich nur selten der Fall.
Eine kurze Sprintlänge zwingt den Produkt Owner und das Team auf jeden Fall zu einer klaren Fokussierung auf ein oder maximal zwei Ziele pro Sprint, weil ansonsten in der kurzen Zeit vermutlich keine in sich sinnvoll abgeschlossenen Features zu realisieren sind. Dementsprechend sind auf den Sprint Reviews auch selten die großen Würfe zu erwarten, dafür aber ständig neue Verbesserungen, Erweiterung, neue Features. Bei kurzen Intervallen wirkt dies wie ein kontinuierlicher Strom an Fortschritt.

Eher anspruchsvoll um nicht zu sagen schwierig ist bei kurzen Sprintlängen jedoch die Entwicklung einer größeren und investitionssicheren Systemarchitektur. Hier steigen die Anforderungen an gute Architekturvorgaben und an einen sauberen Programmierstil, wenn die Systemarchitektur nicht jede Woche neu erfunden oder völlig aus dem Runder laufen soll. Dementsprechend müssen hierfür im Team auch die entsprechenden Skills vorhanden sein oder bewusst aufgebaut werden. Darüber, wie auch in kurzen Sprints saubere Architektur entstehen und erhalten bleiben kann und was dafür notwendig ist, werde ich in einem anderen Artikel schreiben, wenn wir uns mit inkrementeller Architektur befassen.

Das führt uns direkt zur Betrachtung von langen Sprintlängen. Welche Auswirkungen haben diese auf ein Projekt?
Wenn wir bei einer kurzen Sprintlänge die kurze Reaktionszeit gelobt haben, dann ist sofort klar, dass dies bei langen Sprintlängen nicht mehr so ist. Bei einer Sprintlänge von vier Wochen beträgt die durchschnittliche Reaktionszeit jetzt schon 2 Wochen! Dass kann Stakeholder mit vermeintlich dringenden Begehren schon mal ein bisschen ungeduldig werden lassen.
Umgekehrt bietet die lange Sprintdauer aber auch viel Raum für Anforderungen. Dass soll aber dennoch nicht davon ablenken, dass auch hier klare Sprintziele mit Schwerpunkten für jeden einzelnen Sprint gesetzt werden sollen. Bitte behalten Sie das im Auge, die Gefahr ist sonst groß, dass sich das Team bei der Umsetzung der Anforderungen verzettelt und durch den fehlenden Fokus viel an Energie verloren geht.
Die kurzen Sprints erfordern, das Anforderungen knapp und knackig sein müssen, um in die Sprints zu passen und dafür müssen sie ziemlich präzise beschrieben sein, damit überhaupt abgeschätzt werden kann, ob sie in einen Sprint passen. Die langen Sprints verleiten leicht dazu, diese Präzision zu vernachlässigen, da die Anforderung schon irgendwie passen wird. Das rächt sich aber relativ schnell und deshalb muss auch bei langen Sprints die gleiche Sorgfalt auf die präzise Beschreibung der Anforderungen gelegt werden. Zumindest für die Anforderungen, die in einen Sprint eingeplant werden sollen.
Viel Platz für Anforderungen bedeutet aber auch die Möglichkeit, größere zusammenhängende Teile der Systemarchitektur in einem Stück planen und umsetzen zu können. Es ist also leichter, die Systemarchitektur aufzusetzen und Grundlagen zu schaffen. Und natürlich ist es ein schönes Gefühl in jedem Sprint Review nicht bloß ein zwei Kleinigkeiten sondern gleich einen großen Batzen an Neuerungen im Produkt zeigen zu können. Das dafür aber auch nur alle vier Wochen.

Hm, alles recht interessante Gesichtspunkte, aber so zwingend hilft das noch nicht weiter, zumindest nicht in allen Fällen. Betrachten wir ein paar einzelne Gesichtspunkte etwas genauer.

Bei kurzen Sprintlängen stellt sich die Frage des Overheads bzgl. der Meetings. Wir erinnern uns, in Scrum haben wir mit dem Sprint Planning, dem Sprint Review und der Sprint Retrospektive drei Regelmeetings, die einmal pro Sprint abgehalten werden. Bei einwöchigen Sprints wären das zwischen 12 und 15 Meetings im Monat, bei vierwöchigen Sprint halt genau 3. Klingt erst mal nach erheblichen Overhead bei kurzen Sprints. Allerdings darf man nicht vergessen, dass bei kurzen Sprints auch die Meeting wesentlich kürzer sein können, da ja nur der Inhalt einer wesentlich kürzeren Zeitperiode besprochen werden muss. Sollten Sie in Ihrem Team die Disziplin haben, Meetings nicht länger zu gestalten, wie wirklich notwendig ist, dann ist die höhere Anzahl an Meetings pro Monat kein Hinderungsgrund für kurze Sprintlängen. Ufern bei Ihnen jedoch Besprechungen grundsätzlich aus ohne dass Sie das einschränken können, dann wäre eher eine längere Sprintdauer zu empfehlen, bei der Sie dann weniger Meetings pro Monat haben.

Ein Punkt, den wir schon angesprochen hatten ist die Reaktionszeit auf Änderungen in den Anforderungen bzw. die Neupriorisierung von Anforderungen. Ich glaube ich habe es mal in einem der Bücher von Ken Schwaber gelesen, die entscheidende Frage bezüglich der Sprintlänge war: Wie lange kann der Product Owner den Mund halten? Übersetzt bedeutet das, wie lange kann der Product Owner das Team vor der Einflussnahme durch Stakeholder schützen? Wenn die Geschäftsführung regelmäßig neue Ideen ausbrütet, die natürlich immer wichtig sind und deshalb aus Sicht der Geschäftsführung immer sofort gemacht werden sollen, wie lange kann der Product Owner diese Stakeholder bremsen beziehungsweise wie viel Geduld und Verständnis für die Belange des Softwareentwicklungsprozesses bringen die einflussreichsten Stakeholder auf. Ist es diesen Stakeholder verständlich zu machen, dass neue Ideen und Anforderungen nur alle vier Wochen in Angriff genommen werden können oder bestehen die Stakeholder trotz aller Erklärungen auf möglichst sofortige Berücksichtigung ihrer Anforderungen?

Und jetzt zum nächsten Knackpunkt.
Es ist ja schön, wenn wir in der Lage sind Anforderungen in kleine, voneinander unabhängige und präzise beschriebene Pakete zu zerlegen, unsere Meeting kurz und effizient zu halten und auch trotz kürzester Sprintlänge eine vorbildliche Systemarchitektur planen und aufbauen zu können. Wert hat das Ganze aber nur dann, wenn am Ende jedes Sprints ein potentiell auslieferbares Produktinkrement entsteht und dazu gehört nach den Definitionen von Scrum auch, dass der produzierte Code getestet ist. Natürlich ist jedes Team selber für seine „Definition of done“ verantwortlich und damit kann der Anspruch, was als potentiell auslieferbar gilt natürlich auch beliebig weit nach unten gedrückt werden. Aber sinnvoll ist das nicht! Bei der Wahl der Sprintlänge ist also auch zu berücksichtigen, in welchem Zeitraum neue Funktionen sinnvoll getestet werden können. Ein möglichst hohes Maß an Testautomatisierung und eine ständig verfügbare Test- und Integrationsumgebung verkürzen den notwendigen zeitlichen Aufwand und ermöglichen so kürzere Sprintlängen. Aber überall da, wo manuelle Test notwendig oder Testumgebungen nicht ständig verfügbar sind (aus welchen Gründen auch immer), überall da ist bei der Planung der Sprintlänge zu berücksichtigen wann die für die Test erforderlichen Ressourcen zur Verfügung stehen. Idealerweise sind Tester aus der Fachabteilung fester Bestandteil des Teams und zu 100% für diese Tätigkeit eingeplant, aber wo sind die Bedingungen für ein Projekt schon ideal. Wenn mir meine Tester nur alle vier Wochen für jeweils fünf Tage zur Verfügung stehen, dann kann ich keine zweiwöchigen Sprints fahren, denn wie will ich im jeweils zweiten Sprint testen?
Das Gleiche gilt auch für das Sprint Review. Inhalt des Sprint Reviews ist es, dem Product Owner und den Stakeholdern die Ergebnisse des Sprints zu präsentieren. Dabei geht es dem Team nicht bloß darum, sich im Lichte seiner Leistungen zu sonnen, obwohl das natürlich auch schön ist. Nein, ein wichtiges Ziel des Sprint Reviews ist das direkte Feedback von Product Owner und Stakeholder darüber, ob die neuen Funktionen oder Korrekturen in Art und Umfang dem entsprechen, was sich die Stakeholder vorgestellt hatten oder auch nicht. Dieses Feedback ist wichtig für die ständige Verbesserung des Entwicklungsprozesses und auch für evtl. Kurskorrekturen bei der Priorisierung der nächsten Anforderungen. Bei einer einwöchigen Sprintdauer bedeutet das aber auch, dass jede Woche zumindest einige Stakeholder die Zeit für das Sprint Review haben müssen. Ist das dauerhaft nicht der Fall, dann ist fraglich ob die einwöchige Sprintlänge wirklich Sinn macht.

Ein in meinen Augen eher kosmetischer Punkt, den wir hier aber dennoch nicht verschweigen wollen sind die Auswirkungen der Sprintlängen auf die Schwankungen in der Velocity eines Teams. Um sowohl für die Planung der nächsten Sprints wie auch für die grobe Releaseplanung eine Vorstellung über die zukünftige Entwicklungsgeschwindigkeit zu haben, halten wir für jeden abgelaufenen Sprint die Anzahl der erledigten Aufwände fest. Das können Story Points sein oder auch ideale Tage oder Gummibärchen, wie wir sie in meinem aktuellen Projekt gerne nennen. Daraus bilden wir einen Chart, der uns die Entwicklung der Entwicklungsgeschwindigkeiten graphisch aufbereitet und uns eine Prognose für die zukünftige Entwicklungsgeschwindigkeit ermöglichen soll.
Jetzt ist aber zu beachten, dass ein plötzlicher Ausfall eines Mitarbeiters für einen Tag, z.B. durch Krankheit, die Velocity eines kurzen Sprints wesentlich stärker beeinflusst wie die eines langen Sprints. Und bei langen Sprints besteht auch eine größere Wahrscheinlichkeit, dass in jedem Sprint mal jemand überraschend einen Tag ausfällt. Das heißt, die Velocity wird in längeren Sprints eher gleichmäßiger ausfallen als in kurzen.

Spielt das eine Rolle? Ich denke nicht. Auf dem Chart sehen die vermutlich stark unterschiedlichen Entwicklungsgeschwindigkeiten bei kurzen Sprintlänger zwar etwas wild aus, für die Berechnung eines Trends ergeben sich aber keine echten Unterschiede. Dieser Punkt ist also eindeutig zu vernachlässigen.

Kommen wir zurück zum Anfang, unserer Problemstellung, wie lang soll die Sprintlänge für unser neues Scrumprojekt sein. Sind wir da wirklich weitergekommen? Vielleicht ja. Möglichweise ist einer der Umstände, die wir gerade beschrieben haben der Schlüsselfaktor. Die schnelle Reaktionszeit, die unsere Stakeholder von uns verlangen oder die fehlenden Testkapazitäten. Dann kann daran die, ich nenne sie mal „initiale“ Sprintlänge festgemacht werden. Wenn aber keiner dieser Faktoren so deutlich ins Auge sticht oder einfach noch nicht bekannt ist, nun dann trifft man einfach eine Annahme und startet damit.

Ich hatte am Anfang davon gesprochen, dass die Sprintlänge zumindest über einen gewissen Zeitraum hinweg fix sein soll. Hintergrund ist, dass damit ein gewisser Flow geschaffen werden soll, in dem sich hilfreiche Abläufe einschleifen und den Entwicklungsprozess einfach und stabil halten sollen. Bei jedem Sprint die Dauer des Sprint zu ändern, würde dem im Wege stehen. Das bedeutet aber eben nicht, dass die Dauer der Sprints einmal festgelegt wird und dann nie wieder verändert werden darf. Scrum ist eine agile Methodik und einer der Grundpfeiler ist und bleibt „inspect and adapt“ und das gilt auch für die Sprintlänge. Einfach mal mit was starten, sehen wie es läuft und bei Bedarf anpassen.

Meine Empfehlung für die ersten Sprints: Wenn das Team neu in Scrum ist oder die Skills für inkrementelle Architektur nicht vorhanden sind oder das Testen größtenteils noch manuell erfolgt und auch andere Faktoren im Testen noch nicht optimal sind, dann als initiale Sprintlänge vier Wochen wählen. Dabei aber kontinuierlich daran arbeiten, die Bedingungen für kürzere Sprintzeiten zu verbessern, d.h. die Grundlagen in inkrementeller Architektur zu schaffen, die Tests zu automatisieren, ständig verfügbare Testumgebungen aufzubauen und so weiter. Und dann nach und nach die Sprintlängen alle paar Monate um eine Woche zu reduzieren. Dabei ist für mich persönlich der Einwochensprint nicht zwingend das Endziel. In vielen Fällen pendeln sich Scrumprojekte bei einem Zweiwochenzyklus ein, das scheint ein guter Kompromiss zwischen den beiden Extremwerten zu sein. Aber schussendlich muss jedes Projekt seinen eigenen Zyklus finden.

Kanbanvortrag auf dem ScrumDay 2010

Dienstag, 23. Februar 2010 von  
unter News

Auf dem ScrumDay 2010 wird Carsten Czeczine am 5. Mai einen Vortrag über Kanban halten. Mehr Infos dazu gibt es hier.

Das Kano-Modell der Kundenzufriedenheit

Donnerstag, 31. Dezember 2009 von  
unter Fachartikel Scrum

In meinem Artikel „Prioritäten von Anforderungen – Kategorie oder Reihenfolge“ hatte ich mehrfach Bezug auf das Kano-Modell der Kundenzufriedenheit genommen ohne dieses dabei näher zu erläutern. Diese fehlende Erläuterung möchte ich hier nun nachholen.

Die meisten von uns, die sich schon mal mit Produkt- oder Anforderungsmanagement auseinandersetzen durften oder immer noch dürfen, kennen das Problem der Entscheidung: In welcher Reihenfolge sind Anforderungen umzusetzen bzw. welche sind überhaupt umzusetzen. Selten mangelt es an Anforderungen an das, was ein zu erstellendes Produkt alles können soll, unzählige Interessenvertreter haben ihre eigenen Vorstellungen davon, was absolut unverzichtbar ist und damit auf jeden Fall umgesetzt werden muss. Und zwar immer als allererstes!

Das Kano-Modell versucht hierbei Licht ins Dunkel zu bringen und dem armen Entscheider, der es allen Recht machen und am Ende aber auch die Verantwortung für den Erfolg des Produktes tragen muss ein Werkzeug an die Hand zu geben, dass in diesem Wirrwarr die Streu vom Weizen trennt und für die Entscheidung, was wann umgesetzt wird eine nachvollziehbare Grundlage schafft. Damit ist aber auch direkt klar, was das Kano-Modell nicht macht: Es unterstützt nicht bei der Erhebung der Anforderungen. Um diesen teilweise unübersehbaren Pool an Anforderungen zu generieren, müssen also andere Techniken verwendet werden, die in diesem Artikel jedoch nicht besprochen werden (vielleicht lasse ich mich hierzu ja auch demnächst zu einem Artikel hinreißen).

Zum geschichtlichen beschränke ich mich auf den Hinweis, dass das Kano-Modell auf Prof. Dr. Noriaki Kano von der Universität Tokio zurückgeht. Mehr historisches dazu interessiert zumindest mich derzeit nicht.

Also zurück zum Handwerklichen oder besser erst mal zu einer ganzen Reihe von Definitionen.

Als erstes müssen wir festhalten, dass im Kano-Modell nicht von Anforderungen sondern von Produktmerkmalen gesprochen wird. Anforderungen sollten sich in der Regel auf Produktmerkmale beziehen, d.h. sie „fordern an“, dass das Produkt ein bestimmtes Merkmal aufweist bzw. nicht aufweist. Ein Produktmerkmal selber ist eine für den Kunden spürbare Eigenschaft des Produkts, also z.B. dass er sich anmelden kann. Und unter Kunden verstehen wir hier den Personenkreis, der mit unserem neuen Produkt umgehen muss bzw. es kaufen soll.

Jetzt wieder zurück zum Kano-Modell. Dort werden Produktmerkmale in fünf Kategorien aufgeteilt:

Basis-/Must-Have Merkmal: Basismerkmale eines Produktes sind so grundlegend und selbstverständlich, dass sie dem Kunden erst bei Nichterfüllung bewusst werden. Werden sie aber nicht erfüllt, dann entsteht nicht unerhebliche Unzufriedenheit. Umgekehrt entsteht aber bei Erfüllung nicht wirkliche Zufriedenheit. Ein Beispiel hierfür kann die Möglichkeit zur Anmeldung an eine Software sein.

Lineares-/Leistungsmerkmal: Lineare Merkmale sind dem Kunden durchaus bewusst und sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung. Ein Beispiel hierfür ist die Performance eines Softwareprodukts.

Begeisterungsmerkmal: Begeisterungsmerkmal sind Nutzen stiftende Merkmale, mit denen der Kunden nicht unbedingt rechnet. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einer überproportionalen Nutzenstiftung führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, die Nutzenstiftung aber dennoch enorm.

Unerhebliches Merkmal: Sind sowohl bei Vorhandensein wie auch beim Fehlen ohne Belang für den Kunden. Sie können daher keine Zufriedenheit stiften, führen aber auch beim Fehlen nicht zu Unzufriedenheit.

Rückweisungsmerkmal: Rückweisungsmerkmale führen beim Vorhandensein zu Unzufriedenheit, beim Fehlen jedoch nicht zu Zufriedenheit. Ein Beispiel hierfür wäre ein Kopierschutz.

Soweit so gut, ich habe jetzt also auf der einen Seite fünf Kategorien und auf der anderen einen Sack voll mit Anforderungen. Aber wie ordne ich jetzt meine Anforderungen in diese fünf Kategorien ein? Eine Möglichkeit wäre, dass ich als der Produktverantwortliche dieses anhand der Beschreibungen oben jetzt selber mache. Dafür muss ich aber die zukünftigen Kunden und deren Bedürfnisse schon ziemlich genau kennen und die Wahrscheinlichkeit, dabei des Öfteren mal daneben zu liegen dürfte recht hoch sein.

Besser also, ich frage die potentiellen Kunden selber und zwar möglichst viele davon. Aber auch hier die Frage, nach welchen Kriterien ist eine Anforderung einer der fünf Kategorien zuzuordnen. Die Beschreibungen oben sind verhältnismäßig dürftig, dürften von jedem etwas anders verstanden werden und darüber hinaus ist dies schon eine recht anspruchsvolle und komplexe Tätigkeit. Ich will damit nicht sagen, dass alle Endkunden zu … äh … damit überfordert wären, aber machen wir uns nichts vor, gerade wenn ich eine größere Gruppe von Personen zu etwas befragen möchte, dann sinkt die Qualität des Ergebnisses mit der steigenden Komplexität der Fragestellung.

Das Kano-Modell geht deshalb einen anderen Weg, den einer biopolaren Befragung. Jeder Proband wird zu jedem Merkmal jeweils mit einer funktionalen und einer dysfunktionalen Frage konfrontiert oder verständlich ausgedrückt, er soll zu jedem Merkmal mitteilen, wie er es fände, wenn es vorhanden ist und wie, wenn es fehlt.

Als Antwortmöglichkeiten stehen ihm für beide Fragen zur Verfügung:

– Ich mag es genau so
– Ich erwarte, dass es so ist
– Mir egal
– Ich kann damit leben
– Das stört mich

Super, jetzt habe ich pro Merkmal sogar zwei Antworten von einem Probanden, wie soll ich denn daraus jetzt zu meiner Kategorie kommen? Hier kommt die Magic des Kano-Modells ins Spiel und zwar in Form der Antworten-Kategorien-Matrix.

Antworten-Kategorien-Matrix des Kano-Modells

Wir finden in dieser Matrix in den Schnittmengen der möglichen Antworten auf die beiden Fragen alle unsere fünf Kategorien wieder plus zweimal eine unlogische Kombination. Bei dieser Antwortenkonstellation scheint irgendwie der Sinn der Fragestellungen abhanden gekommen zu sein. Entweder ignorieren oder die Frage nochmal stellen und dabei nochmal den Schwerpunkt auf das Verständnis der Fragestellungen legen.
Aus den Antworten auf die beiden Fragen eines Probanden kann nun also die Kategorie einfach abgelesen werden. Und machen wir nun nicht nur einmal sondern pro Produktmerkmal fragen wir möglichst viele potentielle Kunden und halten das Ergebnis tabellarisch fest. In der Tabelle unten habe ich mal ein Beispiel dafür erstellt. Wir haben drei Merkmale befragt und die Verteilung der Zielkategorien der einzelnen Befragungen prozentual in einer Tabelle zusammengefasst.

Beispiel der Auswertung

Bei dem Produktmerkmal 1 haben wir mit 43,8% eine eindeutige Spitze für lineares Merkmal, bei dem Produktmerkmal 2 mit 54,3% eine eindeutige Spitze für Basismerkmal. Beim Produktmerkmal 3 jedoch haben wir zwei Spitzen, einmal 36,6% für Basismerkmal und dann nochmal 39,1% für Begeisterungsmerkmal. Dies kann darauf hindeuten, dass wir zwei unterschiedliche Arten von Kunden für unser Produkt haben, die unterschiedliche Erwartung an unser Produkt hegen. Hier macht es Sinn, sich klarzumachen, welche unterschiedlichen Kundenarten das sind und anschließend festzulegen, auf welche von beiden Kundenarten wir mehr fokussieren wollen.

Kommen wir zurück zu unserer Ausgangssituation, wir sind ein armer Produktverantwortlicher und alle Interessenvertreter haben uns mit Unmengen an Anforderungen zugeschüttet. Wir haben aus (fast) all diesen Anforderungen Produktmerkmale extrahiert und diese durch das Kano-Modell in Kategorien eingeordnet. Ist damit jetzt klar, welche Anforderungen bzw. Produktmerkmale umzusetzen sind und in welcher Reihenfolge?
Leider nicht so ganz. Fangen wir mit den einfachen Fällen an, die Rückweisungsmerkmale und die unerheblichen Merkmale. Das Kano-Modell priorisiert Produktmerkmale aus Sicht des Kunden und aus dieser Sicht sollte auf Rückweisungsmerkmale auf jeden Fall verzichtet werden und unerhebliche Merkmale sollten nur am Schluss umgesetzt werden, wenn noch Zeit und Geld da ist. Obwohl sie aus dieser Sicht eigentlich nur Resourcenverschwendung sind. Also besser auch nicht umsetzen. Allerdings bestimmen ja nicht immer nur die Kundenwünsche die Notwendigkeiten zu Produktmerkmalen. Bevor diese Merkmale also tatsächlich komplett gefeuert werden, erst noch prüfen was die Intention zu diesen Merkmalen war. Bei gesetzlichen Vorgaben oder technischen Notwendigkeiten kann die Welt schon ganz anders aussehen. Aber wenn nichts dergleichen zutrifft, raus damit, schlanke Produkte designen.

Kommen wir zu unserem Dreigestirn: Basis-, lineare und Begeisterungsmerkmale.
Mit Basismerkmalen gewinnt man keinen Blumentopf, wenn sie aber fehlen floppt wahrscheinlich das ganze Produkt. Also müssen sie wohl rein. Wie dringend sie rein müssen, also mit welcher Priorität verglichen mit den Linearen und Begeisterungsmerkmalen, hängt davon ab, wie ich die Release auf den Markt bringe. Wenn ich klassisch im Wasserfall arbeite und vermutlich nur alle 12 Monate ein neues Release rausbringe (oder sogar noch langsamer), dann müssen alle Basismerkmale bereits im ersten Release drin sein, denn die Kunden werden das Produkt solange nicht akzeptieren, wie die Basismerkmale nicht enthalten sind oder mit der baldigen Nachlieferung zu rechnen ist. Wenn ich dahingegen in wesentlich kürzeren Zeitabständen meine Releases ausliefere, z.B. jeden Monat oder alle zwei und dieses auch entsprechend kommuniziere, dann sind Kunden schon eher geneigt, dass Fehlen von Basismerkmalen für kurze Zeit in Kauf zu nehmen. Natürlich muss dass, was ich da ausliefere in sich funktionsfähig sein, alles andere wäre ja völliger Unsinn. Aber anstatt für den gesamten geplanten Funktionsumfang des Produktes erst mal nur die Basismerkmale zu ersten und auszuliefern und dem Kunden damit ein „ist ja ganz nett“ zu entlocken, fokussiert man nur einen bestimmten Funktionsbereicht und realisiert diesen mit seinen notwendigen Basismerkmalen plus weitere Lineare und Begeisterungsmerkmalen. Der Kunden gewinnt damit einen guten Eindruck dessen, was in nach und nach bei unserem Produkt erwarten wird und kann evtl. auch schon mit der Teilfunktionalität schon Mehrwerte für sich erzielen.

Wäre das mit den Basismerkmalen schon mal geklärt, aber wie gewichten wir lineare gegenüber Begeisterungsmerkmalen. Begeisterungsmerkmale sprechen oft sehr subjektives Empfinden gegenüber einen Produkt an und gewinnen in der Regel eher durch den Überraschungseffekt oder das Alleinstellungsmerkmal (das hat halt kein anderer so, deshalb ist es cool). Beides nutzt sich mehr oder weniger schnell ab. Lineare Merkmale dahingegen stellen meist tatsächliche Wehrwerte des Produktes für den Kunden dar, die meist auch auf Dauer erhalten bleiben.
Rein ökonomisch gesehen wären deshalb die linearen Merkmale den Begeisterungsmerkmalen vorzuziehen. Aber unsere Kunden sind alle Menschen und die Begeisterungsmerkmale sind es, die dann doch oft die Kaufentscheidung oder die Akzeptanzbereitschaft für unser Produkt stark beeinflussen. So gesehen ist die Entscheidung für Begeisterungsmerkmale irgendwie auch ökonomisch. Zumindest für den, der das Produkt verkauft :-).

Die gesunde Mischung macht es aus. Ein Produkt nur mit linearen Merkmalen ist zwar wertvoll, aber unsexy, ein Produkt nur mit Begeisterungsmerkmalen verleitet zwar zum schnellen Kauf aber nicht zur Nutzung. Ein guter Erfahrungswert ist, den Schwerpunkt auf lineare Merkmale zu setzen, damit der Kunden tatsächlich echten Mehrwert erhält und das mit einer Handvoll Begeisterungsmerkmale zu würzen, damit er sich auch für unser Produkt entscheidet bzw. die Nutzer das Produkt bereitwillig akzeptieren.

So, ich hoffe das hat ein bisschen Licht ins Dunkel gebracht. Die Quintessenz ist, das Kano-Modell bietet eine gute Unterstützung dabei, sich der Qualität von Anforderungen bewusst zu werden und sich aus der Vielzahl an Anforderungen auf die zu konzentrieren, die bei den Kunden gut ankommen werden. Es ist aber zum Leidwesen einiger kein Mechanismus, in den ich oben einfach alles rein kippe und unten kommt dann die fertige Reihenfolge heraus. Der gesunde Menschenverstand der Produktverantwortlichen ist immer noch erforderlich.

Und zumindest ich bin froh darüber!

Quellen:

Die Sprint Retrospektive

Montag, 14. Dezember 2009 von  
unter Fachartikel Scrum

Laut Wikipedia bezeichnet Retrospektive im Allgemeinen einen Rückblick. Dementsprechend ist eine Sprint Retrospektive ein Rückblick auf den gerade abgelaufenen Sprint.

Die Sprint Retrospektive findet nach dem Sprint Review, in dem die Sprint Ergebnisse präsentiert wurde statt und schließt damit den Sprint ab.Ziel der Retrospektive ist die Verbesserung des Scrum Prozesses. Und da wir in Scrum neben dem reinen Prozess auch Wert auf den sozialen Umgang zwischen allen Beteiligten legen, gehört auch dies mit in die Retrospektive.

„Der Inhalt“

Also, was wird in einer Sprint Retrospektive besprochen?

Beispiele:

– Arbeitet das Projekt erfolgreich?

– Werden die Sprintziele erreicht?

– Betrachtung der einzelnen Prozessschritte, wie z.B. das Daily Scrum oder der Sprint Review.

– Werden die Prozessschritte eingehalten?

– Sind die Ergebnisse der Prozesschritte das, was erwartet wurde?

– Welche Ergebnisse werden denn erwartet?

– Wenn Prozessschritte nicht durchgeführt werden, warum ist das so?

– Was müsste sich ändern, damit sie eingehalten werden? Oder besteht überhaupt die Notwendigkeit, sie einzuhalten.

Ganz klassisch kann hier z.B. auch darüber reflektiert werden, ob die Zeitfenster für die Prozessschritte noch angemessen ist. Wenn das Sprint Planning Meeting zum Ende hin immer hektisch wird, weil die Zeit ausgeht bevor das Sprint Backlog vollständig ist, dann könnte hier z.B. festgehalten werden, dass das Meeting eine Stunde länger angesetzt werden muss. Oder auch genau umgekehrt.

Oder z.B. die tagtäglichen Arbeitspraktiken: Werden die Codierstandards eingehalten und wenn nicht, warum? Fehlen Standards/Vorgaben und wenn ja, welche? Unterstützt die verwendete Technologie noch die Anforderungen im Projekt?

Und dann halt auch das Soziale: Wo gibt es zwischenmenschliche Reibungen und warum? Wo scheint Kommunikation zu fehlen oder nicht ausreichend zu sein und warum? Gibt es evtl. Probleme bei den Vorstellungen über die Arbeitszeiten? Und so weiter.

Und Verbesserungen werden in der Regel ja nicht dadurch erzielt, dass man mal darüber gesprochen hat sondern nur durch konkrete Maßnahmen. D.h. als Ergebnis einer jeden Retrospektive müssen konkrete Maßnahmen vereinbart worden sein, die die Verbesserung des Scrum Prozesses zum Ziel haben.

„Die Teilnehmer“

Aus diesem Inhalt ergibt sich schon so ein bisschen die Teilnehmergruppe der Sprint Retrospektive. Teilnehmer sind auf jeden Fall das komplette Team, der Scrum Master und der Product Owner. Weitere Teilnehmer wie z.B. Stakeholder können hinzukommen, dabei gelten aber zwei wichtige Regeln:

  1. nur wenn die weiteren Teilnehmer aktiv zur Prozessverbesserung beitragen können. D.h. sind diese Personen notwendig um Probleme identifizieren oder lösen zu können? Einfach nur Zuschauer sind eher nicht gewünscht. Dafür können die Daily Scrums oder Sprint Reviews benutzt werden.
  2. Alle Teammitglieder, der Scrum Master und Product Owner müssen einverstanden sein. Dabei muss eine Ablehnung auch nicht ausführlich begründet werden. In Retrospektiven kann es, gerade wenn es um soziale Probleme geht, schnell ans Eingemachte gehen und das möchte nicht jeder vor Außenstehenden machen.

Zusammenfassend kann man sagen: So viele wie nötig, so wenig wie möglich.

„Die Dauer“

Wie lange soll die Retrospektive denn dauern?

Wir erinnern uns, dass wir in Scrum ja fast alles in festen Zeitboxen machen. Als Faustformel würde ich sagen, bei einer Sprintlänge von zwei Wochen anfangs jeweils einen halben Tag. Einigen mag das ziemlich lange vorkommen, aber gerade am Anfang eines Projektes wird es ziemlich viel Justierungsbedarf geben und die Retrospektive ist das Werkzeug dafür, um das Projekt im Doing (nicht im Bezug auf die Anforderungen) auf Kurs bringen zu können. Wenn der Justierungsbedarf nachlässt, d.h. in der Retrospektive kommen nichtmehr genug „echte“ Themen auf, um wirklich den halben Tag auf Dauer zu benötigen, dann kann die Zeitbox entsprechend verkürzt werden. Das ist übrigens etwas, was in der Retrospektive als Ergebnis entstehen kann.

Und jetzt wird es noch ein paar geben, die einen halben Tag zu wenig finden. Die mögen aber bedenken, dass die Retrospektive ja in jedem Sprint stattfindet, hier also alle zwei Wochen. Und in der Regel entstehen auch nicht in jedem Sprint so viele neue Probleme oder Umstände, dass jeweils ein halber Tag zur Reflektion benötigt wird. Anfangs vielleicht ja, weil vieles neu ist aber das sollte sich zügig ändern. Und deshalb ist es auch nicht notwendig, dass am Ende jeder Retrospektive alles geklärt sein muss. Offene Themen werden dann halt in die nächste Retrospektive mitgenommen und dort weiter bearbeitet.

„Wo“

Es empfiehlt sich übrigens, wie bei den meisten Meetings, sich für die Retrospektive einen möglichst störungsfreien Raum zu suchen, in dem alle Teilnehmer ausreichend Platz und Sitzgelegenheiten haben und auch Platz für Teamarbeiten an einer Metaplanwand oder Whiteboard sind. Auf Beamer und Rechner würde ich übrigens großzügig verzichten, da dieses selten die Teamarbeit fördert.

„Die Moderation“

Ja und dann ist noch die Moderation der Retrospektiven zu klären. Ein externer Moderator, der der Situation völlig unbelastet gegenübersteht und eventuell, weil er das hauptberuflich macht auch das größtmögliche Maximum an Moderationserfahrung mitbringt, wäre natürlich das schönste. Aber machen wir uns nichts vor, die Wahrscheinlichkeit dass ein Unternehmen alle zwei Wochen einen externen Moderator finanzieren wird tendiert eher gegen Null.

In der Regel wird es also eher der Job des Scrum Masters sein, die Retrospektive zu moderieren und normalerweise sollte das auch mehr aus ausreichend sein. Sinn macht das Extrainvestment in einen externen Moderator gegebenenfalls für die ersten ein zwei Retrospektiven, wenn der Scrum Master noch wenig Erfahrung in der Moderation hat, sodass er sich hier was abschauen kann. Oder wenn die sozialen Probleme im Projekt anwachsen und der Scrum Master entweder selber involviert ist und damit eine unvoreingenommene Moderation nicht möglich ist oder er sich das Moderieren in dieser Situation noch nicht zutraut. Letzterer Grund ist übrigens kein Grund zur Schande. Ganz im Gegenteil, wenn der Scrum Master dies ehrlich eingesteht und Hilfe anfordert anstatt es doch selber zu probieren und die Situation möglicherweise damit noch verschlimmert. Wir erinnern uns: In Scrum werden Probleme immer offengelegt und aktiv angegangen.

„Der Ablauf“

Wie läuft nun so ein Sprint Retrospektive konkret ab:

Noch vor der ersten Retrospektive oder direkt als erstes der ersten Retrospektive müssen die Grundregeln/Grundprinzipien vereinbart werden. An folgenden Regeln führt für erfolgreiche Retrospektiven eigentlich kein Weg vorbei:

  1. Gegenseitiger Respekt
  2. Ehrliche Kommunikation
  3. Trennung von Person und Sache

Diese Regeln müssen von allen akzeptiert werden und jeder Teilnehmer hat jederzeit das Recht, sich auf diese Regeln zu berufen.

Weitere Regeln können dann individuell vom Team vereinbart werden.

Wenn das geklärt ist, dann kann es losgehen.

Es gibt nicht DIE Vorgehensweise oder Art, eine Retrospektive durchzuführen. Maßgeblich sind eigentlich nur die gerade genannten Grundregeln und das am Anfang benannte Ziel, konkrete Maßnahmen zur Verbesserung des Scrum Prozesses zu erarbeiten. Wer sich hier ein bisschen tiefer einarbeiten möchte, dem empfehle ich das Buch „Agile Retrospectives: Making Good Teams Great“ von Esther Derby und Diana Larsen. Einen Link dazu stelle ich in die Show Notes.

Fürs erste möchte ich hier jetzt eine Vorgehensweise vorstellen, mit der wir in meinem aktuellen Projekt erfolgreich arbeiten.

Die Retrospektive gliedert dabei auf in vier Phase: Einführung, Datensammlung, Themenbearbeitung und Abschluss.

In der Einführung erklärt der Moderator nochmal kurz die Zielsetzung, den Ablauf und die Regeln. Hier holt der Moderator vom Teilnehmerkreis auch das Commitment für Ziel, Ablauf und Regeln ein und ggfs. können hier noch Abweichungen gemeinsam festgelegt werden.

Anschließend erklärt jeder Teilnehmer kurz, wie er sich fühlt und was er von dem Meeting erwartet. Alternativ kann auch jeder Teilnehmer seine Stimmung ausdrücken, indem er auf einem Stimmungsbarometer an einer Wand einen Punkt klebt oder Strich macht und somit die Gesamtstimmung im Team visualisiert wird. Das ganze dient gleichzeitig zur Auflockerung und zur Einstimmung auf das Thema.

Bei der Datensammlung wird gesammelt, was den so im letzten Sprint passiert ist und welche Probleme das Projekt derzeit hat. Das können neu aufgetretene Probleme sein oder aber auch ältere, die das Projekt schon länger ungelöst mit sich rumschleppt.

Eine Methode, um das zu erreichen ist Mad Sad Glad. Als erstes schreiben alle Teilnehmer Karten mit positiven und negativen Ereignissen. Das kann man von der Anzahl völlig offen lassen oder z.B. auch auf jeweils 3 positive und negative Karten beschränken (jede Karte aber nur ein Ereignis). Einfach mal ausprobieren, was bei Ihnen besser funktioniert. Jeder Autor markiert seine Karte auch als positiv oder negativ, indem er eine Smiley oder ein Nichtsmiley darauf malt. Alternativ können auch Karten mit unterschiedlichen Farben verwendet werden.

Wenn alle ihre Karten geschrieben haben, dann werden diese an einer Metaplanwand gesammelt. Dazu stellt jeder Teilnehmer nacheinander seine Karten kurz vor und hängt sie dabei an die Wand. Die Betonung liegt dabei auf kurz, keine Romane. Fragen oder Kommentare durch andere Teilnehmer sind nicht erlaubt. Eine Sortierung findet auch noch nicht statt. Natürlich steht es dem Autor frei, seine Karte in die Nähe einer anderen zu hängen, die er als thematisch verwand empfindet, aber das bedeutet erst mal noch nichts.

Dann werden die Karten gemeinsam gruppiert. Dabei wird darüber gesprochen, was genau gemeint ist oder wie es gemeint ist und so weiter. Nach einer Zeit sind die Karten gruppiert und jede Gruppe bekommt eine gemeinsame Überschrift, das Thema der jeweiligen Gruppe.

Ist das geschehen, dann werden die Themen (die Gruppen sind nun zu Themen geworden) gemeinsam priorisiert. Dazu darf jeder Teilnehmer insgesamt drei Klebpunkte an die Themen verteilen, die ihm am wichtigsten sind. Die muss er übrigens nicht alle auf einzelne Themen verteilen, wenn ihm ein Thema ganz besonders wichtig ist, dann kann er auch seine ganzen Punkte an dieses vergeben.

Das Thema mit den meisten Punkten ist das wichtigste, das mit den zweitmeisten das nächstwichtigste und so weiter.

Wir gehen in die Phase Themenbearbeitung über. Dazu betrachten wir kurz nochmal, dass jeder Teilnehmer sowohl positive wie auch negative Karten schreiben durfte. Daraus ergibt sich, dass Themen eine mehr oder weniger starke Tendenz haben werden, als positiver oder negativer Faktor wahrgenommen zu werden.

Es gibt immer mal wieder die Meinung, dass Positives in einer Retrospektive nicht weiter besprochen werden muss, da es ja eh schon gut ist. Das sehe ich anders. Andere vertreten den Standpunkt, dass man aus Gründen der Motivation natürlich auch über Positives reden muss. Auch da bin ich nicht dabei, denn wir wollen in unserer Retrospektive greifbare Ergebnisse erzielen und nicht einfach mal nur drüber reden. Ja, aber was denn jetzt, drüber reden oder nicht? Die Antwort lautet, drüber reden, wenn daraus ein echter Nutzen gezogen werden kann. Nur drüber zu reden, weil es so schön war und man sich damit selber auf die Schulter klopfen kann, ist in einer Retrospektive Zeitverschwendung. Wenn man aber im Gespräch darüber Lehren für andere Bereiche des Projekts ziehen kann oder Möglichkeiten erarbeiten, etwas was gut ist noch besser zu machen, dann wird hier ein echter Mehrwert erzielt. Erfahrungsgemäß werden diese Themen aber erst eine höhere Priorität bekommen, wenn zumindest die drückendsten negativen Themen gelöst sind.

Aber zurück zur Themenbearbeitung. Die Themen werden in der Reihenfolge ihrer Priorität bearbeitet und zwar sowohl die negativen wie auch die positiven. Bei jedem Thema wird von der Gruppe (diesmal sind die Teilnehmer der Retrospektive gemeint, nicht die gruppierten Karten) zuerst die Ursache erarbeitet, also warum ist etwas ein Problem, warum funktioniert etwas nicht oder warum funktioniert etwas so gut. Hierbei kann z.B. die Methode der fünf Warums verwendet werden, bei der fünfmal nach dem Warum gefragt wird. Natürlich nicht fünfmal nach dem gleichen Warum (obwohl stete Wiederholung soll ja auch Lerneffekte erzielen) sondern jede Antwort auf ein Warum wird erneut hinterfragt um damit auf die tieferen Ursachen eines Umstandes zu kommen.

Wenn die Ursache geklärt ist, dann geht es daran konkrete Maßnahmen zu beschließen, die für die Zukunft Verbesserungen bewirken sollen, also einen negativen Effekt zu beseitigen oder zu mindern bzw. einen positiven zu verstärken. Maßnahmen werden vom Moderator schriftlich festgehalten, ein Verantwortlicher aus dem Teilnehmerkreis und ein Zieldatum bestimmt.

Wenn alle Themen bearbeitet sind oder, was wahrscheinlicher ist, die Zeit für diese Phase rum ist, dann kommen wir zum Abschluss der Retrospektive.

Beim Abschluss führen wir quasi eine kleine Retrospektive der Retrospektive durch. Dabei werden gemeinsam kurz folgende Fragen besprochen.

  1. War der zeitliche Rahmen in Ordnung? Retrospektive zu kurz oder zu lang?
  2. Wurden konkrete Ergebnisse erzielt? Wenn nicht sollte dies das Thema der nächsten Retrospektive sein.
  3. War die Art der Durchführung hilfreich?

Die Ergebnisse hieraus gehen direkt in die nächste Retrospektive ein.

„Was noch“

Damit wäre die Retrospektive durch. Aber noch ein paar kleine Hinweise.

Natürlich kann man die beschlossenen Maßnahmen einfach in ein Textdokument schreiben, dass dann niemand mehr beachtet und in Vergessenheit gerät. Mehr Effekt erzielt man jedoch, wenn die Maßnahmen zusammen mit den Verantwortlichen und Terminen groß auf Flipchartpapier geschrieben und offen im Teamraum aufgehängt werden. Das erhöht die Change, dass irgendwas davon auch erledigt wird erheblich. Außerdem sollte zum Beginn jeder Retrospektive der Status der noch unerledigten Maßnahmen abgefragt werden. Wird eine Maßnahme trotz abgelaufenen Termin zum wiederholten Male nicht erledigt, dann kann dies durchaus ein direkt ein Thema für die Retrospektive sein.

Und dann gibt es da noch eine paar Situationen, die in Retrospektiven auftreten können und in denen der Moderator gefordert ist, die Retrospektive zu retten.

Persönliche Angriffe: Wir haben weiter vorne gesagt, eine der Grundregeln für Retrospektiven ist die Trennung von Person und Sache. Normalerweise bedeutet dies, dass über Sachthemen und nicht über persönliches Verhalten diskutiert wird. Da wir in Scrum, wie aber auch schon gesagt, auch die zwischenmenschlichen Aspekte nicht außer Acht lassen, kann es manchmal auch notwendig und zielführend sein, Zwischenmenschliches zu thematisieren. Allerdings muss der Moderator hier viel Fingerspitzengefühl zeigen, bei der Entscheidung, was zulässig ist und was nicht. Haben nur vereinzelte Personen Probleme untereinander, dann sollte der Punkt aus der Retrospektive herausgezogen werden. Die betroffenen Personen sollen evtl. unter Mithilfe eines Moderators das Problem in einer eigenen Runde besprechen und klären. Betreffen die Probleme aber das ganze Team und hemmen die Produktivität des Teams, dann ist das ein Thema für die Retrospektive. Aber auch hier gilt das Grundprinzip des gegenseitigen Respekts. Keine Beleidigungen, Vorwürfe müssen auch belegt werden können, keine unzulässigen Verallgemeinerungen. Bei Verstößen hiergegen muss der Moderator sofort eingreifen und notfalls die Retrospektive auch mal unterbrechen, damit sich die Gemüter auch mal wieder beruhigen können.

Schweigen: Es gibt ja nichts furchtbareres, wenn man eine Retrospektive startet und dann, wenn nach Themen gefragt wird, alle nur schweigen. Es muss nicht so extrem sein, aber wenn Punkte nicht angesprochen werden, obwohl klar ist, dass sie da sind, dann gibt es da scheinbar ein Problem. Meist ist dies ein Vetrauensproblem, entweder in den Sinn der Retrospektive selber, also „Wozu soll das gut sein, dass ändert doch eh nichts“ oder in Anwesende. Sollte der Moderator in diese Situation kommen, dann hilft hier nur doch, auf die Metaebene zu wechseln und die Situation offen anzusprechen. Also klar adressieren, dass er das Gefühl hat, dass nicht alles angesprochen wird und er ein Vertrauensproblem vermutet. Sind Vorgesetzte von Teilnehmern anwesend, so kann dies durchaus der Grund sein. In diesem Fall kann es hilfreich sein, die nächste Retrospektive ohne diese Vorgesetzten durchzuführen und zu sehn, ob es dann besser wird. Als letztes Mittel bleiben dem Moderator nur noch Einzelgespräche, um die Ursachen für das Schweigen zu finden und zu beheben, denn gelöst werden muss dieses Problem. Ohne eine funktionierende Retrospektive kann sich ein Scrumprozess nicht weiterentwickeln und damit das Projekt nicht optimal unterstützen. Bei aller Sorge um eine funktionierende Retrospektive darf der Moderator aber nicht vergessen: In seltenen Fällen gibt es tatsächlich keine oder nur wenige Probleme, die besprochen und gelöst werden müssen. Also bitte nicht dort ein Problem unnötig erzeugen, wo eigentlich keins ist.

Schwafeln: Wenn viel gesprochen wird, ohne dass dabei was Konkretes rauskommt, dann nennt man das schwafeln. So begrüßenswert es ist, wenn die Teilnehmer in der Retrospektive viel reden, wenn einzelne Teilnehmer sich zwar viel mitteilen, dabei aber eigentlich nur heiße Luft erzeugen, dann muss der Moderator auch hier eingreifen und gezielt nach den eigentlichen Inhalten fragen. Zeit ist ein knappes Gut und es sollte gut genutzt werden. Es geht allerdings nicht darum, jede Art von informeller Kommunikation zu unterbinden. Eine Retrospektive sollte durchaus auch Spaß machen. Aber wenn einzelne Teilnehmer anfangen sich zu produzieren und damit massive Zeit für sinnvollen Inhalt vergeuden, dann kann das den Nutzen einer Retrospektive stark beeinträchtigen.

Wenn alle zwei oder vier Wochen konsequent eine Retrospektive durchgeführt wird, dann schleicht sich schnell Routine ein und diese kann auf Dauer die Effektivität einer Retrospektive beeinflussen. Abhilfe schafft hier, den Ablauf und Inhalt der Retrospektiven immer mal wieder zu variieren.

Anstatt die Karten mit den Ereignissen bei der Vorstellung zufällig auf der Metaplanwand zu verteilen, können diese z.B. anhand eines Zeitstrahls zeitlich geordnet werden. Oder man nimmt anstatt eines einfachen Zeitstrahls den Sprint Burndown und vergleicht mal, ob bestimmte Ereignisse evtl. mit Entwicklungen im Sprintfortschritt in Korrelation stehen könnten. Obwohl das teilweise mit Vorsicht zu genießen ist. Oder man ändert ausnahmsweise mal den Fokus einer Retrospektive. Normalerweise werden in einer Retrospektive ja rückblickend die Ereignisse des abgelaufen Sprints bzw. auch der Zeit davor betrachtet. Wenn die aktuellen Probleme im Projekt aber nicht zu drückend sind, dann lenkt man den Fokus mal in die Zukunft. Die Teilnehmer spielen mal zur Abwechslung eine Runde „was wäre wenn“. Alle zusammen formulieren mal, wie ihrer Ansicht nach das Projekt aussähe, wenn die Rahmenbedingungen völlig frei definierbar wären. Dann definiert man, wie die Rahmenbedingungen denn konkret sein müssten und anschließend wird überlegt, was in der tatsächlichen Welt unternommen werden müsste, um auf die idealisierten Rahmenbedingungen zu kommen. Quasi eine legitime Zeit zum Träumen mit dem Anspruch aber hieraus konkreten Projektnutzen zu ziehen.

„Und noch was“

So, jetzt haben wir noch zwei Punkte, über die wir sprechen müssen. Was ist mit unbehandelten Themen und nochmal ein genauerer Blick auf den zeitlichen Rahmen innerhalb der Retrospektive.

Wir hatten es schon angesprochen, nicht alle Themen die bei der Datensammlung aufgekommen sind, werden auch immer in der Themenbearbeitung ihren Platz finden. In vielen Retrospektiven werden hier mehr oder weniger Themen unbehandelt übrig bleiben. Was passiert nun mit diesen? Nun, das kann man unterschiedlich handhaben. Eine Möglichkeit ist tatsächlich, alle unbehandelten Themen wegzuwerfen und bei der nächsten Retrospektive komplett neu anzufangen. Wenn die Themen wichtig waren, dann werden sie auch hier wieder hochkommen. Allerdings besteht hier die Gefahr, dass wenn ein Thema bereits dreimal unbehandelt weggeworfen wurde, es bei der vierten Retrospektive nicht mehr angesprochen wird. „Wird ja sowieso nie behandelt werden“ ist die Denkweise, die sich da schnell einnistet verbunden mit einem gewissen Frust einiger Teilnehmer.

Besser ist es da, die unbehandelten Themen als Startset mit in die nächste Retrospektive zu nehmen. Diese Themen werden zusammen mit allen ihren Karten bereits auf der Metaplanwand angebracht, allerdings wird die Priorität aus der letzten Retrospektive nicht mit übernommen. Diese ist tatsächlich wieder offen. Dann werden in der Datensammlung wieder Ereignisse gesammelt und nun entweder bereits bestehenden Themen zugeordnet oder eben neue Themen gebildet. Und dann wird wieder priorisiert und die Themen wie gehabt bearbeitet. Wichtig ist dabei, dass die Prioritäten wieder offen sind und unter Berücksichtigung der aktuellen Situationen neu vergeben werden.

Kommen wir jetzt nun wirklich zum letzten Punkt, der zeitlichen Einteilung innerhalb der Retrospektive. Grundsätzlich ist natürlich jedes Team völlig frei in der Entscheidung darin, wie viel Zeit es auf was verwenden möchte. Aber man darf natürlich nicht vergessen, dass eine Retrospektive nicht einfach nur ein nettes get-togeher ist, sondern konkrete Ergebnisse erzielen soll. Dementsprechend ist es wenig vorteilhaft, 90% der Zeit mit dem Sammeln von Themen zu verbringen und dann nur noch eine halbe Stunde Zeit zum bearbeiten zu haben.

Ich mache mal einen Vorschlag für den von mir vorgestellten Ablauf bei der Annahme eines zweiwöchigen Sprints und einer halbtägigen Sprint Retrospektive, also vier Stunden.

Einführung: 15 Minuten. Kann beim ersten Mal etwas länger sein, weil hier evtl. die Spielregeln für die Retrospektive geklärt werden müssen und die Teilnehmer noch etwas länger brauchen, um das erste Mal ihre Erwartungen zu formulieren. Aber ab dem zweiten Mal müsste es in 15 Minuten gehen.

Datensammlung: 30 – 60 Minuten. Es hängt ein bisschen davon ab, wie viele neue Themen zu erwarten bzw. wie viele alte Themen schon vorhanden sind. Am Anfang, wenn vieles noch nicht eingespielt ist oder später in turbulenten Zeiten, wenn alle merken, dass es nicht optimal läuft, würde ich eher die 60 Minuten nehmen, denn es ist wichtig, dass die Themen benannt werden. Wenn sich dahingegen in den letzten Retrospektiven gezeigt hat, dass nicht mehr so viele neue Themen aufkommen, sollte der Zeitrahmen für die Datensammlung reduziert werden.

Themenbearbeitung: 120 – 150 Minuten. Die Länge dieses Blocks ist umgekehrt proportional zur Länge der Datensammlung. Je mehr, umso besser, denn nur bearbeitete Themen sind gute Themen.

Abschluss: 15 Minuten. Auch hier gilt, kann beim ersten Mal länger sein, da viel über das Erlebte der ersten Retrospektive verarbeitet werden muss. Also mal lieber 30 Minuten ansetzen. Ab dem zweiten Mal aber nur 15 Minuten. Wenn es deutlich mehr über die eigentliche Retrospektive zu besprechen gibt, dann lohnt es sich evtl. mal eine eigene Retrospektive nur zu diesem Thema zu machen.

Hey, das sind ja nur 3 ½ Stunden. Wir haben doch vier Stunden zur Verfügung! Ja schon, aber ohne gelegentliche Pausen hält das niemand durch. So zwischen Datensammlung und Themenbearbeitung würde ich eine Pause einlegen und dann nochmal eine während der Themenbearbeitung. Aber auch das muss schlussendlich jedes Team selber regeln.

Wichtig bei diesen Einteilungen ist, dass sie allen Teilnehmern klar sind. Der Moderator stellt den Ablauf mit den vorgegebenen Zeiten einschließlich der Pausen in der Einführung vor. Und diese Zeiten sollten als Obergrenzen auch wirklich eingehalten werden. Wenn 60 Minuten Datensammlung angesetzt sind, dann ist nach 60 Minuten auch Schluss. In zwei Wochen ist die nächste Retrospektive, da kann dann weitergemacht werden, aber für aktuelle Retrospektive ist Schluss! Es sind aber wie gesagt Obergrenzen. Wenn nach 45 Minuten bei besten Willen kein echtes neues Thema mehr gefunden werden kann, dann sitzen wir natürlich nicht die restlichen 15 Minuten schweigend da oder machen Unsinn. Wir gehen dann halt eben schon vorzeitig in die nächste Phase über, in diesem Fall hätten wir dann 15 Minuten mehr Zeit für die Bearbeitung der Themen. Ist doch super!

„Geschaft“

Das war es, Sie wissen jetzt alles, was Sie für eine erfolgreiche erste Retrospektive brauchen und haben auch die notwendigen Werkzeuge zur Hand, um Ihre Retrospektiven selber weiter zu entwickeln.

Dies ist das Skript der Episode „Die Sprint Retrospektive“ des Podcasts Scrumidable vom 13.12.2009.

Prioritäten von Anforderungen – Kategorie oder Reihenfolge?

Freitag, 6. November 2009 von  
unter Fachartikel Scrum

Ein typisches Problem in jedem Projekt (nicht nur in der Softwareentwicklung) ist die Frage der Prioritäten der Anforderungen. Was muss zuerst erledigt werden, was hat Zeit für später, auf was kann ggfs. ganz verzichtet werden.

Es gibt verschiedene Methoden und Verfahren, diese „Wichtigkeiten“ der Anforderungen zu bestimmen, auf die ich hier nicht näher eingehen möchte. Was mich hier aus aktuellem Anlass eher beschäftigt ist die Frage, wie diese Priorität anschließend festgehalt wird.
Aktuell sind mir dazu zwei Modelle geläufig: a) Einteilung in feste Kategorien und b) relative Priorität in Form einer Reihenfolge.

Betrachten wir beide Modelle mal kurz getrennt voneinander:

Kategorien: Zur Einteilung der Anforderungen wird eine Anzahl n Kategorien definiert. Besonders beliebt sind die Kategorien „Priorität 1“ bis „Priorität 5“. Wenn sich der Prozessverantwortliche noch besonders Mühe gibt, dann bekommen die Kategorien noch so sprechende Bezeichnungen/Beschreibung wie z.B. „Must have“, „Nice to have“ oder auch „Sehr wichtig“, „Wichtig“ oder „Normal“. Dass sich mal jemand getraut hätte eine Kategorie ganz offen als „Wird wohl niemals gemacht werden“ zu deklarieren, habe ich leider noch nicht erlebt. Aber ehrlich wäre es.

Mittels einer geeigneten Methode (z.B. Kano Modell) oder oft auch Bauchgefühl wird jeder Anforderung nun einer dieser Prioritätskategorien zugeordnet.

Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können.
Nachteile ergeben sich aber oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen. Dazu weiter unten aber mehr.

Reihenfolge: Die Anforderungen werden abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Hier weiß man genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C. Man fängt mit zwei Anforderungen an und fügt dann weitere Anforderungen im Bubblesort-Verfahren (http://de.wikipedia.org/wiki/Bubblesort) in die Reihenfolge ein.

Nachteil ist, dass der initiale Aufbau der Reihenfolge etwas aufwändig scheint, da man die einzelnen Anforderungen bei der Frage nach ihrer Priorität nicht isoliert betrachten kann. Und auch bei der Aufnahme weiterer Anforderungen ist ein Vergleich mit den anderen Anforderungen notwendig. Dabei muss man aber bei der Einsortierung nicht immer ganz unten anfangen; wenn ich weiß, meine neue Anforderung H ist wichtiger als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger wie alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren. Da kann es sich anbieten statt Bubblesort das Verfahren des binären Suchens (http://de.wikipedia.org/wiki/Binäres_Suchen) anzuwenden. Das ist doch mal spannend, mathematische Sortierverfahren bei der Priorisierung von Anforderungen einzusetzen. Die Mathematiker jetzt aber bitte nicht alle melden und darauf hinweisen, dass es optimalere Algorithmen für die Sortierung gibt. Ich kann mir nur schwer vorstellen, dass tatsächlich ein Produktverantwortlicher oder Anforderungsmanager einen mathematischen Sortieralgorithmus verwenden wird, die Vergleiche dienen hier nur als anschauliche Beispiele.

Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier mal nennen möchte) ist, dass ich hier nun eine eindeutige Reihenfolge habe, in der die Anforderungen umzusetzen sind. Was ist, wenn ich zwischen zwei Anforderungen nicht entscheiden kann, welche von beiden wichtiger ist? Münze werfen oder die weiteren Begleitumstände beachten (ist klar, dass eine der beiden Anforderungen aufgrund äußerer Umstände erst später umsetzbar sein wird, dann kann sie auch direkt weiter nach unten wandern. Dies gehört aber zum Thema, wie überhaupt bestimmt werden kann, welche Anforderungen wichtiger sind wie andere. Das behandeln wir mal in einem anderen Artikel).

Werfen wir beide Modell nun mal in den Ring und betrachten wir ihre Stärken und Schwächen im direkten Vergleich.

Bei einer kleinen überschaubaren Anzahl an Anforderungen machen sich beide Kandidaten recht gut. Die Vergabe der Prioritäten im auf Kategorien basierenden Ansatzes ist wie bereits oben besprochen ja eh recht trivial (Priorisierungsmethode der Wahl anwenden, Ergebnis nehmen und auf Kategorien transformieren, fertig). Aber auch im relativen Modell ist der direkte Vergleich der Wichtigkeit der Anforderungen untereinander schnell erledigt. Und auch bei der Abarbeitung der Anforderungen bzw. der Einplanung zeigen sich beide Modelle hilfreich.

Aber wie sieht es mit einer großen Anzahl an Anforderungen aus, wie sie schon in durchschnittlichen Projekten schnell erreicht ist?
Wir unterstellen mal eine initiale Anzahl von 100 Anforderungen zum Projektstart. Und hier wird es langsam interessant.

Betrachten wir als erstes wieder den Aufwand für die initiale Priorisierung der Anforderungen.
Im auf Kategorien basierenden Modell nehmen wir mal die typische Aufteilung in fünf Kategorien an, die wir hier als P1 bis P5 bezeichnen wollen, wobei P1 für die wichtigsten Anforderungen stehen wird und P5 für die unwichtigsten. Die Verteilung der 100 Anforderungen auf die fünf Kategorien ist erneut mit wenig Aufwand verbunden. Na gut, mit verhältnismäßig wenig Aufwand, natürlich muss jede der 100 Anforderungen bewertet werden, das ist schon Arbeit. Als Ergebnis bestimmen wir in unserem Beispiel, dass 30 Anforderungen nun P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5. Das ist irgendwie nicht unüblich, dass der überwiegende Teil der initialen Anforderungen ziemlich wichtig zu sein scheint.

Beim relativen Modell steigt der Aufwand deutlich, denn hier müssen nun die 100 Anforderungen im Verhältnis zueinander nach Wichtigkeit sortiert werden. Das klingt aber schlimmer als es dann wirklich ist. Man fängt mit zwei Anforderungen an und fügt dann Anforderung für Anforderung hinzu. Und wie oben schon mal erklärt, muss nicht bei jeder Anforderung unten mit der Sortierung angefangen werden sondern in der Regel kann direkt weiter oben in der Reihenfolge eingestiegen werden (weiter unten sage ich da noch was zu).

Wie sieht es jetzt mit der Einplanung der Anforderungen aus? Auch hier treffen wir für unser Beispiel ein paar vereinfachte Annahmen. Wir definieren, dass wir mit Scrum arbeiten, dass alle Anforderungen mit einem Aufwand von einem Story Point (SP) geschätzt sind und dass wir in einen Sprint 20 Story Points unterbringen können.
Wenn wir nun unseren ersten Sprint planen, dann stellen wir im Kategorienmodell fest, dass wir insgesamt 30 SPs haben, die Priorität vor allem anderen haben. Soweit war das Modell ja schon mal hilfreich. Im ersten Sprint unterbringen können wir aber nur 20 SP. Welche sollen wir da nun nehmen? Hier fangen wir dann vermutlich an, diese 30 Anforderungen untereinander zu vergleichen, um innerhalb dieser Gruppe eine gewisse Sortierung zu erzielen. Das gleiche gilt dann für die nächsten Sprints. Vorausgesetzt, die 20 geplanten SPs des ersten Sprints werden auch umgesetzt, stehen für den zweiten Sprint 10 weitere SPs der Priorität P1 an und 40 der Priorität P2, von denen aber nur 10 im Sprint Platz finden. Also wieder vergleichen und sortieren innerhalb von P2, und so weiter. Wir fangen uns hier also den Aufwand ein, den wir vorher bei der initialen Priorisierung vermeintlich gespart hatten.
Bei der bereits eindeutig sortierten Reihenfolge des relativen Modells haben wir diese Probleme hier nicht mehr, es ist jederzeit klar was als nächstes wichtig ist. Dafür haben wir aber vorher mehr Aufwand reinstecken müssen.

Und jetzt kommen wir zur Königsdisziplin, eine neue Anforderung, die wichtiger ist wie alles andere, sagen wir eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist (neue gesetzliche Vorgaben werden vor allem in Konzernen ja gerne mal so lange ignoriert, bis sie dann auf den letzten Drücker doch plötzlich unvermeidbar scheinen).
Wie bilde ich das mit meinen Kategorien ab? P1 ist ja schon das wichtigste, aber meine neue Anforderung ist ja sogar noch wichtiger als die 30 bereits als P1 eingestuften Anforderungen. Definiere ich jetzt adhoc eine neue Kategorie P0, die noch über P1 steht? Da dauert es garantiert nicht lange, bis auch diese neue Kategorie regelmäßig gefüllt wird, denn hochpriore Kategorien haben die Eigenschaft, Anforderungen anzuziehen. Wir haben hier also ein nichttriviales Problem, dass in vielen Fällen damit gelöst wird, dass zusätzlich zur eigentlichen Kategorie noch ein weiteres Attribut wie z.B. Severity (in Bugzilla) hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und enhancement (diese gibt es so z.B. eben in Bugzilla aber auch anderen Tools) annehmen. Das ist aber nicht nur redundant, sondern kann auch zu Inkonsistenzen führen. Was ist denn nun wichtiger, eine Anforderung mit P1/enhancement oder eine mit P3/blocker? Und wieso kann eine P3 Anforderung ein Blocker sein, bzw. wieso kann ein scheinbarer Blocker nur die Priorität P3 haben? Das führt zu Chaos!

Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen hochprioren Anforderung leicht zu lösen. Die neue Anforderung einfach ganz oben einsortieren, Problem gelöst.

Bis hierhin scheint das relative Modell also besser geeignet zu sein.

Jetzt hatte ich aber weiter oben ausgeführt, dass die meisten Methoden zur Priorisierung von Anforderungen eher das Denken in Kategorien unterstützen. Das jetzt schon mehrfach zitierte Kano Modell der Kundenzufriedenheit z.B. teilt Produktmerkmale (aus denen Anforderungen werden) in die fünf Kategorien Basis-, Leistungs-, Begeisterungs-, Unerhebliches und Rückweisungsmerkmal ein.
Muss ich nun auf diese Methoden verzichten, wenn ich mit einem relativen Prioritätsmodell arbeiten möchte? Natürlich nicht! Wenn ich eine eindeutige Reihenfolge meiner Anforderungen aufbauen möchte, dann muss ich die Wichtigkeit der einzelnen Anforderungen irgendwie begründen können. Warum ist denn die Anforderung A wichtiger als die Anforderung B? Da brauche ich für beide Anforderungen irgendwelche Anhaltspunkte dafür, weshalb sie wichtig oder auch nicht wichtig sind. Und genau dafür sind viele Methoden der Priorisierung eine große Hilfe. Mit ihnen kann ich zumindest schon mal ein grobes Raster schaffen, dass mir bei der ersten Vorsortierung hilft. Und wenn die Anforderung A nach dem Kano Modell in die Kategorie Basismerkmal fällt und die Anforderung B in die Kategorie Leistungsmerkmal, dann weiß ich ganz automatisch, das A wichtiger ist als B. Und nur wenn die Anforderung C ebenfalls ein Basismerkmal zu sein scheint, muss ich mir im Vergleich von A und C mehr Informationen heranziehen um hier eine eindeutige Entscheidung zu fällen.

Fazit:
Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind. Nein, sie sind eine hilfreiche Zwischenstufe auf dem Weg zu einer sortieren Reihenfolge relativer Wichtigkeit und diese Zwischenstufe kann nicht nur viel Zeit sparen sondern bei der Verwendung geeigneter Methoden die fundierte Basis für die Bewertung der relativen Wichtigkeiten liefern. Nur davon, dann bei diesen Kategorien stehen zu bleiben und auf dieser Basis dann z.B. die Sprint- oder Releaseplanung zu betreiben oder die Priorität von Anforderungen zu kommunizieren, rate ich dringend ab.

Vortrag auf dem Scrum Day 2009

Montag, 12. Oktober 2009 von  
unter Fachartikel Scrum, News

Der Vortrag „Wie entsteht Architektur in Scrumprojekten“ von Carsten Czeczine wurde für den Scrum Day 2009 in Düsseldorf angenommen. Weitere Informationen hierzu gibt es hier.

Schulung Scrum Grundlagen

Mittwoch, 7. Oktober 2009 von  
unter Fachartikel Scrum, News

Carsten Czeczine wird über die GFU Cyrus AG im Dezember 2009 und Mai 2010 zwei offene Grundlagenschulungen über Scrum halten. Informationen und Anmeldungen zu dieser Schulung gibt es hier.

Vortrag „Scrum – Was ist das“

Mittwoch, 7. Oktober 2009 von  
unter Fachartikel Scrum

Am 16. Juni 2009 hat Carsten Czeczine bei der RheinJUG vor knapp 100 Zuhörer eine Einführungsvortrag über Scrum gehalten. Der komplette Vortrag wurde aufgezeichnet und kann hier angesehen werden.
Hier gibt es die Nachlese zum Vortrag.

Scrumidable – der Podcast über Scrum

Mittwoch, 7. Oktober 2009 von  
unter Fachartikel Scrum

Mit Scrumidable produziert Carsten Czeczine seit April 2009 den ersten deutschsprachigen Podcast über Scrum. In kurzen Episoden werden verständlich und ohne großes Tamtam sowohl die Grundlagen von Scrum erklärt wie auch kontroverse Aspekte von Scrum diskutiert.

« Vorherige Seite