Über eine Iterationslänge von 1 Tag habe ich ja schon öfter geschrieben. Dazu stehe ich weiterhin. Allerdings ist mir aufgefallen, dass sie nicht an erster Stelle stehen sollte. Deshalb versuche ich mal eine andere Formulierung:
Im Kern von Scrum steht der Sprint von mehreren Wochen, d.h. ein fixes Auslieferungsdatum mit fixem Scope. Scrum ist damit fundamental zeitorientiert. Pro Sprint werden mehrere "Arbeitspakete" angegangen, die alle zum selben Zeitpunkt abgeliefert werden müssen.
Im Kern von Kanban steht die Warteschlange. Kanban ist damit fundamental flussorientiert. Wie lange die Ablieferung eines "Arbeitspaketes" dauert, ist egal, solange dadurch keine Verschwendung entsteht (Halden von auf Vorrat produziertem "Zeug").
Klingt irgendwie alles sinnig, oder?
Wenn wir uns das aber mal auf der Zunge zergehen lassen, dann sollte uns "im Abgang" ein bitterer Geschmack auffallen. Es fehlt nämlich etwas. Und was fehlt, ist oft schwer zu erkennen.
Es fehlt der Kundennutzen, es fehlt die Qualität. Beides steht weder bei Scrum noch bei Kanban an erster Stelle. Und nur das meine ich natürlich: Er steht nicht an erster Stelle. Er ist nicht offensichtlich.
Ich will also nicht sagen, dass Scrum und Kanban nicht an Kundennutzen oder Qualität interessiert seien. Nein, im Gegenteil. Teams, die Scrum oder Kanban oder Scrumban machen, wollen selbstverständlich Qualität herstellen. Niemandem soll der Wille zu Qualität abgesprochen werden.
Allerdings glaube ich, dass ein Qualitätsziel schwieriger als nötig (oder wünschenswert) erreicht wird, wenn es nicht an erster Stelle steht. Außerdem haben wir es sowieso schwer, ein Qualitätsziel zu erreichen; wie messen wir Qualität? Und je größer der Brocken, der in Qualität hergestellt werden soll, desto schwieriger.
Viel leichter ist es, einem Prozess zu folgen. "Haben wir X getan, so wie es der Prozess vorschreibt?" Diese Frage ist ungleich einfacher zu beantworten.
Je weiter oben auf der Prioritätenliste eines Vorgehens dann eine Handlung steht, desto eher wird sie auch ausgeführt. "Haben wir den Sprint eingehalten?", "Ist die Warteschlange übergelaufen?" - das sind die beiden ersten Fragen, die sich Scrum- bzw. Kanban-Teams stellen. In beiden kommt Qualität nicht vor.
Wie kann nun ein Vorgehen aussehen, dass Qualität an die erste Stelle setzt? Die Handlung mit höchster Priorität muss mit Qualität zu tun haben. Weitere Handlungen/Aspekte können sich dann auf Zeit oder Fluss oder sonst etwas beziehen. So wie sich weitere Handlungen/Aspekte bei Scrum und Kanban auf Qualität beziehen.
Mein Vorschlag:
1. Füge der Software den kleinsten vertretbaren Nutzen auf dem vereinbarten Qualitätsniveau hinzu.
Das sollte die zentrale, die erste Aufforderung eines Vorgehensmodells für Software sein.
Nutzen: Irgendetwas, das für den Kunden einen Wert darstellt, das ihm etwas bringt, das er beurteilen kann, um festzustellen, ob die Entwicklung auf dem richtigen Weg ist. Nutzen kann in Funktionalität bestehen oder der Erfüllung einer äußeren nicht-funktionalen Anforderungen.
Hinzufügen: Die Software soll etwas mehr Nutzen irgendeiner Art erhalten. Der Nutzenzuwachs kann in etwas mehr Funktionalität bestehen oder in etwas höherer Geschwindigkeit oder in etwas besserer Usability usw.
Kleinstmöglich: Es geht nicht darum, eine ganze User Story oder auch nur ein ganzes Feature hinzuzufügen. Nein, es geht um viel kleinere Inkremente, aus heutiger Sicht quasi unvorstellbar und schmerzhaft kleine Inkremente. Phantasie ist gefragt, Anforderungen so hauchdünn zu schneiden.
Damit meine ich natürlich nicht beliebig klein. Wie immer im Leben ist auch hier eine Balance zu finden zwischen Nutzenzuwachs und "administrativem Aufwand". Da aber alle andere Vorgehensmodelle auch nicht ohne Balance und Fingerspitzengefühl auskommen, finde ich es nicht schlimm, wenn es hier auch nötig ist.
Warum so kleine Inkremente? Ich würde ja sogar formulieren, sinnvoll kleinstmögliche Inkremente. Aber dann kommt jemand und sagt, so hauchdünne Scheiben machen ja eben für den Kunden keinen Sinn.
Darum geht es ja aber auch nicht. Selbst die in einem Scrum Sprint realisierten User Stories machen für den Kunden keinen Sinn in dem Sinne, als dass er nach dem ersten Sprint die Software produktiv einsetzen würde. Dazu sind schon ein paar mehr Sprints nötig in den meisten Fällen.
Wirklich sinnvoll ist für den Kunden nur, was ihn im Tagesgeschäft einen guten Schritt voran bringt. Am besten natürlich die Erfüllung der kompletten Anforderungen. Das ist ja aber bei keinem Vorgehensmodell möglich. Scrum liefert das nicht nach einem Sprint und Kanban nicht, wenn am Ende der Produktionskette das erste mal etwas heraustropft.
Der kleinstmögliche Nutzenzuwachs dient also nicht irgendeinem Sprung nach vorn im sofortigen produktiven Einsatz, sondern in einem _beurteilbaren_ Zuwachs. Ein Team kann viel Code in 14 Tagen schreiben - aber ob damit die Software näher an die Wunscherfüllung des Kunden kommt, kann der nicht beurteilen. Agiles Vorgehen stellt mithin den Nutzen in den Vordergrund; es wird in Durchstichen entwickelt. So auch hier.
Nutzen ist alles, dessen Qualität (d.h. Anforderungskonformität) der Kunde beurteilen kann. Nutzen hat also nicht zwingen mit GUI oder Datenbank oder Verteilung zu tun. Deshalb kann Nutzen auch in viel dünneren Scheiben und viel schneller produziert werden, als gemeinhin angenommen.
Und warum nun diesen Schritt als ersten im Vorgehensmodell? Weil er erstens auf äußere und auch innere Qualität fokussiert und zweitens schnelles Feedback ermöglicht und drittens auch noch der Grundbaustein konstanten Flusses ist. “Kleinstmöglicher Nutzen” entspricht der Forderung nach “small batch sizes”.
Qualität und Feedback vor allen anderen Gesichtspunkten. Das ist mir wichtig. Andere kommen erst danach, z.B.
2. Schritt 1 sollte am Ende des Tages abgeschlossen sein.
3. Zurück zu Schritt 1. Es können auch mehrere Nutzeninkremente (nacheinander) gem. Schritt 1 hergestellt werden, solange die Bedingung von 2 erfüllt ist
Ziel ist ein konstanter Fluss von Nutzenzuwächsen. Durch diese Vorhersehbarkeit und Verlässlichkeit entsteht Vertrauen in die sonst so schwer für Außenstehende greifbare Softwareentwicklung.
Das war´s. Das ist für mich der Kern des Vorgehens in der Softwareentwicklung. Und weil sich die dabei so schnell dreht, nenne ich das mal Spinning.
Wer jetzt Zeit oder Fluss weiter ins Spiel bringen möchte, der fühle sich eingeladen:
Kanban passt wunderbar zu Spinning. Nutzenzuwächse sollten nicht auf Halde geplant werden. WIP sollte limitiert werden; am besten arbeitet das Team zur Zeit immer nur an einem Nutzenzuwachs. Wenn die Herstellung des Nutzenzuwachses aus mehreren Schritten besteht, dann sollten die über Warteschlangen entkoppelt werden.
Scrum passt auch zu Spinning. Wenn wirklich, wirklich nötig, können die Nutzenzuwächse mehrerer Tage zusammengefasst dem Kunden zur Beurteilung vorgelegt werden. Der PO kann sie sich am Ende des Sprints anschauen, wenn er mag. Damit würde zwar die Chance der hohen Umdrehungszahl nicht ausgereizt, aber es wäre halt möglich. Ein Team kann Spinning einführen, auch wenn der Kunde noch nicht genauso schnell ist. (Allerdings sollte er dahin gebracht werden.)
Spinning ist also orthogonal zu anderen Vorgehensmodellen. Es kann unabhängig davon eingeführt werden, sogar im Wasserfall. Die Vorteile:
- Voranschreiten der Codeproduktion im Sinne der Agilität durch höchste Priorität für Nutzenherstellung
- Fokus auf Qualität durch höchste Priorität für äußere Qualität (Nutzen gem. Anforderungen) und innere Qualität (täglicher Druck auf Evolvierbarkeit durch Nutzenproduktion)
- Chance für kürzesten Feedbackzyklus (Iterationsdauer max. 1 Tag)
- Motivation/Zufriedenheit durch “abgeschlossenes Tagwerk”
Wann schicken Sie Ihr Projekt ins Sportstudio? :-) Mit dem Spinning können Sie sofort beginnen.
4 Kommentare:
Meiner Meinung nach haben Scrum als auch Kanban den Kundennutzen implizit im Blick (siehe Agile Manifesto). Was die Qualität angeht, bieten beide Methoden durchaus Möglichkeiten diese zu kontrollieren, etwa "Definition of done" bei Scrum. Kanban erlaubt eine Art "Definition of done" zwischen den einzelnen Prozesschritten, womit das Qualitätsniveau definiert werden kann.
Tasks werden in unserem Team auf eine geschätzte Dauer von maximal 2 Tagen begrenzt (vergleichbar mit dem angesprochenen kleinsten Nutzen).
Wie nun Scrum oder Kanban im Detail umgesetzt wird, hängt vom jeweiligen Team ab. Allerdings geben meiner Meinung nach beide Methodolgien einem alle Mittel an die Hand. Wo siehst du da genau den Verbesserungsbedarf?
@Johannes: Sag ich ja: Scrum und Kanban haben die Qualität irgendwie implizit im Blick.
Das ist mir aber zuwenig. Denn "implizit" kann man mal aus den Augen verlieren. Was irgendwo in einem Manifest steht, ist weiter weg als der Prozess, dem man grad folgt.
Implizit wird überstimmt durch explizit. Und Theorie wird überstimmt durch Praxis.
Deshalb muss die Qualität explizit in der Praxis, d.h. im Vorgehen an erster Stelle stehen. Das tut sie bei Spinning.
Spinning soll nichts ersetzen, sondern eine Lücke füllen, komplementär sein und verstärken.
Hallo Ralf,
"[...]hält die Teile in der Hand. Fehlt leider nur das geist'ge Band" ist manchmal zu oft der Fall bei dem Problem, was du beschreibst.
"Viel leichter ist es, einem Prozess zu folgen. 'Haben wir X getan, so wie es der Prozess vorschreibt?' Diese Frage ist ungleich einfacher zu beantworten."
Dies ist ein eher typisches "Wir machen's so wie uns gesagt wurde!"-Satz. Hier hat jemand nicht verstanden, dass der Prozess ein Werkzeug darstellt und nicht Sinn und Zweck der Übung ist.
Aber das Problem ist ein anderes. Ich hebe das Werkzeug hervor und nicht die Idee, die dahinter steckt. Korrekter wäre der Satz "Haben wir X getan, um etwas zu machen, dass dem Kunden einen Nutzen bringt.".
Deine Idee des Spinnings kann aber genauso "verdreht" werden, wie alle anderen Werkzeuge. Deine Forderung "Füge der Software den kleinsten vertretbaren Nutzen auf dem vereinbarten Qualitätsniveau hinzu." finde ich auch bei Andersons Kanban auch, er umschreibt's nur mit dem Begriff "Kosten" (Transaktion/Koordination) und "Value-Adding".
Die Wertevorstellung (und eine solche ist es), die dahinter steckt, ist das relevante und da stimme ich dir zu, diese muss gedanklich in den Vordergrund kommen. Dann erscheint (hoffentlich) auch das "geist'ge Band" auch wieder, dass das Ganze zusammenhält.
Gruß
@Steffen: Wir müssen einesehen, dass Tools gedankenlos benutzt werden. Sonst hätten wir nach .NET Remoting eher nicht WCF gebraucht. Das erkennen wir ja auch an, wenn wir Kindern sagen "Messer, Schere, Feuer nicht..." (oder so ähnlich). Wir halten von ihnen fern, was man mit bedacht benutzen muss.
Entwickler unter Druck sind nun kaum anders als Kinder. Das habe ich in einer Microblog-Serie bei g+ beschrieben. Sie regredieren unter Druck. Also sollten sie ebenfalls keine Werkzeuge in die Hand bekommen, die man mit Bedacht benutzen muss.
Mit Bedacht kann man benutzen, wozu man Muße hat. Oder sehr viel Erfahrung. Ersteres ist eher nie der Fall, letzteres nicht durchgängig.
Wie schon gesagt: Alle Vorgehensmodelle sind auch für Qualität.
Sie unterscheiden sich aber darin, was sie an die erste Stelle setzen. Ob irgendwo bei Kanban etwas steht ist nicht so wichtig wie, ob es zuoberst auf der Handlungsliste steht.
Kommentar veröffentlichen