Direkt zum Hauptbereich

Messen statt Meinung - Scrum und Lean Startup bevorzugen ein empirisches Vorgehen

Darüber wie man ein Unternehmen, Team oder Projekt führt, gibt es bekanntlich viele Meinungen. Es gibt Methoden und praktische Erfahrungen, über die sich vortrefflich debattieren lässt. Selbst wenn sich ein Team auf ein Vorgehen geeinigt hat, können uns der Kontext und kognitive Verzerrungen (/1/) einen Strich durch die Erfolgsrechnung machen. Wie kommen wir aus diesem Dilemma heraus? 

Aus meiner Sicht ist ein Erfolgsfaktor von Scrum, dass dort Wert auf ein empirisches Vorgehen gelegt wird. Das bedeutet, dass man arbeitet, sich verbessert und dann misst. Ändert sich die Produktivität oder nicht? Wenn ja, geänderte Arbeitsweise beibehalten; wenn nein, weiter anpassen (inspect and adapt). Zu solch einem Vorgehen gibt es gute Anregungen in Buchform.

Sie kennen sicherlich die Situation: Ein Teammitglied bringt eine neue Idee mit, die es gern umsetzen möchte. Nun beginnt die große Diskussion, ob die Idee wirklich so toll sei. Sicherlich funktioniere sie woanders gut, aber in diesem Unternehmen gehe das gar nicht.

Phil Crosby hat die Situation so zusammengefasst /2, S. 50/:

I have had discussion with executives in hundreds of different businesses and industries. Regardless of the nation, product, service, or group I am never disappointed. Someone always says: 'You have to recognize that our business is different.'

Aus der Diskussion kommen wir ohne Messdaten nicht raus (/3/). Beispielsweise hat Edward Deming, wie Crosby ein Guru im Qualitätsmanagement, seine Kunden immer wieder aufgefordert, Daten über einen Prozess zu sammeln. Er hat damit erstaunliche Ergebnisse produziert. Deming ist der Erfinder des Deming-Zyklus, der aus meiner Sicht fälschlicherweise mit "PDCA - Plan - Do - Check - Act" wiedergegeben wird. Wenn man in Demings Bücher schaut, liest man dort "Plan - Do - STUDY - Act" (/5/). Es geht nicht um das Überprüfen eines Ablaufs, sondern um das Lernen aus den statistischen Daten des Prozesses. Wenn wir etwas verbessern wollen, brauchen wir eine Vorstellung über die Zusammenhänge. Dann überlegen wir, woran wir diese erkennen und wie wir sie messen können. Dazu brauchen wir die Daten.

Bei Scrum messen wir zum Beispiel die sog. Abarbeitungsgeschwindigkeit (engl. velocity). Jeder Anforderung wird ein relativer Wert für den Aufwand gegeben, die sog. Story Points. Am Ende eines Zyklus (ein Sprint in Scrum) zählt das Team, wie viele Story Points es bearbeiten konnte. Ebenfalls am Ende des Zyklus gibt es auch eine Feedback-Runde (die sog. Retrospektive), in der sich das Team auf ein bis zwei Verbesserungsmaßnahmen einigt. Wenn die Maßnahmen wirken, ist das an einer höheren Punktzahl im nächsten Durchlauf zu erkennen.

Eric Ries hat eine Arbeitsweise zur kontinuierlichen Anpassung an den Markt unter dem Titel "Lean Startup" veröffentlicht (/6/). Er nennt den Zyklus "Build - Measure - Learn". Er schlägt zum Beispiel vor, für ein Produkt 2 Webseiten zu erstellen. Auf einer Webseite spricht man vielleicht eher Privatpersonen an, auf der anderen eher Geschäftskunden. Beide Seiten werden abwechselnd den Kunden gezeigt (sog. A/B-Tests). Wenn sich mehr Privatkunden registrieren, scheint das Produkt für diese Gruppe interessanter zu sein. Die Idee ist die gleiche wie bei Deming.

Wenn Sie vor einer wichtigen Entscheidung im Unternehmen stehen, lohnt es sich vielleicht, ein kleines Experiment zu machen. Was wären beobachtbare Konsequenzen für die einzelnen Optionen?

Man könnte meinen, dass es doch sehr aufwändig sei, Experimente zu machen und Daten zu sammeln. Doch zum Glück belehrt uns Douglas Hubbard eines besseren. Seiner Meinung nach ist es ein großer Unterschied, ob wir Unsicherheit in unserer Entscheidungsfindung etwas reduzieren wollen oder ob wir eine klinische Studie in einem renommierten medizinischen Fachblatt veröffentlichen (/7/). Wenn man genau hinschaut, brauchen wir oft weniger Daten, als wir glauben und haben oft mehr Daten zur Verfügung als wir denken.

Messen statt Meinung - die Idee finde ich gut.

Anmerkungen

      Kommentare

      1. "Messen statt Meinung..."

        ist mir plakativ zu nah an "management by numbers" (/1/) und liefert mir die falschen Signale.

        In PDSA, also Plan - Do - STUDY - Act, sehe und erlebe ich mit dem aktiv geforderten Lern-Ansatz und den sich daraus ergebenden Chancen deutlich nachhaltigere Hebel-Wirkungen.

        Just my 2 Cents.

        CU
        Boeffi

        /1/ http://www.betacodex.org

        AntwortenLöschen
        Antworten
        1. Ja, Du hast recht. Management by numbers ist nicht anstrebenswert. Ich meine eher "Daten sammeln, um zu lernen".

          Löschen
      2. Ich finde den Ansatz inkrementeller Verbesserungen, gekoppelt mit der "Erlaubnis zum Experiment", sehr gut. Das hat nichts mit "management by numbers" zu tun, denn "Management" setzt eine übergeordnete Instanz voraus, die die Strippen zieht.
        Das gibt es hier nicht. Es ist ein evolutives Vorgehen. So wie die Evolution Mutationen zulässt und mal schaut was rauskommt, so werden hier auch Ideen als testenswert akzeptiert und auf Sinnhaftigkeit getestet.
        Wir sind ja auch gerade dabei, zu viert ein neues Unternehmen zu gründen, und machen die Erfahrung: Pläne und Konzepte bringen viel weniger als das praktische Ausprobieren, gekoppelt mit Kritikschleifen. Wenn Pläne das praktische Ausprobieren verzögern, weil der Plan noch nicht ganz rund ist, sind sie sogar schädlich.

        AntwortenLöschen
      3. > Ansatz inkrementeller Verbesserungen [..] So wie die Evolution Mutationen zulässt und mal schaut was rauskommt, so werden hier auch Ideen als testenswert akzeptiert und auf Sinnhaftigkeit getestet

        Genau damit lassen sich in der Praxis große Erfolge erzielen. Erfolge, die bei den immer komplexer werdenden Systemen über ein jahrzehnte "bewährtes" BDUF (Big Design Up Front) immer seltener werden.

        > "Erlaubnis zum Experiment"

        Damit fühlt sich nur die Manager-Generation der "alten Schule" nicht sehr wohl (un-wohl!), da gerade dort "management by numbers" als Lösung(?) für Ungewissheiten gelehrt wurde.

        "...lieber noch detaillierter planen, ein oder zwei Nachkomma-Stellen hinzufügen, und man kann alles noch präziser kontrollieren... höre ich aus diesem Lager immer wieder.

        Und genau deshalb habe ich meinen o.g. Kommentar

        > "Messen statt Meinung..." [..] plakativ zu nah an "management by numbers" [..] und liefert mir die falschen Signale

        so formuliert. Ich weiss, dass Jan mit "Messen statt Meinung" genau nicht "management by numbers" meinte. Nur "verstehen" Manager es leider genau so.

        CU
        Boeffi

        AntwortenLöschen

      Kommentar veröffentlichen

      Beliebte Posts aus diesem Blog

      Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

        Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

      Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

      Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

      Den passenden Job finden

      Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

      Die Microsoft Teams-Not-To-Do-Liste

      Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

      Agilität ist tot. Ausgerechnet jetzt?

      Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

      Wie beschreibt man einen Workshop für eine Konferenz?

      Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

      Gemeinsam eine Anwenderdokumentation erstellen

      Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

      Scrum und Hardware: Es kommt auf die Basics an

      Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.