[lwscologne] Re: [kanbandev] Transition from Scrum to Kanban: Real experience
- From: Kurt Häusler <kurt.haeusler@xxxxxxxxx>
- To: lwscologne@xxxxxxxxxxxxx
- Date: Mon, 28 May 2012 10:17:20 +0200
Hi Thomas,
absolute richtig, das habe ich auch gemerkt.
Es geht um den Unterschied zwischen "shallow" und "deep" Kanban.
Shallow Kanban ist ein Scrum-ähnliches Tool für die Planung von Arbeit. Es
bietet Sachen wie Vorhersehbarkeit, Classes of Service, und Freiheit von
Iterationen an. Change Management ist kein Teil davon weil entweder gibt es
keinen richtigen Prozess dahinter (weil es wird oft in einem
nicht-funktionsübergreifenden Team verwendet, oder nur ein kleines Teil der
Wertstromkette, und der Prozess geht nur um Dev und Test oder so), oder es gibt
gar kein Wünsch für Änderungen. Hier werden nur die erste 4 (oder manchmal doch
weniger) Kerneigenschaften von Kanban verwendet.
Deep Kanban, ist ein richtiges Change Management Tool. Hier sind alle 5
Kerneigenschaften relevant. Die 5. ist besonders relevant.
Wenn jemand redet über Wechsel von Scrum zu Kanban, es geht um shallow Kanban,
und ist fast immer ein Anti-Pattern, um die Vorteile von Scrum umzugehen.
Ein gutes Beispiel ist wenn Team P entwickelt ein Produkt und braucht das
manche Aufgaben sind von Team A, das Architektur Team geführt. Das ist ein
Smell in Firmen die vertrauen die meistens Entwickler nicht um
"Architektur"-Entscheidungen zu treffen, nur ein besonderes Team von "guten"
Entwickler "dürfen" das machen. (Also ein typisches Low-Trust Szenario).
Wenn Team A nach Scrum arbeitet, dann müssen Team P durchschnittlich 1,5
Sprints warten bis ihre Änderung fertig ist. In diesem Fall hat Scrum ganz
prima ein Problem erkannt. Das Team P enthält nicht die Fähigkeiten, oder
besser gesagt die Erlaubnis, ihre Software selbst zu entwickeln. Die bessere
Lösung wäre Team A aufzulösen, und die Mitglieder in den verschiedenen Produkt
Teams zu verbreiten. Manchmal aus politische oder kulturelle Gründe ist das
nicht akzeptable, also es wird versucht Team A in Kanban zu wechseln, einfach
um die Freiheit von Timeboxes zu bekommen. Das richtige Problem wurde nicht
gelöscht, sondern wurde ein Hack oder Workaround gefunden.
Dieses Blog schreibt noch ein Beispiel, unter Punkt 2:
http://www.clarus.co.nz/blog/three-reasons-to-choose-kanban-over-scrum-1.html
Ich denke shallow Kanban ist viel leichter, nicht nur bequemer für Teams und
Managers die Angst von Änderung haben, aber auch leichter von Consultants zu
verkaufen. Deswegen die meistens Leute denken das shallow Kanban irgendwie das
richtige Kanban ist. Leider. Ich glaube auch, die meistens Erfolgsberichte
(also Werbungen) über Kanban gehen um shallow Kanban. Ich glaube es ist sehr
schwer Erfolg mit deep Kanban zu bekommen. Es geht wahrscheinlich nur wenn die
Firma schon ziemlich Agile ist, und es gibt schon eine Bewegung weg von Command
& Control nach einer High-Trust Kultur zu werden.
Probleme erscheinen wenn jemand versucht Shallow Kanban mit einem breiten
Prozess abzudecken. Wenn viele Teams, Rollen usw sind involviert, dann richtig
Change Management, besonders kulturelle, ist benötigt, weil Pull, WIP
Limitierung, usw, kombiniert mit einer Low-Trust, Command & Control Kultur
führen nur zum Stress, Konflikt, und Verschwendung.
Persönlich für mich, das einzige Kanban ist deep Kanban. Ich würde immer
erklären das es geht meistens um sehr radikale Änderungen im Mindset und
Kultur. Die andere Aspekten wie Visualisierung, WIP Limitierung, Classes of
Service, usw, sind nur schöne Features davon.
Wechsel von Scrum zu (shallow) Kanban ist für mich einfach nur ein schlechtes
Hack oder Workaround weil jemand will nicht die richtige Probleme, die Scrum
ganz klug erkannt hat, lösen.
Aber es ist leicht zu verkaufen, und benötigt nicht das Management was ändern
muss, und liefert auch ein bisschen (ziemlich oberflächlichen) "Erfolg" worüber
der Consultant einen Bericht/Werbung schreiben kann, also ich denke wir werden
zukünftig leider sehr viel mehr davon sehen.
Es bringt aber nichts. Die meistens Firmen brauchen richtige Änderungen und
deep Kanban ist absolut prima dafür, shallow Kanban ist nur eine andere Art um
Karten um einem Board zu verschieben, allerdings ein bisschen "cooler" als
Scrum, aber noch weniger effektiv um richtige kulturelle Verbesserungen
umzusetzen. Ich denke es ist auch nicht nachhaltig, darüber soll ich ein
Blogpost schreiben.
Gruß,
Kurt
On May 27, 2012, at 8:43 PM, Thomas Epping wrote:
> Hallo Michael,
>
> Danke für den Hinweis auf diesen Bericht, unprätentiös trifft es wohl recht
> gut.
>
> Für mich verstecken sich zwischen den Zeilen weitere Botschaften. Besonders
> aufgefallen ist mir, dass des öfteren von einem Wechsel zu Kanban die Rede
> ist.
>
> Damit liest sich der Bericht für mich so, als wäre Kanban in diesem Fall kein
> Change Management (im Sinne von: Von Scrum durch Kanban zu X), sondern
> vielmehr direkt ein Ersatz für das vorher genutzte Scrum.
>
> Scheinbar gehen damit ebenso direkt einige Änderungen einher:
> *) Keine Iterationen ("We've been running iterations for 3 years and then
> switched to Kanban.");
> *) keine Schätzungen ("Points → No Estimates. This shift became possible with
> Kanban adoption.");
> *) keine Releaseplanung ("Initially we did strict release planning, but with
> Kanban adoption we quit this practice.").
>
> Der üblichen Rolle von Kanban entsprechend hätte ich eher Beschreibungen
> erwartet wie: "Wir haben durch Kanban festgestellt, dass wir uns von
> Iterationen lösen sollten."
>
> Die beschriebenen Veränderungen klingen plausibel - aber nicht, als wären sie
> durch Kanban (als einige von vielen vorstellbaren Veränderungen) ausgelöst
> worden, sondern als würden sie (recht selbstverständlich) mit Kanban einher
> gehen.
>
> Kannst Du (oder kann jemand) diesen Eindruck nachvollziehen?
>
> Viele Grüße,
> Thomas
>
> -------- Original-Nachricht --------
>> Datum: Sat, 12 May 2012 11:19:46 +0200
>> Von: Michael Mahlberg <mm@xxxxxxxxxxxxxxxxxxx>
>> An: lwscologne@xxxxxxxxxxxxx
>> Betreff: [lwscologne] Fwd: [kanbandev] Transition from Scrum to Kanban: Real
>> experience
>
>> Hallo allerseits,
>>
>> da die Frage des Übergangs von einem Prozess zum Anderen auch bei uns in
>> der LWS-Cologne immer wieder mal auftaucht und nicht alle der kanbandev
>> Mailingliste folgen:
>>
>> Der Artikel ( http://www.targetprocess.com/articles/agile50months/ ), der
>> hier so unprätentiös – und noch dazu unter Pseudonym – angekündigt
>> wird ist einer der detailliertesten Erfahrungsberichte zu dem Thema, die ich
>> in der letzten zeit gelesen habe!
>>
>> Cheers
>> Michael
>>
>> Begin forwarded message:
>>
>>> From: "fire_falcon_frag" <fire_falcon_frag@xxxxxxxxx>
>>> Date: May 10, 2012 6:27:28 PM GMT+02:00
>>> To: kanbandev@xxxxxxxxxxxxxxx
>>> Subject: [kanbandev] Transition from Scrum to Kanban: Real experience
>>> Reply-To: kanbandev@xxxxxxxxxxxxxxx
>>> x-mailer: Yahoo Groups Message Poster
>>>
>>> I've wrote an article that summarizes our transition from Scrum to
>> Kanban.
>>>
>>> http://www.targetprocess.com/articles/agile50months/
>>>
>>> Does anybody have similar experience?
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
Other related posts:
- » [lwscologne] Re: [kanbandev] Transition from Scrum to Kanban: Real experience - Kurt Häusler
