Agile und Kanban

Eine zeitlang habe ich in Teams gearbeitet, in denen agile Softwareentwicklung eine Rolle spielte. Ein Satz, den ich in der Zeit oft gehört hatte, war:

Wenn dein Agile nicht funktioniert, dann weil du es nicht richtig machst.

Das ist, wenn man es genau betrachtet, eine in sich ziemlich geschlossene Aussage, denn die Frage ist, wie geht “richtiges Agile” und gibt es das überhaupt? Ich denke auch, dass man Meinungen finden kann, dass es bei Agile darum geht, für das entsprechende Team den richtigen Weg zu finden, was den Eindruck bestärkt, dass es ein “richtiges” Agile kaum geben kann.

Aber es gibt natürlich ein paar Grundprinzipien und Methoden, die angewendet werden: iterativer Entwicklungsprozess und Organisationsformen wie Scrum.

Ein paar Fragen stellten sich in meiner Praxis:

• Wie oft / in welchem Rhythmus finden Standups statt?
• Wie lange dauert ein Sprint?
• Wie gestaltet man das Review am Ende des Sprints?

Standups

Folgende Rhythmen habe ich erlebt:

• Mo, Di, Mi, Do, Fr (intuitiv das, was man denkt, was man tun sollte, aber imho sehr anstrengend)
• Mo, Mi, Fr (mag ich gar nicht, kann ich nicht empfehlen)
• Di, Do (funktioniert)
• Mo, Di, Mi, Do (war mein Vorschlag)

Mo, Di, Mi, Do

Mein Favorit, Standup Mo-Do, Freitag kein Standup, sondern selbstständige Arbeit. Das hat den Vorteil, dass sich bis Montag ganz viel angesammelt hat und man die Woche mit einem produktiven Standup startet. Natürlich nur bei Projekten, wo viel zutun ist.

Di, Do

Für laufende Projekte, die “rollen” aber trotzdem müssen Absprachen getroffen werden. Fand ich besser als nur ein Treffen die Woche, weil man auch mal fehlen kann und man ohnehin immer den Weg gehen kann, OK, wenn es nicht viel zu besprechen gibt, dann ist das Standup eben nach 5min vorbei.

Mo, Mi, Fr

Geht gar nicht, man hat dasselbe Problem wie mit einem täglichen Standup, was soll bitte nach dem freitäglichen Standup alles passieren, was Montag geklärt werden muss?

Sprints

Sprints entweder 2 oder 3 Wochen, nicht länger. Wichtig finde ich, dass man Sprints mit einem Review abschließt, aber es muss bitte nicht ein extra Review Meeting sein. Eine Review Runde zu Beginn des Planungstreffens für den kommenen Sprint reicht vollkommen.

Kanban

Viel weiß ich noch nicht über Kanban, aber ich mag die Grundeinstellung, dass, auch wenn etwas einmal nicht gut läuft, dass man das als Ausgangspunkt sehen kann, sich zu verbessern oder etwas besser zu machen. Wobei, wenn ich das jetzt noch einmal nachschlage, dass das vielleicht eher unter Kaizen fällt?

This is day 25 of my #100daystooffload series, a challenge to write 100 blog posts in a year.