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.

Montag, 7. März 2016

Der Scrum Master als Übersetzer und Dolmetscher

Bild: Startup Stock Photos / Eric Bailey - CC0 1.0
Einer von vielen Diskussionspunkten bei einer Scrum Master-Selbsthilfegruppe einer Fachdiskussion am Wochenende: zu den vielen Aufgaben eines Scrum Masters gehören auch die eines Übersetzers und Dolmetschers. Zum Teil im wörtlichen Sinn (immer mehr IT-Fachkräfte in Deutschland sind zugewandert und sprechen kaum deutsch), vor allem aber im übertragenen - ein Großteil der Probleme zwischen Entwicklungsteams, Fachabteilungen, Management, Kunden und sonstigen Stakeholdern hat seinen Ursprung darin, dass es vielen Beteiligten nicht möglich ist ihr Anliegen so zu formulieren, dass alle anderen es verstehen und nachvollziehen können.

Hintergrund und Ursache dieses Phänomens ist meistens die unterschiedliche Herkunft, bzw. Bildungshistorie der verschiedenen Gruppen: Entwickler haben in der Regel ein Studium oder eine Ausbildung im Bereich der Informatik oder eines verwandten Bereichs hinter sich (z.B. ein Mathematikstudium oder eine Lehre als Mediengestalter), Manager haben meistens einen betriebswirtschaftlichen Hintergrund und Mitglieder der Fachabteilungen einen ihrer Spezialisierung entsprechenden, also Marketing, Vertrieb, Einkauf, Produktion, etc. Im Rahmen ihrer Sozalisierung haben nun diese verschiedenen Gruppen ein z.T. sehr spezifisches Vokabular und Begriffsverständnis erlernt, dass sie in ihrer alltäglichen Kommunikation unbewusst und völlig selbstverständlich einsetzen. Die Verständlichkeit dieser Begriffe für den jeweils anderen wird dabei nicht hinterfragt und einfach vorausgesetzt, und zwar nicht aus bösem Willen sondern aus dem Glauben heraus, dass sie allen gleichermaßen bekannt wären. Wenn das aber nicht der Fall ist entsteht eine Kommunikationsstörung: die Nachricht wird vor dem Absenden codiert, kann aber vom Empfänger nicht decodiert werden (siehe Sender-Empfänger-Modell).

Grundsätzlich ist es zwar so, dass Störungen dieser Art von allen Teammitgliedern erkannt und vermieden werden sollten, häufig scheitert das aber, wofür eine ganze Reihe von Gründen ursächlich ist: fehlende Empathie, fehlende Selbstreflektion, fehlendes Problembewustsein, fehlendes Ausdrucksvermögen und dergleichen mehr. Ohne Hilfe würden die Beteiligten in vielen Fällen aneinander vorbeireden, deshalb am Bedarf vorbeigehende Produkte entwickeln und mit sich mit großer Wahrscheinlichkeit irgendwann in Schuldzuweisungen und Konfrontationen verstricken. Da spätestens das definitiv ein Impediment wäre sollte jeder Scrum Master möglichst früh und vorbeugend den oben genannten Kommunikationsstörungen vorbeugen, entweder indem er es delegiert oder indem er sich selbst darum kümmert. Bleibt nur die Frage: wie soll das gehen?

Der einfachste Weg ist in diesem Fall die Einigung auf eine einheitliche Codierung, bzw. auf einen gemeinsamen Sprachgebrauch. Der Versuch diesen einheitlichen Sprachgebrauch herzustellen ist beispielsweise der Grund dafür, dass oft großer Wert auf das klassische User Story-Format gelegt wird (Als [..] möchte ich [...] damit ich [...] kann). Auch das Verfassen allgemein verständlicher Akzeptanzkriterien hilft dabei ein einheitliches Verständnis herzustellen (siehe auch Qualität ist mehr als Testen: User Stories und Akzeptanzkriterien). Mit diesen relativ einfachen Maßnahmen lässt sich bereits ein Großteil der Mißverständnisse ausräumen, für den verbleibenden Rest ist dann aber tatsächlich die Arbeit als Übersetzer und Dolmetscher nötig. Zum Einen im wörtlichen Sinn (an die Fachabteilung: "Wenn ein Entwickler sagt, dass er die Datenbank indiziert, meint er damit, dass er die Produkte für die neue Suchfunktion auffindbar macht") zum Anderen aber auch für die Vermittlung von Hintergründen (an den Entwickler: "Wenn das Management die neuen Funktionen unbedingt bis November haben will liegt das daran, dass dann das Weihnachtsgeschäft beginnt").

Eine derartige Dolmetscher-Tätigkeit kann zu Beginn in erstaunlichem Ausmass zeitfressend sein, weshalb sie häufig nicht erledigt oder aufgeschoben wird. Da aber ein gemeinsames Sprachverständnis (wenn es einmal da ist) große Verbesserungen der Produktivität und des Betriebsklimas bewirken kann sollte damit so früh wie möglich begonnen werden. Und je häufiger solche Übersetzungen stattgefunden haben, desto seltener werden sie benötigt. Dabei ist es übrigens unwichtig ob sich eine gemeinsame Sprachcodierung herausgebildet hat oder ob die des jeweils anderen decodiert werden kann - Hauptsache die Leute verstehen sich.

Donnerstag, 3. März 2016

A Toast to Complexity

Die Ausgangsfrage erscheint zunächst absurd: wie zeichnet man den Vorgang der "Zubereitung" eines Toastbrots? Was dann aber folgt ist ein bemerkenswerter Vortrag über den Einsatz von Visualisierungswerkzeugen zu Förderung und Verbesserung von Zusammenarbeit. Durchaus sehenswert.