Sorry, für den Click-Bait. Für heute habe ich mal ein paar Dinge zusammengesammelt, die mir immer wieder als Missverständnisse bei SchulungsteilnehmerInnen und Beratungskunden unterkommen. Schauen wir mal, wie viele es werden.
1. „Agil bedeutet, wir müssen nicht mehr dokumentieren.“
Vielfach nehmen EntwicklerInnen nach dem Lesen des Agilen Manifests mit, dass sie mit Scrum oder Kanban die lästige Dokumentation nicht mehr benötigen. Liest man die Sätze vor und nach den vier Wertpaaren, wird allerdings spätestens bei
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
klar, dass agil Dokumentation schon wertschätzt. Wenn ich es allerdings schaffe, eine Software zu schreiben, die keinerlei Handbuch bedarf, dann bin ich potentiell besser gewappnet.
Rachel Davies spricht rund um Dokumentation auch gerne von „Consumables“, die einen klaren „Consumer“ haben. Um herauszufinden, was diese Person wirklich konsumieren möchte, kann ich mit der Person zusammen gemeinsam herausfinden, was das Mindestmaß an Dingen ist, die ich dokumentieren sollte und dann nur genau das festhalten.
2. „Wir sind doch agil.“
Agil bedeutet nicht „Durchwurschteln 2.0“ oder dass alles beliebig wird. Don Reinertsen definiert in seinem Buch Principles of Product Development Flow mit dem Vergleich zwischen einem Speedboat und einem Ozeantanker. Beide Boote können theoretisch die gleiche Maximalgeschwindigkeit erreichen. Bei einem Speedboat spricht er aber davon, dass es bei einer sehr hohen Geschwindigkeit eine sehr geringe Reaktionszeit für einen Richtungswechsel hat, während der Ozeantanker das eben nicht hat. Das Speedboat ist so gesehen agiler. Gleiches möchten wir auch bei der Produktentwicklung mit agil erreichen. Das bedeutet nicht, dass ich mich täglich anders entscheiden können will. Auch bei einem Speedboat kann ich bei zu hoher Geschwindigkeit auf eine Klippe aufsetzen und nicht mehr zeitig genug reagieren. Agil bedeutet, dass wir uns umentscheiden können, wenn das sinnvoll wegen der Marktsituation ist. Nicht dass wir das immer auf Biegen und brechen machen werden.
3. „Mit Scrum muss man auch User Storys machen.“
Der Scrum Guide ist da ziemlich eindeutig. In Scrum gibt es einen Product Backlog, der aus Product Backlog Einträgen besteht. Man kann die als User Story beschreiben, andere Möglichkeiten sind ebenfalls erlaubt.
4. „Der Product Owner nimmer das Produktinkrement im Sprint Review ab.“
Bitte nicht. Eine Situation, die ich einmal fast so erlebt habe, war die folgende. Ein neuer Programmierer ist den zweiten Monat in der Firma und hat an seinem ersten Sprint mitgearbeitet. Stolz wie Oskar stellt er seinen Teil der Produktinkrements im Sprint Review vor und es taucht die Frage auf, ob die Product Ownerin das Ergebnis so abnehmen kann. Im Sprint Review sitzen neben dem Scrum Team noch diverse Stakeholder. Dazu gehören unter anderem die Linienvorgesetzte des Programmierers, der Personaler, der ihn eingestellt hat, der CTO, die CEO und Vertreter von drei Kunden.
Die Diskussion, die nach der Antwort auf diese Frage auftritt, wird alle TeilnehmerInnen des Sprint Reviews davon abhalten, den eigentlichen Zweck des Sprint Reviews zu erfüllen: Feedback zum Produkt zu bekommen. Davon mal ab, würde ich das als der Programmierer als ziemlich respektlos empfinden und mich so einer Situation in der Firma noch maximal einmal stellen. Mit hoher Wahrscheinlichkeit wäre ich innerhalb meiner Probezeit schon wieder bei einem neuen Arbeitgeber wegen dieser Verletzung des Wertes Respekt in Scrum.
5. „In Scrum muss man mit Story Points und Planning Poker Dinge im Product Backlog schätzen.“
Muss man nicht. Im Scrum Guide steht lediglich, dass das Product Backlog geschätzt sein sollte. In welcher Einheit ist offen. Das können Story Points, ideale Personentage/-stunden sein, oder Tiergrößen.
Über den Scrum Guide hinaus bin ich auch ein Freund von probalistischem Forecasting und #noestimates. Wenn ich es schaffe, mich nicht zu überplanen, weil ich alles ähnlich groß geschnitten habe, dann kann ich auch am Ende eines Sprint zählen, wie viele Dinge ich geschafft habe, um Vorhersagen für die Zukunft in Richtung Release-Planung oder Product Roadmap zu gestalten.
6. „Wir machen Scrum, haben unser Sprint Backlog aber als Kanban-Board organisiert. Deswegen machen wir ScrumBan.“
Diese Erklärung finde ich immer wieder lustig, weil sie insbesondere ein sehr oberflächliches Verständnis der Kanban-Methode offenbart. Zum einen ist nirgendwo erwähnt, wie das Sprint Backlog aussehen muss und es kommt garantiert keine Scrum-Polizei vorbei und sperrt Leute ein, wenn das Sprint Backlog nicht Design XYZ entspricht. Jedes Scrum-Team ist komplett frei darin, die Gestaltung ihres Sprint Backlogs zu finden, die ihnen weiterhilft, die Arbeit im Sprint zu organisieren.
Darüber hinaus spricht die Kanban-Community heute auch vom sog. Proto-Kanban, wenn ein Team ihre Arbeit als Kanban-Board visualisiert hat, aber noch keine Work-In-Progress Limits etabliert hat oder die Durchlaufzeiten der Arbeit trackt oder auch nur die Spalten-Policies explizit gemacht hat. Wenn ich bei ScrumBan nachbohre, höre ich meistens sehr schnell heraus, dass beides nicht passiert. Zwar ist das WiP-Limit im Sprint meistens durch die Sprintlänge gedeckelt und könnte somit als WiP-Limit herhalten, bei den restlichen Kriterien höre ich aber immer wieder viel Luft nach oben aus den Beschreibungen heraus.
7. „User Storys müssen in der Form ‚Als … möchte ich …, damit …‘ geschrieben sein.“
Nein. Die Ursprung des Begriffs User Story kommt aus dem Extreme Programming (XP). Das erste XP-Team saß vor Ort beim Kunden und hat Leute in der Organisation dazu befragt, was sie bauen sollen. Dazu haben sie ihnen die Frage gestellt: „Stell‘ Dir vor, das System wäre jetzt fertig, und es wäre perfekt. Wie würdest Du das einsetzen?“ Auf Basis dieser Frage haben dann potentielle Benutzer (User) angefangen, Geschichten (Storys) zu erzählen, was den Begriff User Story motiviert hat. Tatsächlich denkt der allererste XP-Coach, Ron Jeffries über das weit verbreitete Satz-Template zu User Storys eher als „Stützräder zum Fahrradfahrenlernen“ nach – und hat sich öffentlich dafür entschuldigt, dass er das Template mal in Umlauf gebracht hat.
8. „Wir machen Scrum, aber das Daily nur alle zwei Tage.“
„Ehm, wie war nochmal die Übersetzung von ‚Daily‘ im „Englischen“? Genau genommen macht Ihr also kein Scrum, wenn ich das mal mit der pedantischen Position anmerken darf.“
9. „Der Product Owner ist nicht bei der Retrospektive dabei.“
Miteinander Reden ist besser als übereinander Reden. Diese Erkenntnis hatte irgendwann auch die Scrum-Community. Seitdem ist auch im offiziellen Scrum-Guide der Product Owner Teilnehmer in der Sprint Retrospektive.
10. „Scrum hat bei uns nicht funktioniert. Deswegen machen wir jetzt Kanban.“
„Wirklich? Was hat nicht funktioniert? Wie stellt Ihr jetzt sicher, dass das gleiche Problem nicht mit Kanban auch passieren wird?“
Ich glaube, es gibt gute Gründe, weswegen man Scrum nicht einsetzen sollte. Einen Großteil mache ich daran fest, ob ich für einen überschaubaren Zeitraum eine planbare Basis herstellen kann, in der sich nicht ändern darf. Demnach bemesse ich die Sprintlänge. Bei einer Sprintlänge von 2 Wochen habe ich eine durchschnittliche Reaktionszeit von 3 Wochen, bei 1-Wochen-Sprints von 1,5 Wochen, bei 2 Stunden Sprints von 3 Stunden im Durchschnitt. (Ach ja, die Sprintlänge ist nach unten nicht limitiert, so dass ich auch 1-Sekunden-Sprints machen kann, wenn ich das für sinnvoll halte.) Fehlt diese planbare Verlässlichkeit, ergibt es keinen Sinn, Sprints zu machen. Das Ergebnis des Plannings wäre zu häufig zu schnell wieder hinfällig und damit das ganze Erlebnis für alle Seiten frustrierend. Entweder schaffe ich es, diese Planbarkeit herstellen zu können, oder Scrum einzusetzen ist nicht angebracht. In letzterem Fall würde ich mit der Kanban-Methode liebäugeln, das wäre für mich aber nicht zwingend bindend. Vielleicht gibt es noch eine andere agile Methode, die noch niemand entdeckt hat.
Welche Mißverständnnisse treten bei Euch häufiger auf, die ich nicht erwähnt habe?
