Donnerstag, 27. Juni 2019

Change Fatigue (II)

Bild: Pixabay / TotumRevolutum - Lizenz
Altersbedingt (Ende der 70er geboren) gehöre ich zu der Generation, deren Erwachsenwerden mit dem endgültigen Siegeszug der Digitalisierung zusammengefallen ist. Bedingt dadurch habe ich auch die letzten Rückzugsgefechte der Menschen erleben dürfen, die glaubten, dem mit Einmal- oder Teilaufwänden begegnen zu können. An meiner Universität etwa beharrten manche Professoren auf der Nutzung von WordPerfect. Ein Textverarbeitungsprogramm gelernt zu haben sollte ihrer Meinung nach für den Rest ihres Lebens reichen, das Erlernen eines zweiten (MS Word) lehnten sie ab. Auch in meinem ersten Job traf ich vergleichbare Menschen. Word und Outlook hatten sie sich unter Schmerzen beibringen lassen, der Nutzung von Excel und Powerpoint verweigerten sie sich. Die Begründung: irgendwann müsse es doch genug sein mit "diesen immer neuen Computerprogrammen".

Zwar sind das Anekdoten der Vergangenheit, man kann sie aber auch als Parabel für die Gegenwart einsetzen. Damals wie heute werden die Menschen in ihrem Berufsleben mit immer neuen Tools konfrontiert. Damals Outlook, heute Slack. Damals Word und Excel, heute Jira und Confluence. Et cetera. Und sowohl bei den vergangenen als auch bei den gegenwärtigen Neuerungen sind die irgendwann auftretenden Ermüdungserscheinungen vergleichbar. "Schon wieder ein neues Tool?" "Das alte funktioniert doch noch!" "So viel mehr kann das Neue doch auch nicht!" "Können wir uns nicht endgültig auf eine Lösung einigen und dabei bleiben?" Diese und ähnliche Äusserungen dürften sich quer durch die Arbeitswelt der letzten 25 Jahre ziehen (übrigens auch quer durch alle Altersklassen).

Was die Erzählung von der Word-, Outlook- und Excel-Ablehnung besonders macht, ist ihr im Rückblick besonders deutlich erkennbarer Anachronismus. Aus heutiger Sicht erscheint sie genauso irrational wie eine Ablehnung von Kugelschreibern, Notizblöcken und Briefmarken, so sehr sind die Office-Programme mittlerweile in den Alltagsgebrauch übergegangen. Es lohnt sich ein Gedankenexperiment: wie anachronistisch wird die heutige Ablehnung neuer digitaler Werkzeuge in 15 oder 25 Jahren wirken? Wie vorgestrig werden diejenigen erscheinen, die nicht mit Chatprogrammen arbeiten wollen, da sich doch alles mit Emails verschicken lässt? Wie aberwitzig wird die Aussage herüberkommen, kein Wiki zu brauchen, da es doch gemeinsame Laufwerke gebe?

Natürlich, für jeden der heute das Gefühl hat, sich an immer neue Tools gewöhnen zu müssen, sind solche Gedanken nur bedingt tröstlich. Und ja, nicht alles was zur Zeit neu eingeführt wird werden wir in 10 Jahren noch benutzen. Ist es demnach nicht ein vertretbarer Mittelweg sich erstmal zurückzuhalten, andere die ersten Erfahrungen machen zu lassen und erst dann mit einzusteigen, wenn sich die neue Idee durchgesetzt hat? So verlockend das auch klingen mag, eine Option ist es leider nicht. Konsequent durchgezogen würde es die eigene Firma zum Nachzügler der Modernisierung machen, bei dem neue Möglichkeiten erst als letztes genutzt werden können und um das alle mit Pioniergeist und Zukunftsoffenheit ausgestatteten Arbeitskräfte einen grossen Bogen machen werden. Ein solches Unternehmen wird kaum wirtschaftlich erfolgreich sein.

Es bleibt das finale Argument: "Aber ich kann nicht mehr!" "Die ganzen Veränderungen sind zu viel für mich!" "Nimmt den hier keiner Rücksicht auf mich?" Ein Aufschrei dem man kaum begegnen kann ohne hartherzig zu wirken, oder? Das kann man auch anders sehen. Nur weil einige nicht mehr dazulernen wollen, soll eine ganze Organisation ihre Zukunfsfähigkeit aufs Spiel setzen, und mit ihr auch die aller anderen Angestellten, die in einer veraltenden Arbeitswelt eingekapselt sein würden? Das kann nicht die Lösung sein. Ohne die Bereitschaft zur Veränderung sind die meisten Jobs heute nicht mehr ausübbar. Diese Erkenntnis ist nicht für jeden schön, an ihr vorbeikommen wird man aber genausowenig wie die zu Beginn erwähnten Damen und Herren an Word und Excel vorbeigekommen sind.

Montag, 24. Juni 2019

Wenn die richtigen Teams zur richtigen Zeit an der richtigen Sache arbeiten

Donnerstag, 20. Juni 2019

Agiles Change Management (III)

Bild: Pexels / Rawpixel - Lizenz
Es ist eine der kleineren Meldungen, die im grossen Nachrichtengeschehen kaum Aufmerksamkeit finden: zum ersten mal seit dem Krieg hat die CDU die Landratswahl in Osnabrück verloren. Gewonnen hat stattdessen eine Anna Kebschull von den Grünen. Was diese Lokalmeldung besonders macht ist eine ihrer Aussagen nach der Wahl: "Mein Stil sieht vor allem Transparenz und eine Kommunikation vor, die nicht vorgefertigte Pläne vorlegt und dann durch Sprachregelungen anderen Leuten erklärt, warum sie sie gut zu finden haben. Ich will offen Probleme ansprechen, Lösungen vorschlagen, Expertisen einholen und Akteure vor Ort einbeziehen, um gemeinsamen Pläne zu stricken." Das ist etwas Besonderes.

Klassisches Change Management funktioniert in seiner Kommunikation genau umgekehrt, nämlich so wie Kebschull es mit ihren treffenden Worten beschreibt: den Menschen wird nur noch erklärt warum sie das fertig festgelegte und geplante Vorgehen gutzufinden haben. Das gibt es in der Politik (mit der berüchtigten Formulierung alternativlos), das gibt es aber auch in der freien Wirtschaft, bei Umstrukturierungen, Strategiewechseln, Entlassungen, etc. Der Grund dafür ist, dass dieses Vorgehen wunderbar zur alten Top-Down- oder Wasserfall-Welt passt. Planung, Durchführung, Verkündung - das ist idealtypische Sequenzialität. Und idealtypisch in mehr als eines Hinsicht: für die Realität ist sie kaum geeingnet.

Selbst wenn man annimmt, dass es vielleicht wirklich alternativlose Entscheidungen gibt - die meisten sind es nicht, mit ihnen sollte man anders umgehen. Dort wo die Zukunft nocht nicht klar absehbar ist (und damit dort wo Agilität und agiles Change Management Sinn machen) kann das blosse "Durchkommunizieren" bereits beschlossener Pläne keine Option sein. Stattdessen muss die Durchführung frühzeitig und regelmässig durch Überprüfung und Feedback validiert werden, mit der begleitenden Kommunikation als zentralem Faktor. Wenn diese nämlich nicht nur von oben nach unten sondern auch von unten nach oben verläuft kann sie wertvolle Informationen zu Sinnhaftigkeit und Akzeptanz eines Vorgehens enthalten.

Oben angekommen sollten diese Rückmeldungen die Grundlage eines Inspect & Adapt-Prozesses sein, dessen Ergebnisse wieder nach unten weitergegeben werden, als Grundlage für weiteres Feedback nach oben. Etc., etc. Um im Rahmen dieser Kommunikationsschleifen nicht zu erstarren muss aber eine weitere Voraussetzung gegeben sein: Geschwindigkeit. Nur wenn die Feedbackschleifen kurz sind kann auch die Reaktion auf Veränderung rechtzeitig erfolgen, sind sie zu lang wird nur an den Problemen der Vergangenheit gearbeitet, nicht an denen der Gegenwart. Und ja, derartig schnelles Feedback ist auch in grossen Organisationen möglich, dafür gibt es Beispiele.

Für Change Management-Einheiten die bisher nur auf Verkündung ausgerichtete Einwegkommunikation gewöhnt waren bedeutet ein derartiges Vorgehen eine fundamentale Neuausrichtung, weg von gewohnten und lieb gewonnen Mustern. Das kann weh tun. Allen die davon betroffen sind kann man aber raten sich durch diese Schmerzen zu arbeiten. Die Alternative wäre noch unangenehmer: irgendwann feststellen zu müssen gar kein Change Management zu sein sondern ein Planwirtschafts- oder Stillstandsmanagement.

Montag, 17. Juni 2019

Die 10 Voraussetzungen von Scrum

Bild: pxhere - CC0 1.0
"Wir haben es mit Scrum versucht, aber es funktioniert nicht!" Diese irgendwo zwischen Stossseufzer und Resignation schwankende Aussage dürfte schon in vielen Firmen gefallen sein. "Natürlich nicht, bei Euch fehlen die Voraussetzungen!" ist die in den meisten Fällen zu hörende Antwort. Was diese Voraussetzungen sind bleibt allerdings häufig unausgesprochen. Das muss nicht so sein, in den meisten Fällen reicht ein Blick in den Scrum Guide. Aus ihm lassen sie sich ableiten. Im folgenden zehn wichtige von ihnen, samt einer kurzen Erläuterung.

1. Scrum is founded on [...] empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known

  • Was heisst das? Dass Scrum Teams alle relevanten Zahlen kennen müssen. Nicht nur Bugrate und Umsetzungszeit sondern auch Herstellungs-, bzw. Personalkosten, Kundenbewertungen, Nutzungsdaten, Marktforschungsergebnisse, etc.
  • Warum ist das wichtig? Weil ohne Datengrundlage alle Verbesserungsversuche nur auf Mutmassungen basieren könnten und nicht validierbar wären

2. Everyone focuses on the work of the Sprint and the goals of the Scrum Team

  • Was heisst das? Dass es für die Mitglieder eines Scrum Teams keine Teilzeit-Zugehörigkeit und keine Zusatzaufgaben geben darf
  • Warum ist das wichtig? Weil Kontextwechsel und Verfügbarkeitsengpässe zwangsläufig dazu führen, dass Konzentration abnimmt, Wartezeiten und Konflikte dafür zunehmen

3. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work

  • Was heisst das? Dass alle sich darauf einlassen, dass die Zukunft sich anders entwickelt als es geplant wurde, wodurch auch das Ergebnis ein anderes sein kann
  • Warum ist das wichtig? Damit nicht weiter an obsolet gewordenen Plänen festgehalten wird, die nicht mehr zu Rahmenbedingungen und Marktbedürfnissen passen

4. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team

  • Was heisst das? Dass die Selbstorganisation ernst gemeint ist. Nur das Scrum Team selber entscheidet wieviel Arbeit es in den Sprint nimmt, welche Metriken es erhebt, etc.
  • Warum ist das wichtig? Um Bürokratie und Ineffizienz zu vermeiden. Die Effekte von Top Down-Management (Stille Post-Effekte, Reporting-Overhead, Entscheidungsverzögerungen, unrealistische Planungen) sollen vermieden werden

5. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team

  • Was heisst das? Dass jede Fähigkeit die zur Herstellung eines Produkts nötig ist im Team vertreten sein muss, egal ob es um Backend, Frontend, UX, Marketing, Recht oder sonst etwas geht
  • Warum ist das wichtig? Weil externe Abhängigkeiten immer wieder dazu führen, dass benötigte Personen nicht verfügbar sind und Arbeiten deshalb nicht beendet werden können

6. Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available

  • Was heisst das? Dass nach jedem Sprint ein Produktionsrelease möglich ist. Er muss nicht stattfinden, er muss aber möglich sein
  • Warum ist das wichtig? Weil sonst die Gefahr besteht, dass sich Integrations-, Release- oder Dokumentationsaufwände zu einer Bugwelle stauen die am Ende nicht mehr bewältigbar ist

7. For the Product Owner to succeed, the entire organization must respect his or her decisions

  • Was heisst das? Dass der PO entscheiden darf ob bestimmte Funktionen ein- oder ausgebaut werden oder ob das unterbleibt
  • Warum ist das wichtig? Um zu verhindern, dass Managementrunden, Steuerungskommittees oder andere Kontrollgremien zu Verzögerungen oder politisch getriebenen Entscheidungen führen

8. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint

  • Was heisst das? Dass die Teamgrösse zwischen 3 und 9 Mitgliedern (plus PO und Scrum Master) liegen muss (diese Zahlen sind ebenfalls aus dem Scrum Guide)
  • Warum ist das wichtig? Weil zu kleine Teams hohe Ausfallrisiken haben und nicht crossfunktional sein können und grosse zu starke Effizienzverluste durch hohen Kommunikationsbedarf haben

9. Scrum Masters do this [promoting and supporting Scrum] by helping everyone understand Scrum theory, practices, rules, and values

  • Was heisst das? Dass der Scrum Master nicht nur für das Coaching des Teams zuständig ist sondern auch für das Coaching von Managern und Stakeholdern
  • Warum ist das wichtig? Weil sonst den (ggf. versehentlich) destruktiv handelnden Personen die Tragweite ihrer Handlungen nicht bewusst wird

10. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint

  • Was heisst das? Dass a) Stakeholder im Review-Meeting anwesend sein müssen und b) sie dort aktiv Feedback geben müssen statt nur zuzuhören
  • Warum ist das wichtig? Um zu vermeiden, dass das Scrum Team versehentlich am Bedarf vorbei produziert und schlimmstenfalls betriebsblind wird


Um es klar zu sagen: das sind anspruchsvolle Voraussetzungen, vor allem für grosse und hierarchische Organisationen. Im Zweifel sind sie nicht sofort erreichbar, was aber nicht schlimm ist, so lange man sie erreichen will und darauf hinarbeiten kann (jede Firma sollte sich dann aber fragen ob sie diesen Zustand bereits Scrum nennen will). Vielleicht passen sie aber auch gar nicht zur Unternehmenskultur und -struktur - dann ist Scrum vermutlich nicht der passende Ansatz.

Donnerstag, 13. Juni 2019

Design Sprints (am Beispiel von illegalem Whisky)

Es geht doch nichts über eine Erklärung komplexer Sachverhalte anhand von abseitigen Beispielen.

Montag, 10. Juni 2019

The Agile Bookshelf: Wicked Problems, Righteous Solutions


Eigentlich könnte man denken, dass über die Ursprünge von Scrum alles bekannt ist. Die Grundidee wurde in den 80er Jahren von japanischen Fabrikteams entwickelt und von Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel im Harvard Business Review The New New Product Development Game beschrieben, in dem auch erstmalig das Wort Scrum auftaucht. Ab 1993 wurden diese Erkenntnisse von Ken Schwaber und Jeff Sutherland auf die IT übertragen und 1995 wurde das so entstandene Vorgehensmodell der Öffentlichkeit vorgestellt. Zumindest ist das die weitverbreitete Annahme.

Was in diesem Zusammenhang wenig beachtet wird ist ein Buch aus dem Jahr 1990, das den Titel Wicked Problems, Righteous Solutions trägt und von zwei Amerikanern namens Peter DeGrace und Leslie Hulet Stahl verfasst wurde. DeGrace und Stahl wollten in diesem Werk die Probleme aufzeigen die durch die Anwendung eines Wasserfall-Vorgehens auf einen Softwareentwicklungsprozess enstehen und mögliche Alternativen erörtern. Neben anderen, mittlerweile vergessenen Ansätzen wie Whirlpool, Sashimi und Hollywood stellten sie auch einen namens Scrum vor, der auf autonomen, crossfunktionalen selbstorganisierten Teams beruht.


Nun könnte diese inhaltliche Ähnlichkeit, zeitliche Nähe und gleiche Benennung auch Zufall sein, sie sind es aber nicht. Schwaber und Sutherland kannten das Buch von DeGrace und Stahl und bauten darauf auf (siehe hier und hier). Der offensichtlichste Hinweis darauf ist die Benennung: sowohl das "alte" als auch das "neue Scrum" berufen sich auf den oben genannten Artikel von Takeuchi und Nonaka, The New New Product Development Game. Was dabei leicht übersehen werden kann - in ihm wird das Vorgehen als Rugby Approach beschrieben, das Wort Scrum kommt nur einmal vor, und das an einer wenig prominenten Stelle. Die Übertragung dieses Namens auf das ganze Vorgehensmodell wurde erstmals in Wicked Problems, Righteous Solutions durchgeführt und von dort weiter übernommen. Dieses Buch ist also tatsächlich die Initialzündung.


Die Pionierarbeit von DeGrace und Stahl besteht wesentlich daraus, überhaupt den Harvard Business Review-Text zu finden und zu realisieren, dass sich seine Erkenntnisse auf die Softwareentwicklung übertragen lassen (was u.a. voraussetzt dieses Magazin überhaupt gelesen zu haben). Aus heutiger Sicht erscheint das zwar naheliegend, da sich gerade diese Arbeit so stark für iteratives und incrementelles Arbeiten eignet wie keine andere. Man darf aber eines nicht vergessen: zum damaligen Zeitpunkt gab es diese Erkenntnis noch nicht. Trotzdem einen Artikel über die Fertigung von Hardware in japanischen Fabriken zu lesen und zu erkennen, dass er auch im Kontext einer völlig andere Industrie Sinn macht, ist keineswegs etwas Naheliegendes worauf man schnell kommen würde. 


Sogar einer der zentralen Slogans des heutigen Scrum findet sich bereits im Buch von DeGrace und Stahl. Es ist das kontrovers diskutierte doing twice the work in half the time. In Wicked Problems, Righteous Solution wird es noch weniger griffig formuliert, es heisst dort you further unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Das ist zwar anders, aber klar widererkennbar.


Um Schwaber und Sutherland nicht zu schlecht dastehen zu lassen muss man ergänzen, dass viele der heute zentralen Elemente von Scrum bei DeGrace und Stahl noch nicht zu finden sind. Es gibt keinen Scrum Master, keine Sprints und keine Retrospektiven. Andere, wie z.B. die incrementelle Lieferung, kommen zwar vor, werden aber separat von Scrum erläutert. Scrum im heutigen, engeren Sinn haben also tatsächlich die beiden Herren erfunden die dafür bekannt geworden sind.


Edit: 26.06.2019
Ursprünglich stand in diesem Artikel, dass Schwaber und Sutherland nicht auf die Vorarbeit von DeGrace und Stahl verwiesen hätten. Haben sie doch. Danke an Jan Fischbach für den Hinweis und Schande über den Autor. Die hier stehenden Fake News wurden entfernt.

Donnerstag, 6. Juni 2019

Start where you are (II)

Bild: Pixabay / Moniek58 - Lizenz
Das mit dem Kanban-Prinzip Start where you are ist bekanntlich so eine Sache. An vielen Stellen muss man zuerst Klarheit darüber schaffen, was der Ist-Zustand ist, häufig verbunden mit der schmerzhaften Erkenntnis, dass der offizielle Prozess nur eine Fassade (so genanntes Business Theater) ist, während das gelebte Vorgehensmodell ganz anders aussieht. Selbst das lässt sich aber nochmal ins Unschöne steigern, und zwar auf eine Art die gerade in agilen Transitionen häufig ist.

Ein immer wieder anzutreffendes Phänomen ist es, dass eine festgefahrene Transition erst dann wieder Fahrt aufnehmen kann wenn man sich in Bezug auf die bisher erzielten Ergebnisse ehrlich macht. Und dort wo man sich an diese Wahrheiten traut kann es peinlich werden: gerade die scheinbaren Vorzeige-Erfolge entpuppen sich häufig als Missverständnis, nicht zielführende Umsetzung oder im schlimmsten Fall sogar Etikettenschwindel.

Einfach ist es noch dort wo offensichtlich getrickst wurde. Wenn nur bestehende Rollen, Prozesse und Meetings ohne inhaltliche Änderung umbenannt wurden lässt sich der Finger schnell in die Wunde legen. Das kann zwar für diejenigen peinlich sein die sich mit den scheinbaren Erfolgen gebrüstet haben, im den meisten derartigen Fällen ist der Etikettenschwindel aber ohnehin ein offenes Geheimnis, dessen Aufdeckung nur mit einem "endlich sagt es mal einer" kommentiert wird.

Schwieriger ist es in Konstellationen in denen in grösserem Ausmass Cargo Cult anzutreffen ist. Wenn die Verantwortlichen und Beteiligten aufgrund von fehlendem Verständnis bisher davon überzeugt waren alles richtig gemacht zu haben, dann kann das Aufdecken dieser Illusion eine unschöne Überraschung sein, häufig verbunden mit emotionalen Abwehrreaktionen. Diese sanft aufzufangen und sachlich auf die Missverständnisse hinzuweisen kann eine herausfordernde Aufgabe sein.

Wirklich kompliziert kann es dann werden, wenn zwar das richtige Verständnis und grundlegend richtige Massnahmen anzutreffen sind, die scheinbaren Erfolge aber nur auf unerkannten Seiteneffekten beruhen. Ein Beispiel dafür könnte ein Kanban-Pilotteam sein, dass scheinbar seinen Wertstrom erfolgreich optimiert hat, bei dem in Wirklichkeit aber die Protegierung durch den Geschäftsführer zu einer Vorzugsbehandlung im Vergleich zu anderen Teams geführt hat, wodurch die unverändert im System vorhandenen Unwuchten bei Auslastung und Staffing einfach an andere Stellen verlagert werden.

In derartigen Fällen muss das Start where you are dazu führen, dass das scheinbare Erfolgsmodell als Problemfall erkannt und offensichtlich gemacht wird. Nur dann kann der kontinuierliche Verbesserungsprozess einen Ansatzpunkt finden und Wirkung entfalten. Die Reaktionen darauf können nochmal heftiger ausfallen als im Fall der Cargo Cult-Implementierung, schliesslich können die Beteiligten zu Recht darauf verweisen "alles richtig gemacht zu haben". Diesen Frust ernst zu nehmen, in konstruktive Bahnen zu lenken und zum Ausgangspunkt einer echten Transition zu machen ist dann das Meisterstück des verantwortlichen Change Managers.

Montag, 3. Juni 2019

'El Jefe', der Kunde

Bild: Wikimedia Commons / Er nun wieder - CC BY-SA 3.0
Einmal mehr ist es der Zufall durch den eine interessante Geschichte zu Stande kommt. Zu Besuch bei dem in Spanien lebenden Teil der Familie kam das Gespräch zufällig auf die Supermarktkette Mercadona, die in den letzten Jahrzehnten viele ihrer Konkurrenten verdrängt hat. Das wäre auf ein fortschrittliches Management-Konzept zurückzuführen, hiess es. Neugierig geworden nutzte ich später die Zeit am Flughafen für eine kurze Recherche, und tatsächlich - im Wall Street Journal, in El Pais und in Publikationen der Harvard Business School liess sich einiges über dieses Unternehmen finden was sich bemerkenswert anhört.

Eine der interessantesten Ideen ist die Hierarchie der verschiedenen Zielgruppen und Stakeholder die durch das Unternehmen bedient werden sollen. Der Wichtigkeit nach absteigend sind das der Kunde, die Angestellten, die Gesellschaft, die Lieferanten und die Eigentümer. Das ist bemerkenswert: nicht nur, dass der Kunde an der Spitze steht (das behaupten fast alle Firmen von sich), sondern auch das was danach kommt - Angestellte, Gesellschaft und Lieferanten nicht nur als Zielgruppe zu nennen sondern sie sogar über den Eigentümern einzuordnen ist etwas was ich noch nicht gehört habe.

Ungeachtet dessen scheint es so, dass auch versucht wird dem Anspruch der Kundenorientierung gerecht zu werden. Dazu gehört nicht nur freundliches, gut ausgebildetes Personal (kann ich aus eigener Anschauung bestätigen) sondern auch darüber hinausgehende Ansätze: das Management wird angehalten regelmässig auf der Verkaufsfläche mit Kunden zu sprechen, und nicht nur im sondern auch um die Supermärkte findet Marktforschung statt. Etwa durch Kundenmanager die in den umliegenden Cafes mit den Kunden über ihre gerade getätigten Einkäufe reden.

Apropos Personal: um die Wünsche des Kunden (intern "El Jefe" genannt) besser erkennen und umsetzen zu können sind die Teams der einzelnen Supermärkte so crossfunktional wie möglich. Das heisst nicht nur, dass sie (wie auch in Deutschland üblich) je nach Bedarf zwischen Kassieren, Reinigen und Einräumen wechseln können, sondern dass sie Fortbildungen in Warenkunde, Kundenansprache, Betriebswirtschaft und Logistik erhalten. Mit Hilfe dieses Wissens sind sie in ganz anderer Weise in der Lage Prozesse erkennen, beurteilen und optimieren zu können.

Diese Optimierungen finden schliesslich fast nie in Form von grossen Change-Programmen statt sondern durch viele, kleine, ständig durch Feedback verbesserte Schritte. Mal ist es die Einführung von Familienpackungen, mal die Reduktion von Verpackungsmüll (beides in Kooperation mit Lieferanten), an anderen Stellen werden Arbeitsschritte automatisiert (z.B. bei den Preisanzeigen), Beratungsangebote verbessert, Transportwege verkürzt oder Recyclingquoten erhöht.

Ein weiteres Beispiel dafür wo man lean und agile Praktiken finden kann. Nicht nur bei Google und Spotify sondern auch um die Ecke, im nächsten Supermarkt.