Agile / Projektmanagement / Software-Entwicklung

Scrumban – Mischmasch oder Fortschritt?

Neben den agilen Vorgehensmodellen Scrum und Kanban trifft man in der Praxis vermehrt Mischformen an, die beides miteinander verbinden. Aus Scrum oder Kanban wird Scrumban. Welche Vorteile oder Nachteile ergeben sich durch einen Mix? Wann ist so ein Vorgehen zu empfehlen und wann lässt man besser die Finger davon?

Richtung Pfeil

Zu Beginn eine kurze Begriffsklärung

  • Scrum ist ein agiles Framework mit bestimmten Regeln und Rollen. Schlank, einfach zu erlernen. Es hat seinen Ursprung in der Softwareentwicklung und kann generell für jede Art von Produktentwicklung zum Einsatz kommen. Wesentliche Elemente sind unter anderem inkrementelles und iteratives Vorgehen, also die schrittweise Erweiterung von Software in wiederholbaren Prozesszyklen. Das selbstorganisierte Team steht im Zentrum, begleitet von Product Owner und Scrum Master, Personen mit klar definierten Pflichten und Aufgaben.
  • Kanban konzentriert sich auf die Wertschöpfungskette einer Fertigung. Es stammt ursprünglich aus der Produktionssteuerung, wurde bereits nach dem zweiten Weltkrieg bei Toyota entwickelt und ist inzwischen ebenso bei vielen Softwareentwicklungsprojekten üblich. Ziel ist, einen optimalen Flow zwischen verschiedenen Arbeitsstationen herzustellen. Steigerung von Produktivität und Effizienz wird durch Einhaltung bestimmter Regelkreise erzielt. Das Pull-Prinzip (eine Aufgabe erst übernehmen, wenn eine andere abgeschlossen ist) und Vermeiden von Multitasking kennzeichnen das Vorgehen.

 

Gemeinsamkeiten und Unterschiede

  • Scrum und Kanban sind leichtgewichtige Methoden, bei denen die Beteiligten und ihre Mitwirkung im Vordergrund stehen. Menschen sind wichtiger als Prozessbeschreibungen. Hindernisse (Impediments) werden erkannt, visualisiert und vom Team gelöst. Kontinuierliche Verbesserung ist im Vorgehen integriert und Teil der Grundhaltung. Beide möchten Produktivität verbessern und Leerläufe vermeiden.
  • Scrum baut auf einem stringenteren Regelwerk auf, das alle Beteiligten einhalten müssen. Es ermöglicht die Planung von überschaubaren Zeiträumen. Die Einführung muss ganzheitlich erfolgen. Vorgegebene Prozessschritte oder Artefakte wegzulassen, ist von Nachteil, da sie aufeinander abgestimmt sind.
  • Kanban ist in der Anwendung flexibler. Es beschreibt Prinzipien, die man einhalten muss, aber nicht welche Meetings man dafür braucht oder welche Rollen es geben muss. Man kann mit Kanban jederzeit beginnen ohne bestimmte Voraussetzungen erfüllen zu müssen. Jeder IST-Zustand ist durch den Ansatz der kontinuierlichen Verbesserung erlaubt. Die Planung von Ergebnissen unter Berücksichtigung von Inkrementen oder Iterationen ist nicht möglich.

 

Warum Scrum + Kanban in einem?

Im Wesentlichen gibt es dafür folgende typische Szenarien:

  • 1) Scrum ist bereits eingeführt und man möchte das Verfahren erweitern, Überlastungen einzelner Mitarbeiter vorbeugen oder Schwierigkeiten bei teaminternen Prozessübergängen besser in den Griff bekommen. Z. B. mittels WIP-Limits (Work in Progress) schädliches Multitasking verhindern oder als ersten Schritt den Stau zwischen verschiedenen Rollen im Team visualisieren. Eine weiteres Thema könnte z. B. die Abarbeitung von Wartungsaufgaben betreffen, nicht planbare und dringende Erledigungen, für die eine sogenannte „Fast Lane“ zwecks Priorisierung in Frage kommen kann.
  • 2) Kanban kommt zur Anwendung und  Tasks werden im kontinuierlichen Fluss abgearbeitet. Für die Synchronisation von Ergebnissen mehrerer Teams werden Planungsübersicht und inkrementell lauffähige Software benötigt. Den Mitarbeitern im Team fehlen explizite Ziele. Für die Produktentwicklung möchte man einen Verantwortlichen etablieren und stärken. Lauter Beispiele, für die Scrum mit seinen Regeln und definierten Rollen Lösungen anbietet.
  • 3) Kanban oder Scrum sind im Einsatz. Die Methoden funktionieren nicht wie gedacht. Schwierigkeiten werden mehr statt weniger. Es ist klar, so geht es nicht weiter, Änderungen im Vorgehen sind notwendig.
  • 4) Alles Sonstige. Es gibt im Unternehmen Rahmenbedingungen, die unveränderbar sind und den Einsatz der Methoden laut Lehrbuch verhindern. Ein spezifisches Vorgehen ist wegen bestimmter Voraussetzungen notwendig, Sie möchten sich die eine oder andere Rosine herauspicken, quasi ein „Best of“ zusammenstellen, eventuell sonst nicht viel ändern oder überhaupt ihr eigenes Vorgehen etablieren. Sie möchten alles neu gestalten, das volle Programm, Scrum und Kanban auf einmal einführen. Oder einfach mal etwas Neues ausprobieren.

20150819_ImageShooting_01_5055

Was man dabei bedenken muss

  • Szenario 1 + 2. Sie sind gleichwertig. Eine Methode ist im Einsatz, durchaus bewährt, und es gibt Gründe, das Verfahren zu erweitern. Nachfolgend ein paar Fragen, die in einem solchen Fall das Unternehmen oder die betroffene Abteilung zuerst ehrlich beantworten sollte:
    • Haben wir alles ausprobiert, um die bestehende Methode so anzuwenden, wie sie gedacht ist?
    • Liegt es am Verfahren oder an bestimmten Personen, Teams, Bereichen, Interessen, dass wir Schwierigkeiten haben?
    • Werden die Hindernisse, die uns am Erfolg hindern, auch bei Änderung der Methode erhalten bleiben oder suchen wir eine Umgehungslösung?
    • Müssten noch weitere Personenkreise geschult werden, um Verständnis und Commitment zum derzeitigen Vorgehen zu erhalten?
  • Szenario 3. Es hilft nichts, Sie müssen sich die gleichen Fragen wie bei Szenario 1 + 2 stellen. Allerdings viel intensiver. Ihr Verfahren funktioniert nicht und Sie wollen versuchen, stattdessen auf zwei laufenden Pferden gleichzeitig zu stehen. Wahrscheinlich müssen Sie mehr ändern, als nur eine Methode.
  • Szenario 4. Finden Sie Antworten auf folgende Fragen:
    • Zum Anfang eine harte Frage. Wollen Sie Erfolg haben oder suchen Sie ein Alibi? Nach dem Motto, Sie wissen schon im Vorfeld, dass Sie verlieren werden, aber irgendwas muss man als Manager ja tun.
    • Welche der Rahmenbedingungen sind wirklich so unverrückbar? Sind alle unangreifbar oder kann man das eine oder andere Hindernis entschärfen?
    • Warum wollen Sie das Risiko eingehen, eine eigene Methode zu entwickeln?
    • Ist es realistisch, dass ihre Organisation und ihre Mitarbeiter diese Umstellung bewältigen?
    • Wollen Sie zuviel auf einmal? Wären kleinere Schritte sinnvoll?

 

Resümee

Wollen Sie methodisch etwas ausprobieren und Erfahrungen sammeln? Mitarbeiter, Organisation, Fachbereiche oder Vorstände an neue Verfahren gewöhnen? Lernen, was zu den Menschen in Ihrem Unternehmen passt? Ohne den Anspruch, damit alle vorhandenen Probleme zu lösen? Oder sehen Sie ihr Vorgehen als Zwischenschritt, um die bestehende Organisation in Richtung agiles Unternehmens weiter zu entwickeln, Stichwort Bimodale IT? Unter diesen oder ähnlichen Voraussetzungen können Sie alles ausprobieren und wieder korrigieren. Agilität beginnt in der Praxis, nicht in der Theorie. Wichtig ist, egal wofür Sie sich im Detail entscheiden, den Prozess einer regelmäßigen Verbesserung ernsthaft zu betreiben und sich erkannten Schwierigkeiten zu stellen. Hindernisse gehören aufgeräumt, nicht nur dokumentiert.

Rsum

Andererseits sollten Sie ernsthaft prüfen, ob nicht vorerst eine der beiden Methoden genügt und versuchen, bei einer zu bleiben und diese möglichst gut einzuführen bzw. weiter zu verbessern.

  • Szenario 1 und 2. Das sind die beiden Ausgangssituationen, in denen Scrumban eine Weiterentwicklung verspricht, auf inzwischen Bewährtem aufzubauen und um weitere Aspekte zu ergänzen. Vergessen Sie nicht. Es besteht kein Zwang, ihr Vorgehen um eine weitere Methode oder um ein weiteres Framework zu erweitern. Die Entwicklung muss dadurch nicht zwangsläufig besser werden. Es kann genug Arbeit sein, die Qualität bereits aufgebauter Prozesses zu erhalten.
  • Szenario 3. Das Erweitern mit Scrum oder Kanban kann in Frage kommen, falls Sie das Gefühl haben, das gewählte Verfahren passt nicht zu ihren Mitarbeitern oder ihrer Organisation. Die Wahrscheinlichkeit ist allerdings größer, dass Sie zuerst noch mehr an der Etablierung der bestehenden Vorgehensweise arbeiten müssen, bevor Sie daran denken können, diese zu erweitern.
  • Szenario 4. Überlegen Sie es sich gut. Das Herauspicken einzelner Elemente kann negative Konsequenzen mit sich ziehen. Als Beispiel: Etablieren Sie keinen Product Owner mit ensprechenden Rechten, wird die Produktentwicklung wahrscheinlich dauerhaft darunter leiden. Führen Sie eine Methode halbherzig und verwässert ein, dauert es vielleicht Jahre, bis der nächste Versuch unternommen werden kann. Scrum und Kanban gleichzeitig einzuführen, und zwar wirklich vollumfänglich, ist ein ehrgeiziger Plan. Und die Wahrscheinlichkeit, dass eine selbst entwickelte Methodik besser funktioniert als in der Praxis erprobte Verfahren, ist nicht ausgesprochen hoch.

 

Passende Artikel

Kommentare gesperrt.