Agilität und das VSM


 

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Viable System Model - SCRUM - Initialisierung
Beispielhafte Darstellung: Die Scrum Rollen während der Vorbereitung

SCRUM und das Viable System Model

Vor ein paar Tagen haben Heiko Bartlog und ich ein Experiment gestartet. Wir wollten herausfinden, wie sich das SCRUM Framework hinsichtlich seiner Rollen und Prozessphasen mit dem VSM abbilden lässt. Soviel sei an dieser Stelle schon verraten: Es hat erstaunlich gut geklappt! Das von mir gesteckte Ziel (“locker flockig in 30 Minuten”) haben wir dann “leicht” überschritten, dafür ist es umso gründlicher geworden 😉

Hierbei haben uns weder Feedback-Schleifen noch Bildstörungen davon abgehalten, die Session bis zum Ende durchzuziehen.  Die systematische Aufbereitung in Form eines “Papers” folgt alsbald .

Worum geht es konkret?

Die These lautet: SCRUM bietet sehr gute Vorraussetzungen für ein lebensfähiges System

Untersuchungsmethode: Die Idee besteht darin, das VSM als “Spielbrett” zu nutzen und die SCRUM Rollen als “Spielfiguren” einzusetzen, die sich im “Spielverlauf” (Prozess) über das VSM bewegen. Auf der übergeordneten Ebene geht es darum herauszufinden, wer welche Funktion(en) zum jeweiligen Zeitpunkt zum Erhalt der Lebensfähigkeit wahrnimmt (vgl. Hierarchie als kontextuelles Phänomen).

Daraus ist ein Google Hangout Video entstanden, welches aus drei Teilen besteht:

  1. Schnell-Vorstellung SCRUM
  2. Schnell-Vorstellung VSM
  3. Gemeinsame Denkrunde und schrittweise Erarbeitung des Prozesses

Erste Einsichten

Meine wichtigste Einsicht besteht darin, dass SCRUM in seiner Grundausprägung nur ganz oder gar nicht funktionieren kann. Das erklärt auch bestimmte Äußerungen, die sich über SCRUM beschweren – als sei es das neue Wasserfall … Zu diesem Thema hat Conny Dethloff einen wunderbaren Text geschrieben, sodass ich mir hier weitere Ausführungen erspare außer einer Anmerkung. Eine Methode funktioniert nie ohne die dazugehörige Haltung, die den gelebten Ethos der Zusammenarbeit widerspiegelt.

In der höchsten Verdichtungsstufe leitet sich für mich daraus ab, dass menschliche Selbstorganisation ohne “neue Autorität” in den heutigen Zeiten nicht Zukunftsfähig sein kann. Es macht im wahrsten Sinne des Wortes keinen Sinn.

Abschließend nochmals Danke an Heiko fürs Zusammen-Denken!

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][youtube id=”vETg2q1irs8″ width=”600″ height=”350″ autoplay=”no” api_params=”” class=””][/youtube]

Update (31.08.2016):

Ralf Westphal hat seine Gedanken zum Experiment zusammengefasst, sodass ich nicht umhin komme ein paar Ergänzungen vorzunehmen:

Es sollte nicht der Eindruck erweckt werden, als wenn SCRUM quasi automatisch ein lebensfähiges System erzeugt. Es sollte nur nachgewiesen werden das die Rollen je SCRUM-Phase gut im VSM verteilt werden können. Im Gespräch erwähne ich ja auch die Annahme, dass der Product Owner ein “guter” ist, der mit dem Team zusammenarbeitet und das Wissen in den Köpfen klug nutzt. Das heisst auch: Eben keine Überforderung, sondern das verteilen von Verantwortung. Alles andere ist Käse, da hat Ralf recht. Agilität lässt sich nicht befehlen, genauso wenig wie Kreativität oder Spontanität.

Die Prozessphasen sind in der Tat nicht zu sehen (per Markierung – wo bin ich?), jedoch sprechen wir über die jeweilige Phase.Wir gehen ja Schritt für Schritt durch die Phasen und schauen dann, welche Rolle in welchem System für welche VSM-Funktion zuständig/verantwortlich ist. Wie gesagt, die Markierung zur Orientierung fehlt – dieses Manko ist mir erst im Nachhinein bewusst geworden, sodass diese Aufbereitung auch Teil des angekündigten “Papers” sein wird.

Abschließend zur Umwelt: Ja, das stimmt alles, war aber im ersten Schritt noch nicht im Fokus. Wir haben einfach zusammen das erste Mal “live gespielt” und hatten gar nicht den Anspruch, das SCRUM-Team und die übergeordneten Rekursionsebenen einzubeziehen. Wir wollten erstmal klein starten und herausfinden, ob der methodische Ansatz überhaupt Sinn macht und ob wir zu einem brauchbaren Ergebnis kommen – also zunächst verifizieren und dann erst validieren. Das Thema “Enterprise Level SCRUM” habe ich auf dem Schirm, konnte dieses aber aus zeitlichen Gründen noch nicht angehen.

Auf jeden Fall sind Ralfs Fragen und Anmerkungen sehr wertvolle Impulse, die ich liebend gerne aufnehme. Es geht iterativ in kleinen Inkrementen weiter ;)[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

,

11 responses to “Agilität und das VSM”

  1. Sprechen ist halt flüchtig. Das merke ich auch immer wieder bei Softwareteams: sie reden – aber es bleibt keine Spur davon zurück. Was ist dann gemeinsam? Shared understanding? Hm… zweifelhaft, solange es kein gemeinsam erstelltes/abgesegnetes (mentales) Modell gibt.

    Ihr habt eine Spur hinterlassen: die Grafik. Und in der fehlt das, was ihr mehr oder weniger in eurem Sprechen bzw. Zeigen drin hattet? Dann ist auch das ein Ausdruck eures Denkens. Ihr habt hinterlassen, worauf ihr euch fokussiert habt: Rollen. Das ist mein Punkt: Ich halte es für den nicht so hilfreichen Fokus. Umso mehr, da es um Selbstorganisation geht, d.h. gar nicht Einzelne entscheidend sind, sondern immer mehrere Personen.

    Verräterisch ist auch die Formulierung “der PO, der mit dem Team zusammenarbeitet”. Das höre ich in Scrum-Organisationen häufig. Schade, denn die Formulierung drückt eine Trennung aus. Der PO ist in ihr nicht Teil des Teams, sondern extern und arbeitet mit “dem Team” zusammen.

    Ein PO arbeitet aber mit Entwicklern oder Testern oder Dokumentierern oder sonstwem zusammen, die wie er im selben Team sitzen. Das ist die Innensicht. Die Außensicht ist: PO und Entwickler usw. sind alle zusammen DAS Team.

    Den PO im (!) Team zu haben ist ja im Kern der cross-functionality. Ein Kunde – extern – mag mit dem Team zusammenarbeiten. Aber ein PO – intern – tut das nicht. Das wäre so, als würde ich mit mir selbst zusammenarbeiten 😉

    Mit “Enterprise Scrum” hat mein Punkt mit dem Unternehmen in der Umwelt nichts zu tun. Das (Rest)Unternehmen ist immer in der Umwelt eines Scrum-Teams, auch und gerade, wenn Scrum eben nicht skaliert werden soll.

    Doch das ist eben das Grundproblem vieler Scrum- oder Agile-Adaptionen: Sie übersehen, dass das (Rest)Unternehmen, also alles was nicht Scrum-Team ist, zur Umwelt gehört und daher entscheidenden Einfluss nimmt auf das Scrum-Team. Das ist so, als würden wir die Luft zum Atmen oder andere Menschen oder die Gesellschaft nicht in unsere Unternehmensplanung mit einbeziehen. Hauptsache Fokus auf Kunden und Nutzer. Was ja auch häufig genug der Fall ist, denn anders ist der Zustand der Welt nicht zu erklären.

    Das (Rest)Unternehmen ist daher nicht ein known blank spot in der Umwelt von Scrum-Teams, sondern häufiger (und im Bild) eher ein unknown blank spot. Vor allem, weil ja das (Rest)Unternehmen das Scrum-Team “gebiert”. Sozusagen die Mutter nicht im Bild aufzuführen, führt sofort in die Schieflage.

    Wie gesagt: Enterprise Level Scrum ist dafür gar nicht nötig. Davon würde ich auch erstmal die Finger lassen 😉

    • Mooooment. Die eine Grafik in Blogpost steht nur für die Visionsphase, wenn es noch kein Backlog gibt. Im Endeffekt ist eine Serie von Grafiken entstanden, je nach Phase.

      Außerdem: Ich wollte nie behaupten, dass SCRUM jetzt die Lösung aller Probleme sei. Und ja: Das Umwelt-Thema ist enorm wichtig. Kommt alles noch. Muss erstmal wieder denken.

  2. … das war ein kluges und gelungenes Experiment, vielen Dank Euch beiden.

    Marc: was meinst Du mit »in der höchsten Verdichtungsstufe«? Ich meine zwar, das Video aufmerksam verfolgt zu haben (bis zum Ende …), habe dieses Wort bzw. den Bezug zu Neuer Autorität nicht heraushören können …

    Thx und beste Grüße

    Frank

    • Du hast richtig gehört, im Experiment kommt der Begriff nicht vor. Aber in der Reflexion poppte der auf und ist dabei, ein Teil meines Poesie-Albums zu werden 🙂

  3. Erstmal vielen lieben Dank für eure Inspiration – klasse!
    Eure These war, zu prüfen, ob das Scrum-Team selbst ein Viable System im Sinne des VSM ist.
    Ich bin mir nicht ganz sicher, ob dann euer Ansatz richtig ist, über die “Phasen” = Events? die Rollen des Scrum Rahmenwerks auf das VSM zu mappen. Eine Phase ist für mich kein Viable System im eigentlichen Sinne. Mir ist deswegen nicht ganz klar warum ihr nicht das Scrum-Team an sich nehmt und dessen „Position“ im VSM bestimmt?

    Versuche ich das Scrum-Team als VSM zu betrachten und zu mappen komme ich auch schnell auf die Rollen und ich denke das ist falsch. Besser könnte es sein z.B. die Aufgaben, die die Rollen mit sich bringen und die und Artefakte im VSM unterzubringen. Weiterhin denke ich, dass insb. die Events Einfluss auf die Verbindungen der 5 VSM Subsysteme haben und hier dazu dienen die Varietät durch kontinuierliche Rückkopplung positiv (im Sinne der Komplexität) zu beeinflussen.
    Löse ich mich von den eigentlichen Rollen würde sich für mich, sehr vereinfacht, erstmal folgendes ergeben:

    System 5
    Die Basis hierfür ist Scrum selbst sowie die Unternehmens- und Scrum Werte, erweitert durch die individuellen Team Werte, Prinzipien und Verhaltensweisen. Geprägt wird dies stark aus dem Manifest für agile Softwareentwicklung. Beeinflusst wird das System 5 u.a. durch die Retrospektive aber auch durch Teamworkshops etc. Beteiligt sind alle Teammitglieder. Eine starke Rolle hat hier der Scrum Master.

    System 4
    Die Basis hierfür wäre die Produktvision bzw. die Vision über das Produkt hinaus. Kann das Produkt z.B. auch in anderen Märkten greifen? Weiterhin denke ich, dass hier die Team Vision eine große Rolle spielen kann. Aus dem Team heraus wird das System 4 u.a. durch das Refinement, das Review aber auch die Retro beeinflusst. Beteiligt sind alle Teammitglieder. Eine starke Rolle hat hier der Product Owner.

    System 1-3
    Dies ist die tägliche Arbeit des Teams. Basis hierfür sind alle Scrum Artefakte und alle Events, sowie die Selbstorganisation und Autonomie des Teams. Eine starke Rolle spielt bei der Regulation (System 2) der Scrum Master. Beteiligt sind wiederum alle Teammitglieder.

    Umgebung / Umwelt
    Dies ist differenziert zu sehen. Agiert das Scrum-Team direkt am Markt, so ist dieser selbstverständlich Teil der Umgebung, das Unternehmen selber aber auch (trotz Autonomie). Agiert das Scrum-Team ausschließlich innerhalb des Unternehmens oder über Teile des Unternehmens am Markt, so ist das Unternehmen selbst die Umgebung.

    In allen Fällen denke ich, dass das einzelne VSM Subsystem nicht explizit durch einzelne Scrum Rollen besetzt ist sondern inhärent immer im Team gesamtheitlich abgedeckt ist.

    Freue mich auf eure Kritik

    • Hi Frank, Danke erstmal das Du Dir die Mühe gemacht hast Deine Anmerkungen und Hinweise zu formulieren!

      Ich habe es wohl in meiner Filterblase versäumt zu benennen, was im Experiment betrachtet werden soll. Platt formuliert ging es dabei herauszufinden, ob und wie der Prozess eines SCRUM etwas mit einem lebensfähigen System zu tun hat.

      Die Idee die Artefakte (von mir übersetzt als Struktur) auf das VSM zu mappen, habe ich ehrlich gesagt noch nicht auf dem Schirm gehabt. Deine Aufstellung finde ich gut und nachvollziehbar. Da habe ich nichts zu kriteln 🙂 Deine Ableitungen und Zuordnungen decken sich m.E. auch mit Erkenntnissen aus dem Experiment.

      Es ist halt eine andere Sicht- und Herangehensweise – worüber ich ja auch froh bin, diese gelernt zu haben.

      Als Zwischenstand komme ich somit zu drei Fallunterscheidungen im Kontext von SCRUM und dem VSM:

      1. Fokus auf den SCRUM Prozess – phasenweise Betrachtung mit dem VSM im Hintergrund (wie vorliegend)

      2. Fokus auf die SCRUM Artefakte – Zuordnung der Artefakte in die Systeme (wie von Dir vorgeschlagen)

      3. Fokus auf das SCRUM-Team, welches in eine Organisation eingebettet ist und Unterstützung braucht (interne und externe Umwelt, das war einer von Ralfs Impulsen)

      Bzw. es gibt noch mindestens eine vierte Sichtweise – die alle o.g. Punkte vereint 🙂

      Wie bereits im Post geschrieben, eine Verdichtung all der Erkenntnisse steht noch aus.

  4. Hallo Mark und Heiko,

    erst mal vielen Dank für Euren tollen Beitrag und die wertvollen Impulse welche mich zu weiterem Nachdenke und nachlesen gebracht haben.

    Was mir aufgefallen ist, dass es sehr schwer ist die Handlungen und Rollen aus dem SCRUM Team den jeweiligen Systemen zuzuordnen. Letztlich würde fast jede Rolle irgendwie in jedes System passen. Denn es ist ja nicht so, dass einzelne
    Teammitglieder von der Kommunikation in den jeweiligen Systemen ausgeschlossen sind.

    Warum nicht gleich SCRUM in die darin vorhandenen Kommunikationssysteme zerlegen und versuchen diese dann den einzelnen Systemen im VSM zuzuordnen.

    Im untersuchten Fall geht es ja weder um ein biologisches noch um ein psychisches System, sondern um ein soziales System. Soziale Systeme sind, zumindest wenn es nach Luhmann geht Kommunikationssysteme.

    Vorschlag zur Systemstruktur:
    Kommunikationen zu einem Sprint in das „System 1“.
    Kommunikation aus der Retroperspektive in das „System 3*“
    Kommunikation zu Hindernissen in das „System 3“
    Kommunikation zum Backlog in das „System 4“
    Kommunikation zum Agilen Manifest in das „System 5“
    Kommunikation des Kunden in die „Umwelt“

    Dann noch die Kommunikationsstrukturen die es in den einzelnen Kanälen braucht. Möglicherweise auch mit Übersetzungen von IT Sprache in Kunden oder Managersprache usw.

    Das ist jetzt noch nicht zu Ende gedacht. Auch fehlt mir noch System 2.

    Was sagen die SCRUM Profis zu diesem Vorschlag? Könnte der Ansatz was bringen? Welche Kommunikationssysteme gibt es noch SCRAM?

    Herzliche Grüße
    Peter

    • Hallo Peter,

      mit schrecklich langer Leitung: Dank für den Vorschlag. Diese Sichtweise finde ich auch sehr spannend und “parallel-valide” zu den Sichtweisen von Frank und Ralf. Es scheint mir, als müssten wir uns mal in 2017 zu einem VSM-Camp treffen. München fehlt ohnehin noch auf meiner Tour 🙂

      Liebe Grüße,
      Mark

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.