Im Interview mit Thomas Schissler (artiso AG)

Kanban bietet mehr Freiheiten als Scrum – Agile Methoden im Vergleich
Kommentare

Kanban wird oft als Agile 2.0 bezeichnet. Doch kann diese Methode tatsächlich Scrum ablösen und ist das überhaupt ihre Absicht? Diese und mehr Fragen beantwortet BASTA!-Speaker Thomas Schissler im Interview mit dot.NET.

dot.NET: Herr Schissler, auf der BASTA! 2012 halten Sie eine Session mit dem Titel „Kanban, die Alternative zu Scrum?“. Welches sind die größten Unterschiede zwischen diesen beiden agilen Methoden?

Thomas Schissler: Genau genommen handelt es sich bei Kanban nicht um einen Prozess, sondern um eine Prozessverbesserungsmethodik. Kanban gibt also nicht vor, wie wir arbeiten und wie wir unser Projekt organisieren sollen, sondern lediglich, welche Aspekte wir berücksichtigten sollen, um unseren Prozess stetig zu verbessern. Daraus entstehen dann sehr individuelle Prozesse, die mit Kanban optimiert werden und es gibt natürlich auch einen Standard-Ansatz wie ein solcher „Kanban-Prozess“ aussehen könnte, der ist aber eher als Beispiel zu verstehen. Der größte Unterschied liegt wohl darin, dass Kanban mehr Freiheiten bei der Gestaltung eines Prozesses bietet als Scrum. Das bietet mehr Flexibilität, auf der anderen Seite bietet Scrum aber über seine Regeln klare Vorgaben und wer die einhält, bekommt schon eine recht gute Ausgangsposition für einen effizienten Prozess.

dot.NET: Und welchen Vorteil bietet nun Kanban im Vergleich zu Scrum?

Thomas Schissler: Leider gibt es Teams, für die Scrum nicht richtig funktioniert. Denken sie beispielsweise an ein Team, das hauptsächlich mit der Wartung einer Software beschäftigt ist und nur gelegentlich neue Funktionen einbaut. Wartungsaufgaben lassen sich nicht planen und wenn z.B. ein Fehler oder eine wichtige Anpassung erkannt werden, dann müssen diese schnell behoben werden und können nicht bis zum nächsten Sprint warten, um dann dort sauber eingeplant zu werden. In Kanban gibt es keine Regel, die eine Taktung ähnlich zu Sprints vorschreibt. Man kann eine solche Taktung beliebiger Länge (in diesem Beispiel wäre z.B. 1 Tag eine sinnvolle Taktgröße) nutzen oder eher nach dem „continous delivery“-Prinzip arbeiten. Viele Teams haben auch Probleme mit der in Scrum vorgesehenen Team-Organisation. Hier schreibt Kanban z.B. gar nichts vor. Der wohl größte Vorteil von Kanban ist aber, dass jedes Team sehr einfach damit beginnen kann und dazu nur geringe Veränderungen an den bestehenden Prozessen, Strukturen und Tools notwendig sind, während die Einführung von Scrum einer Revolution gleich kommt. Kanban muss also nicht unbedingt agil sein, auch Wasserfall-Prozesse lassen sich mit Hilfe von Kanban optimieren.

dot.NET: Ist ihrer Meinung nach Kanban in der Software-Entwicklung stets besser geeignet als Scrum oder gibt es auch Teams, die mit Scrum besser fahren?

Thomas Schissler: Nein, das kann man so auf keinen Fall sagen. Es ist nicht leicht, eine allgemein gültige Aussage zu treffen, wann welcher Ansatz besser geeignet ist. Als Coach versuche ich immer zuerst herauszufinden, ob bei einem Team Scrum funktionieren kann und ob die beteiligten Personen (auch außerhalb des Teams) sich darauf einlassen wollen. Wenn dies der Fall ist, dann würde ich dem Team empfehlen, Scrum zu machen, da sie durch die Scrum-Regeln und die inzwischen sehr umfangreichen Best Practices rund um Scrum eine gute Anleitung bekommen. Wenn sie dies alles umsetzen, dann bin ich mir sicher, dass dabei ein sehr guter Prozess entsteht. Kanban empfehle ich vor allem allen Teams, für die Scrum nicht funktioniert, weil sie die eine oder andere Regel von Scrum nicht einhalten wollen oder können. Dann ist es besser, einen schlüssigen Prozess individuell für dieses Team zu finden und diesen mit Kanban zu optimieren, anstatt eine eigene Abwandlung von Scrum zu machen. Es gibt auch verschiedene Bereiche innerhalb der IT, die sich für Scrum schon per se nicht eignen (z.B. Infrastruktur-Support o.Ä.), dort empfehle ich von Beginn an den Einsatz von Kanban.

dot.NET: Ist denn auch ein Mittelding zwischen Scrum und Kanban, also eine Art „Scrumban“, möglich? Oder heißt es hier „ganz oder gar nicht“?

Thomas Schissler: Das hängt ganz davon ab, wie man dieses Mittelding betrachtet. Es spricht natürlich überhaupt nichts dagegen, Aspekte aus Scrum, wie z.B. Daily Standup, Product Backlog, Review Meetings etc. in den eigenen individuellen Prozess zu integrieren, den ich mit Kanban optimiere. Ich würde das allerdings dann nicht Scrumban nennen. Es gibt hier die abenteuerlichsten Kombinationen wie z.B. dass Leute hergehen und in einem Scrum-Prozess die Tasks innerhalb eines Sprints mit Kanban verwalten wollen. Davon halte ich überhaupt nichts. Es gibt allerdings sehr wohl verschiedene Kombinationsmöglichkeiten, die sehr viel mehr Sinn machen. Wenn man die Software-Entwicklung im Rahmen eines komplexen Produktes, an dem mehrere Teams arbeiten, nur als einen Teilbereich ansieht, dann kann es beispielsweise Sinn machen, den übergeordneten Prozess von der Budgetierung eines Features bis hin zum finalen Deployment auf Basis von Kanban zu organisieren. In diesem übergeordneten Prozess wäre dann die Implementierung eines Features eine Station. Die Implementierung selbst inklusive aller Tätigkeiten, die das Team dafür ausführt (z.B. das Testen), könnte dann nach Scrum organisiert werden. In der Praxis funktioniert es nicht immer, dass ein Scrum-Team alle notwendigen Schritte bis zur Kundenauslieferung übernimmt. Gerade wenn mehrere Teams an einem Produkt arbeiten, liegen Schritte wie Integrationstests, Aktualisierung der Benutzerdokumentation, Anpassung der Vertriebs- und Marketinginformationen, Deployment etc. oft außerhalb der Teams. Hier kann eine Aufteilung des Gesamt-Lifecycles in zwei Ebenen, die dann auch durchaus mit unterschiedlichen Prozessen umgesetzt werden können, sinnvoll sein.

dot.NET: Werden nach Ihrer BASTA!-Session alle Teilnehmer auf Kanban umsteigen?

Thomas Schissler: Ich bin mir sicher, dass zumindest ein Teil der Teilnehmer danach Kanban nutzen wird, um Prozesse zu optimieren. Der Vortrag soll allen Teilnehmern hierzu eine gute Entscheidungsgrundlage geben. Ich freue mich aber genauso, wenn der eine oder andere am Ende die Gewissheit gewonnen hat, dass Scrum für ihn genau das Richtige ist und er keine Sorge mehr hat, dass er mit Kanban einen wichtigen Trend verpasst. Das Ziel meiner Session ist nicht, die Leute zu Kanban zu bekehren. Vielmehr sehe ich ein großes Informationsdefizit, was Kanban anbelangt, und viele Halbwahrheiten, die in diversen Medien kursieren. Mein Ziel ist, hier besser aufzuklären, damit die Leute nicht falsche Entscheidungen auf Grund von falschen oder fehlenden Informationen fällen. Oft höre ich die Einschätzung, Kanban sei Agile 2.0. Wer das nun aber als Ablösung Scrum durch Kanban interpretiert, entwickelt möglicherweise einen falschen Ehrgeiz, auf Kanban zu wechseln.

dot.NET: Vielen Dank für das Interview!

Thomas Schissler entwickelt seit 1996 Software, seit dem Jahr 2001 ausschließlich mit .NET. Neben seinen Aufgaben als Projektleiter, Softwarearchitekt und Coach versucht er auch noch einen Teil seiner Zeit mit der Kodierung zu verbringen. Er arbeitet in der Nähe von Ulm und beschäftigt sich momentan hauptsächlich mit Themen wie Softwarearchitektur und optimierten Softwareentwicklungsprozessen. Seine Schwerpunkte sind aktuell Team Foundation Server, komponentenorientierte Architektur und Qualitätsmanagement. Er ist Leiter der .NET Developer Group Ulm und bloggt so oft wie möglich unter www.artiso.com/problog. Als Sprecher ist er auf verschiedenen Konferenzen und bei User Groups unterwegs. Für sein Engagement für die .NET-Community wurde er 2008 erstmals mit dem MVP Award für den Bereich Team System ausgezeichnet.
Thomas Schissler auf der BASTA! 2012
  • Session: Kanban, die Alternative zu Scrum?
    19.09.2012 | 08:30 – 09:45 Uhr
  • Session: Stakeholder einbeziehen – Storyboarding und Feedback mit VS 2012
    20.09.2012 | 10:15 – 11:30 Uhr
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -