Montag, 4. April 2016

The Agile Bookshelf: Vom Kriege

Bild: Wikimedia Commons/Vernet/Swebach - Public Domain
Agilität mag (auf Organisationslehre bezogen) ein relativ neuer Begriff sein, seine Vorformen reichen allerdings deutlich weiter zurück. Zu den bedeutendsten Vordenkern zählt dabei der preußisch-russische General Carl Philipp Gottlieb von Clausewitz (1780 - 1831), der in seinem Hauptwerk Vom Kriege bereits wichtige Aspekte des heutigen agilen Projektmanagements behandelte. Hintergrund waren allerdings noch nicht die Organisations- oder Produktentwicklung sondern die Kriegsführung und der Versuch diese beherrschbar zu machen. Neben verschiedenen militärspezifischen Begriffen sind dabei vor allem zwei zentrale Problemstellungen von Bedeutung, die unter anderen Namen bis heute weiterbestehen: die Friktionen und der Nebel des Krieges.

Friktionen
Unter Friktionen (Brüchen) verstand Clausewitz jegliche Abweichungen der Realität vom ursprünglich gedachten Plan, die dessen Durchführung erschwerten oder unmöglich machten.
So stimmt sich im Kriege durch den Einfluß unzähliger kleiner Umstände, die auf dem Papier nie gehörig in Betrachtung kommen können, alles herab, und man bleibt weit hinter dem Ziel. Diese entsetzliche Friktion, die sich nicht wie in der Mechanik auf wenig Punkte konzentrieren läßt, ist deswegen überall im Kontakt mit dem Zufall und bringt dann Erscheinungen hervor, die sich gar nicht berechnen lassen.
Clausewitz, vom Kriege
Wichtig für das Verständnis dieses Konzepts ist es, dass es sich bei Friktionen nicht um wenige große, sondern um viele kleine Ereignisse handelt, etwa um Verkehrsunfälle durch die einzelne Verbände plötzlich unbeweglich werden oder um lokale Wetterumschwünge durch die das Schießpulver feucht und unbrauchbar wird. Durch diese Vielzahl und Kleinteiligkeit wird nicht nur die Planung erschwert, auch Korrekturmaßnahmen sind schwierig, was mit dem zweiten großen Problem zusammenhängt:

Der Nebel des Krieges
Dieser etwas ungewöhnliche Begriff ließe sich am ehesten mit Kontrollverlust übersetzen: Der Kriegsverlauf ist weder überall gleichzeitig einzusehen noch überall gleichzeitig zu kontrollieren.
Der Krieg ist das Gebiet der Ungewißheit; drei Vierteile derjenigen Dinge, worauf das Handeln im Kriege gebaut wird, liegen im Nebel einer mehr oder weniger großen Ungewißheit. [...] Diese Schwierigkeit ist nicht unbedeutend bei den ersten Entwürfen, die auf dem Zimmer und noch außer der eigentlichen Kriegssphäre gemacht werden, aber unendlich größer ist sie da, wo im Getümmel des Krieges selbst eine Nachricht die andere drängt.
Clausewitz, vom Kriege
Ursache für diesen "Nebel" sind neben der fehlenden Einsehbarkeit und Kontrollierbarkeit vor allem zwei weitere Faktoren: die Volatilität (ist die Situation heute noch immer vergleichbar mit der von gestern?) und die Gleichzeitigkeit (alle Truppenteile geben ständig neue Zwischenstände durch, die sich in Summe kaum noch überblicken lassen).

Die zentrale Erkenntnis von Clausewitz war, dass durch die Friktionen und den Nebel des Krieges sämtliche Pläne bereits nach kurzer Zeit nicht mehr zu gebrauchen sind und angepasst werden müssen. Diese Anpassungen waren für ihn allerdings mit Risiken verbunden: eine umfangreiche Neuplanung wäre zu langwierig umd zum Zeitpunkt ihrer Fertigstellung bereits wieder überholt. Und zu häufige und nicht aufeinander abgestimmte Anpassungen können in Unordnung und Chaos führen. Um dem entgegenzuwirken setzte er auf zwei Eigenschaften, die er bei jedem Anführer für zwingend erforderlich hielt - Geistesgegenwart und Beharrlichkeit.

Geistesgegenwart
Für Clausewitz war Geistesgegenwart die auf Intelligenz und Entschlossenheit beruhende Fähigkeit, geänderte Rahmenbedingungen schnell zu erkennen und auf sie zu reagieren.
Bei dem coup d'oeil [dem Verstand, der auch in dieser gesteigerten Dunkelheit nicht ohne einige Spuren des inneren Lichts ist] und der Entschlossenheit liegt es uns ganz nahe, von der damit verwandten Geistesgegenwart zu reden, die in einem Gebiete des Unerwarteten, wie der Krieg ist, eine große Rolle spielen muß; denn sie ist ja nichts als eine gesteigerte Besiegung des Unerwarteten.
Clausewitz, vom Kriege
In heutigem Verständnis ist das, was Clausewitz unter Geistesgegenwart verstanden hat, im Wesentlichen identisch mit Agilität. Bemerkenswert ist an dieser Stelle auch, dass er sein Geistesgegenwarts-Konzept bereits als empirisch und datengetrieben beschrieb. Oder mit seinen Worten: "so wird das wirklich Vorhandene die Daten abgeben für das Unbekannte, zu Erwartende, was gefunden werden soll." Damit war er wesentlich fortschrittlicher als andere Anführer seiner Zeit, die sich noch weitgehend von "Genie" oder "Intuition" leiten ließen.

Beharrlichkeit
Der Beharrlichkeits-Begriff von Clausewitz enthält die modernen Begriffe Fokus und Vision. Durch Beharrlichkeit soll verhindert werden, dass Anpassungen beliebig vorgenommen werden.
Im Kriege mehr als irgendwo sonst in der Welt kommen die Dinge anders, als man sich es gedacht hat, und sehen in der Nähe anders aus als in der Entfernung. [...] Wer diesen Eindrücken nachgeben wollte, würde keine seiner Unternehmungen durchführen, und darum ist die Beharrlichkeit in dem gefaßten Vorsatz, so lange nicht die entschiedensten Gründe dagegen eintreten, ein sehr notwendiges Gegengewicht.
Clausewitz, vom Kriege
Wichtig an dieser Stelle ist der Einschub im letzten Satz, "so lange nicht die entschiedensten Gründe dagegen eintreten ...". Durch ihn grenzt er die Beharrlichkeit ab vom Methodismus (auch diesen Begriff definiert er in Vom Kriege), der immer dem selben Muster folgt. Beharrlichkeit tut das dagegen nur so lange wie es Sinn ergibt, weshalb auch sie einem datengetriebenen Anpassungs-Ansatz unterliegen muss.

Mit seinen Konzepten der Friktionen, des Nebels des Krieges, der Geistesgegenwart und der Beharrlichkeit hat Clausewitz also zentrale Aufgabenstellungen und Lösungsansätze der agilen Vorgehensmodelle vorweggenommen. Dass das heute nicht (mehr) bekannt ist, ist bedauerlich, aber erklärbar. Es dürfte zum einen an seiner aus heutiger Sicht umständlichen Sprache liegen und zum anderen an der Abkehr Deutschlands von seinen militärischen Traditionen. Wer sich davon nicht abhalten lässt kann sich allerdings einige interessante Inspiratonen an einer Stelle holen, an der man sie normalerweise nicht erwarten würde.

Donnerstag, 31. März 2016

Kommentierte Links (XI)

Grafik: Pixabay / Geralt - Lizenz

  • Gunter Dueck: Duales Management – geht das überhaupt?

    • Gunter Dueck spricht in seinem Blog ein grundlegendes Problem vieler großer Unternehmen an. So lange Mitarbeiter sich auf den unteren Karrierestufen befinden wird ihnen selbstständiges und kreatives Denken systematisch abgewöhnt. Wichtige Informationen werden ihnen vorenthalten, bei Entscheidungen werden sie nicht konsultiert, einmal getroffene Beschlüsse können von ihnen nicht in Frage gestellt werden. Ab einer bestimmten Stufe aufwärts soll aber dann plötzlich alles ganz anders sein. Auf einmal sollen die zum Manager beförderten Kollegen genau das können was man ihnen jahrelang wegtrainiert hat. Auf einmal sollen sie Dinge hinterfragen, neue Wege gehen und Alternativen aufzeigen. Um es mit Duecks Worten zu sagen: "Natürlich geht das im Einzelfall – aber geht das in der erforderlichen Mehrheit? Ich glaube ja nicht!"

  • Barbara Kuchler: Ineffizienz kann sehr effizient sein

    • Dass man ein Unternehmen/eine Behörde "kaputtsparen" kann ist grundsätzlich nichts Neues, wie das im Einzelfall aussieht bleibt dagegen oft unklar. Dankenswerterweise bringt Barbara Kuchler etwas Licht ins Dunkel und zeigt anhand der staatlichen Verwaltung ein häufiges Fehlverhalten auf. Bedingt durch Sparvorgaben wurden Polizei, Sozialbehörden und Kommunalverwaltungen so zusammengekürzt, dass kein "Leerlauf" mehr bestand - durch den Normalbetrieb waren die Mitarbeiter zu 100% beschäftigt. Dieser an sich begrüßenswerte Zustand erwies sich 2015 als verhängnisvoll: die bereits zuvor bis zum Anschlag ausgelasteten Beamten konnten den plötzlichen Mehraufwand durch die 2 Millionen Flüchtlinge nicht bewältigen. Für die verheerenden Folgen steht mittlerweile sinnbildlich das Versagen des Berliner Landesamtes für Soziales und Gesundheit. Die abzuleitende allgemeine Aussage - bei sich ändernden Rahmenbedingungen müssen Organisationen entweder über personelle Reserven verfügen oder laufende Tätigkeiten verschieben können. Sonst kollabieren sie.

  • Michael Nygard: The new normal - embracing failure with netflix, the chaos monkey, and chaos kong

    • Für die meisten klassisch aufgestellten Unternehmen dürfte das, was die IT-Abteilung von Netflix hier betreibt, wie der nackte Wahnsinn erscheinen: Ein Programm namens "Chaos Monkey" simuliert in unregelmässigen Abständen die Abschaltung willkürlich ausgewählter Server, ein zweites namens "Chaos Kong" macht das gleiche mit ganzen Rechenzentren. Der Grund für den Einsatz dieser beiden Tools ist Qualitätssicherung - nur wenn der Netflix Streamingdienst trotz dieser Ausfälle weiterhin verfügbar ist sind die Qualitätskriterien erfüllt. Das wirklich Bemerkenswerte daran: diese Tests finden nicht etwa auf einer separaten Entwicklungsumgebung statt sondern im Produktionssystem, also dort wo sich zum selben Zeitpunkt hunderttausende Kunden ihre Filme ansehen. Beeindruckend.

  • Shane Hastie: Seven sins of scrum and other agile antipatterns

    • Ein Bericht von der Agile India 2016 in Bangalore: in einem sicherlich launigen Vortrag von Sean Dunn und Chris Edwards ging es um "Die sieben agilen Todsünden und ihre Antipattern":
    1. Processes & Tools Over Individuals & Interaction 
    2. Status Over Flow of Value
    3. Stories Over Strategy
    4. Crap Over Craftsmanship
    5. Iterations Over Releases
    6. Illusion Over Reality
    7. Organizational Hacks Over Leadership
    Wer in Konzernen gearbeitet hat dürfte einiges sofort wiedererkennen. Sehr amüsant übrigens auch das hier zitierte Manifesto for Half-Arsed Agile Software Development. Kannte ich noch gar nicht.

  • Aaron Griffith: Mob programming for the introverted

    • In einem sehr langen Artikel spricht Aaron Griffith über Mob Programming (the whole team works on the same thing, at the same time, in the same place, on the same computer). Darüber was das ist, wo es herkommt, wie es eingesetzt wird und was es für einen intovertierten Menschen wie ihn bedeutet, als Teil eines "Mob" gemeinsam vor einem Computer zu sitzen und kollektiv zu programmieren. Auch ohne Programmierkenntnisse sehr lesenswert. Was ich faszinierend finde: in seiner Firma wird Software nur noch im Mob Programming erstellt - ein absoluter Kulturbruch.

Montag, 28. März 2016

As summer time, I want to be simulated

Grafik: Pixabay / Julius H. - Lizenz
Angesichts der aktuellen Zeitumstellung von Winter- auf Sommerzeit ist mir eine User Story eines vergangenen Projekts wieder eingefallen, die seinerzeit zu Diskussionen darüber geführt hat, wie Stories formuliert sein müssen, bzw. dürfen. Zum Hintergrund: wir hatten einen Bug entdeckt, der nur während einer Zeitumstellung auftrat. Um zu überprüfen ob er tatsächlich repariert war mussten wir eine Umstellung der Systemzeit simulieren (ein halbes Jahr warten wollten wir nicht). Da das System von sich aus nicht der Lage dazu war, erweiterten wir es, wozu diese Story verfasst wurde:1


Auf den ersten Blick eine klassische User Story mit dem bewährten Format. As <Role> I want to Perform <Action> so that I can have a <Business Value>. Auf den zweiten Blick durchaus problematisch, denn es fehlt der konkrete Endanwender/Kunde/Auftraggeber, für den diese Anforderung geschrieben wurde. Gerade dafür sind User Stories aber eigentlich da, sie sollen fachlich formuliert und geschnitten sein, damit die gerade genannten Personen sie verstehen und ihr Ergebnis überprüfen können. Hätte man also nicht eher formulieren müssen Als <Anwender> möchte ich auch nach der Zeitumstellung <Aktion X durchführen können> um <Mehrwert Y zu haben>? Im Prinzip schon, in diesem Fall wäre das allerdings schwierig gewesen. Der Bug trat in einer internen Logging-Funktion auf, die über die Benutzeroberfläche nicht einsehbar war.

Die an vergleichbaren Stellen oft auftretende Notlösung ist die Formulierung <Als Entwicklungsteam möchte ich> ... . Das ist zwar in speziellen Einzelfällen möglich, grundsätzlich halte ich es aber für ein Antipattern von dem ich meinen Teams immer abrate. Ein Team entwickelt Software so gut wie nie für sich selbst sondern fast immer für jemanden anderen, weshalb ich diese Formulierung sehr problematisch finde. Wenn aber eine Story sehr technisch/backendlastig ist, wegen der sonst auftretenden Kommunikationshindernisse aber die klassische Formatierung beibehalten werden soll, dann können durchaus kreative Formulierungen wie die in dem oben genannten Beispiel benutzt werden. Selbst wenn sie auf den ersten Blick albern wirken mögen - die Kollegen aus den Fachabteilungen können sie verstehen und die dafür nötigen Ressoucen freigeben, und das ist es worauf es ankommt.


1Um sicherzustellen, dass nur Features mit Nutzerbezug entwickelt wurden gab es die Vorgabe aus allen Anforderungen User Stories zu machen, wie hier zu sehen mit z.T. schrägen Ergebnissen

Donnerstag, 24. März 2016

Perfection Game


Im Normalfall beginne ich die Retrospektiven meiner Teams mit einer Stimmungsabfrage. Ich bitte alle Teilnehmer auf einer Skala von 0 (schlecht) bis 10 (gut) ein Kreuz zu machen um zu zeigen wie sie sich fühlen und wie zufrieden sie sind. Im Anschluss bitte ich um eine kurze Erklärung, um zu erfahren worauf dieser Wert beruht. Zum einen ist das das symbolische "Setting the Stage", mit dem die Veranstaltung eingeleitet wird, zum bekommen ich und alle anderen dadurch einen Eindruck von der aktuellen Verfassung desjenigen der gerade vorträgt. Nach meiner Erfahrung ist das ein sehr gewinnbringendes Vorgehen, wenn auch kein völlig unproblematisches.

Ein großes Problem bei der Abfrage von derartigen Stimmungsbildern ist, dass diese sehr häufig auf diffusen Gefühlslagen beruhen. Die Teilnehmer können oft nicht genau artikulieren wo sie ein Problem sehen, weshalb es sehr schwierig sein kann Verbesserungsmassnahmen abzuleiten. Ein anderes Problem ist die Scheu vor Extrem-, bzw. Grenzwerten. Selbst wenn jemand nicht sagen kann wie sich eine Situation verbessern ließe wird er nur in den seltensten Fällen die 10 ankreuzen, Luft nach oben ist schließlich immer. In Folge dessen erscheinen auch sehr zufriedenstellende Situationen mitunter negativer als sie eigentlich sind.

Eine Methode um diese Probleme zu umgehen ist das Perfection Game. In ihm wird davon ausgegangen, dass grundsätzlich jede Situation alle Erwartungen erfüllt (→ perfekt ist), es sei denn man kann konkret benennen was zu dieser Perfektion noch fehlt. Dabei muss für jeden Schritt den man auf der Skala nach unten, bzw. nach links geht eine Möglichkeit zur Verbesserung genannt werden. Wer keine nennen kann muss sein Kreuz auf der 10 machen. Natürlich kann es auch dann noch sein, dass der eine oder andere mit dem Ist-Stand nicht zufrieden ist, da er aber anscheinend im Augenblick nicht verbessert werden kann, ist er das Perfekteste was zur Zeit zu erreichen ist.

Insgesamt bringt das Perfection Game drei große Vorteile mit sich: diffuse Wahrnehmungen fließen weniger in die Lagebewertungen ein, die Scheu vor Grenzwerten wird umgangen und es werden von Anfang an Lösungsmöglichkeiten gesammelt statt Probleme zusammengetragen. Ein Nachteil ist dagegen, dass die Stimmungsabfrage nicht mehr für ein "Setting the Stage" genutzt werden kann sondern ein direkter Teil der inhaltlichen Arbeit ist. Wenn man das Perfection Game einsetzt sollte also vorher die Veranstaltung mit einer anderen Methode eingeleitet werden.

Montag, 21. März 2016

Deine Muda: Under-Utilization

Durch Zufall bin ich auf dieses Video gestossen. Es zeigt die verschiedenen Arten von Verschwendung aus dem Toyota-Produktionssystem, grafisch aufbereitet und mit Beispielen angereichert. Nett anzusehen.



Erst auf den zweiten Blick fällt auf, dass die Liste erweitert wurde. Laut Toyota existieren im Lean Management nämlich lediglich sieben Arten der Verschwendung:
  1. Transportation
    Güter werden weit transportiert und sind in dieser Zeit nicht für Wertschöpfungen nutzbar
  2. Inventory
    Güter werden in unnötig großen Mengen gelagert und binden dadurch Kapital
  3. Motion
    Personen müssen weite Wege gehen und können in dieser Zeit nicht produktiv tätig sein
  4. Waiting
    Güter oder Personen müssen darauf warten, dass vorgelagerte Prozessschritte beendet werden
  5. Over-Processing
    Komplizierte oder redundante Prozesse binden die Kapazitäten der Mitarbeiter
  6. Over-Production
    Güter werden erzeugt obwohl sie nicht oder noch nicht benötigt werden
  7. Defects
    Güter werden fehlerhaft erzeugt und müssen nachträglich repariert werden
In diesem Video kommt zu den klassischen sieben Arten noch eine achte, und dazu eine in ihrer Tragweite nicht zu unterschätzende:
  • Under-utilized People
    Das Potential und die Fähigkeiten der Mitarbeiter werden nicht genutzt
Ein Verhalten das in vielen Organisationen zu beobachten ist - das Wissen der Mitarbeiter wird nicht (an)erkannt oder bewusst ignoriert. Es nicht zu nutzen ist Verschwendung im wahrsten Sinn des Wortes, weshalb die Erweiterung der Liste für mich absolut Sinn macht. Wenn ich zukünftig jemandem die Verschwendungsarten erkläre ist Nr. 8 auf jeden Fall dabei.

Donnerstag, 17. März 2016

Ein Template für effektive Meetings

Ein sehr hilfreiches Instrument, inspiriert von Mike Sutton's Meeting Facilitator Canvas. Macht Meetings zwar leider nicht automatisch effektiver, hilft aber sehr dabei. Was mir besonders gefällt: Vorbereitung, Durchführung und Dokumentation können mit einem einzigen Dokument durchgeführt werden. Und der eingeschränkte Platz verhindert Prosa und erzwingt eine Konzentration auf das Wesentliche.


 Gibt es auch als PDF-Download. Expertentip: Auf Din A 2 ausdrucken und an die Wand hängen.

Montag, 14. März 2016

Ist der Scrum Master ein Manager?

Bild: Unsplash / Adetola Afolabi - Lizenz
Auf der Agile Cologne am letzten Wochenende ist in einer Session ein Klassiker unter den Agile-Themen wieder hochgekommen: Ist der Scrum Master ein Manager? Soll er es sein? Will er es sein? Macht es Sinn, wenn er es ist? Die meisten Anwesenden beantworteten diese Frage spontan mit Nein, was ich allerdings für falsch halte. Ich glaube, dass ein Scrum Master (zumindest in größeren Unternehmen) nur funktionieren kann wenn er diese Rolle, bzw. diesen Status hat. Andererseits glaube ich aber auch verstehen zu können, warum Viele sich nicht so sehen möchten. Für sie ist der Begriff vorbelastet und hat ein Image das man vermeiden sollte. Und das ist sogar bis zu einem gewissen Grad zutreffend.

Anders als weithin angenommen stammt der Begriff des Managers nicht aus dem Englischen sondern aus dem Lateinischen wo er ursprünglich Manum agere (an der Hand nehmen und Führen) geschrieben wurde. Die in dieser Herkunft erkennbare Funktion des "Mikro-Managens" (der detaillierten Anleitung einzelner Mitarbeiter) hat sich in den meisten Unternehmen bis heute erhalten und steht in deutlichem Widerspruch zu den agilen Werten und Prinzipien. Aus diesem Grund möchten viele Scrum Master explizit keine Manager sein. Auf der anderen Seite ist Manager sein heute aber mehr als nur eine Tätigkeitsbeschreibung - in großen Organisationen ist es eine Hierarchiestufe. Und um Impediments lösen zu können muss man häufig auch auf dieser Stufe operieren können.

Das naheliegendste Beispiel: in den meisten Unternehmen muss man ein Manager sein um ein Budget zu haben. Von der Buchung einer Workshop-Location bis zum Einkauf von Post-Its - viele Dinge kosten Geld, und ohne eigenes Budget verfängt man sich schnell im bürokratischen Dickicht von Anträgen, Begründungen, Abrechnungen und Sparvorgaben. Mitunter dauern solche Prozesse Monate und können in dieser Zeit die Produktivität hemmen und sogar stillegen. Mit eigenem Budget ist es dagegen möglich schnell (agil) auf einen Bedarf zu reagieren und ihn zu erfüllen.1

Ein zweites Beispiel sind die Eskalationshierarchien. Ein häufiges Muster ist hier die Überplanung von Mitarbeitern durch ihre Vorgesetzten, etwa wenn sie theoretisch zu 50% in einem Projekt und zu 50% in der Linie verplant sind, sie in der Linie aber so viele Aufgaben bekommen, dass sie in dieser Zeit nicht zu erledigen sind. Ohne Manager-Status müsste dieses Problem an eben jenen Vorgesetzten eskaliert werden von dem es ausgeht, was dieser in fast allen Fällen abschmettern würde. Mit Manager-Status kann man sich an die nächsthöhere Instanz wenden, wo das Problem (hoffentlich) neutraler betrachtet wird.

Als drittes Beispiel könnte man den Zugang zu höheren Ebenen nennen. Die Kalender von Geschäftsführern, Vizepräsidenten und sonstigen Spitzenkräften sind häufig so eng getaktet, dass man als "normaler Mitarbeiter" Termine erst in mehreren Monaten oder gar nicht bekommen kann. Da auch dadurch die oben genannten Blockaden entstehen können ist der Manager-Status mitunter zwingend notwendig, damit man schnelle Entscheidungen der oberen Ebene erreichen und dadurch agil und handlungsfähig bleiben kann.

Und derartige Beispiele gäbe es noch viel mehr.

Im Übrigen: Was passiert wenn der, bzw. die Scrum Master keinen Manager-Status haben, kann man sehr schön am Titel der Session festmachen in der diese Diskussion stattfand - er lautete "Warum scheitern so viele agile Projekte?". Die zu niedrige Hierarchiestufe der Scrum Master ist dabei zwar nicht notwendigerweise der Hauptgrund, ein wichtiger Faktor ist es aber auf jeden Fall. Alle Scrum-Projekte deren Scheitern ich beobachten durfte hatten eines gemeinsam: ausserhalb ihrer Teams hat niemand auf die Scrum Master gehört, die großen Entscheidungen wurden "vom Management" getroffen. Und in dem hat es praktisch immer an agilem Mindset und Know-How gefehlt.


1Zu beachten ist an dieser Stelle, dass hier von einem Changemanagement- oder Prozessmanagement-Budget die Rede ist. Das Produktmanagement-Budget macht beim Product Owner mehr Sinn.

Donnerstag, 10. März 2016

Scrum Master in die Schule!

Bild: Wikimedia Commons/Fredler Brave - CC0 1.0
Um meine Dolmetscher-Qualitäten auszutesten habe ich mich gestern einer Herausforderung der besonderen Art gestellt und bei einem "Berufs-Speeddating" einer Schulklasse erklärt, was ich in meinem Beruf so mache. Die Überlegung dahinter: If I can make it there, I can make it in every Fachabteilung, oder klarer ausgedrückt - wenn ich es schaffe einem reizüberfluteter Haufen 17-jähriger zu erklären was agile Software-Entwicklung ist, dann schaffe ich es bei jedem.

Sich dafür eine Schule auszusuchen ist übrigens naheliegender als man denkt, schließlich kann man hier ein Werkzeug ausspielen, das auch im Job sehr hilfreich ist: Visualisierung. In jeder Schulklasse steht eine große Tafel und es gibt genug Kreide, man kann also alles an Grafiken, Diagrammen und Bildern auffahren was man hat. Gleichzeitig haben Schulklassen und Fachabteilungen einiges gemeinsam - beide Gruppen wissen, dass Software irgendwie wichtig ist, beide haben kein vertieftes technisches Wissen, dafür aber zumindest Grundlagen, beide sind dankbar wenn man ihnen etwas verständlich erklärt, beide sind hochgradig heterogen, so dass man gezwungen ist immer wieder Feedback und Wissensstände abzuholen und zu bedienen.

In Folge dieser Faktoren ist die Art der Erklärversuche zwangläufig ähnlich. Eher fachlich als technisch, mit vielen grafischen Darstellungen (die man mit dem Handy abfotografieren und mitnehmen kann), ohne Fachchinesisch und mit prägnanten und gut zu erinnernden Formulierungen. In vieler Hinsicht könnte man die Situation mit Pitch-Meetings vergleichen, wie ich sie in verschiedenen Firmen bereits hatte. Sogar Timeboxing gab es, denn auch die Schüler hatten Anschlussmeetings - mit einem Maurer, dem Objekt des nächsten Berufs-Speeddatings, danach mit einem Anwalt, dann mit einem Zahnarzt.

Ich kann nach dieser Erfahrung die Teilnahme an solchen Veranstaltungen nur empfehlen. Man nimmt selber etwas für sich mit, bekommt unmittelbares Feedback und bringt auch den Schülern etwas: zwei Mädchen sagten mir im Anschluss, dass sie die IT jetzt zum ersten mal als mögliches Berufsfeld wahrnehmen würden. Vielleicht die Scrum Masterinnen der nächsten Generation.