Schlagwort-Archive: agiles Arbeiten

Selbstorganisation ist einer der Grundpfeiler für agiles Arbeiten. Das agile Manifest beschreibt weitere Prinzipien für agiles Arbeiten. Agiles Arbeiten ist aber immer auch das, was man daraus macht. Hier sollen entsprechende Denkanstöße zum agilen Arbeiten diskutiert werden.

Kanban Board – todo doing done

Kanban BoardEin Kanban Board soll den Fluss der Arbeit abbilden und dadurch die nötige Transparenz schaffen, auf deren Basis die Prozesse optimiert und übergreifend aufeinander abgestimmt werden können. Diese Boards können beliebig komplex aufgebaut werden. Die einfachste Form folgt dem Schema todo – doing – done. Was so trivial aussieht, deckt aber eine ganze Reihe von zentralen Fragestellungen ab.

Todo

In der Todo Spalte sind die Tasks aufgeführt, die erledigt werden sollen. Um diese Spalte zu befüllen, bedarf es also schon einer intensiven Auseinandersetzung mit der Aufgabe. Es geht um die Fragestellung, was man wirklich machen will bzw. was das wichtigste nächste Thema ist. Noch klarer wird es in der Negation: was will ich (aktuell) alles nicht machen? Eine Todo Spalte impliziert, ein klares Bekenntnis zu den darin befindlichen Aufgaben.

Damit ist die Todo Spalte auch nicht gleichzusetzen mit einem Backlog, d.h. einer nach Wert geordneten Liste aller anstehenden Arbeiten. Innerhalb eines Kanban Systems ist der Fluss der Aufgaben zentral, der über Durchlaufzeiten erfassbar gemacht werden kann. Dafür sollte die ToDo Spalte möglichst klein gehalten werden. Die zentrale Frage für die Befüllung dieser Spalte lautet: was soll als nächstes live gestellt werden? Der Backlog muss dann an anderer Stelle verwaltet werden. Nur so kann auch ein sinnvolles WIP Limit für die ToDos gesetzt werden. Den Backlog durch ein WIP Limit zu begrenzen erscheint wenig sinnvoll.

Doing

In der Doing Spalte wird das verwaltet, was gerade aktiv in Bearbeitung ist. Die Abgrenzung zu der Todo Spalte ist hier besonders wichtig. Nur weil man sich für ein Task entscheidet, hat man lange noch nicht begonnen daran zu arbeiten. Einzelne Tasks sollen schnell und berechenbar durch das Board fließen. Ein Task in der Doing Spalte bedeutet maximale Fokussierung auf die Umsetzung. Losgelöst von Service-Leveln o.ä. muss die Doing Spalte schon an sich ein treibendes Element für das Team darstellen. Entsprechend sollte insbesondere für die Doing Spalte eines Kanban Boards der work-in-progress limitiert werden.

Done

Wenn ein Task fertig gestellt, wird er in die Done Spalte verschoben. Dies setzt natürlich voraus, dass man weiß, wann ein Task fertig ist. Je konkreter die ToDos erfasst sind, desto besser kann deren Reifegrad beurteilt werden. Dabei geht es nicht nur um Akzeptanzkriterien. Es geht vor allem darum, die Arbeit in für das Produkt sinnvolle Teile zu schneiden. Ein Kanban Board zwingt insofern zu agilem Denken, als dass auf die häufige Auslieferung von Wert fokussiert wird. Enthält ein Kanban Board nur große Projekte und bleibt damit auf der Metaebene, gibt es nicht nur wenig Bewegung auf dem Board. Es gibt entsprechend auch keinen am Markt wirksamen Wert. Genau das soll agiles Arbeiten erreichen, die häufige Produktion von Wert, der schnell am Markt wirken kann.

Die Frage, wann ein Task done ist, muss schon gestellt werden, wenn der Task auf todo gesetzt wird. Die Sequenz todo – doing – done muss also als Ganzes verstanden und gelebt werden. Wenn ein Thema noch nicht ausreichend konkret für eine direkte Umsetzung beschrieben werden kann, so kann dies zunächst als Discovery über das Board wandern. Die Ergebnisse einer solchen Discovery können dann in neue, konkrete ToDos überführt werden. Auf diese Weise kann ein simples Kanban Board auch einen Kreislauf darstellen, wie man ihn mit build – measure – learn von Lean Startup kennt.

In den Prinzipien des agilen Manifest steht: „Einfachheit — die Kunst die Menge nicht getaner Arbeit zu maximieren — ist essentiell“. Ein ganz simples Kanban Board mit den Spalten todo, doing und done trägt bereits wesentlich zur Fokussierung auf sinnvolle Arbeitspakete und häufig ausgelieferten Wert bei. Vorausgesetzt natürlich, man ist sich bei jedem einzelnen Task klar darüber, warum und wie er durch die Spalten wandert. Ein Board alleine macht noch lange kein Kanban System aus. Aber agile Boards müssen auch nicht unbedingt komplex aussehen, um die zentralen agilen Werte zu unterstützen. Vielmehr sollte man gerade bei sehr komplexen Boards hinterfragen, welche der Spalten den Status von todo, doing und done repräsentieren und ob nicht eine Vereinfachung sinnvoll ist. Schließlich sollen die Boards nicht zeigen wie komplex die eigenen Prozesse sind, sondern dabei helfen die Prozesse zu verstehen und zu optimieren.

Bild: Simple personal Kanban Board von Kanban Tool auf flickr, Verwendung unter cc Lizenz

Von der Timebox zur Valuebox

TimeboxEine der Kernideen von Scrum ist das Arbeiten in Timeboxes. In einer Timebox gibt es einen klar definierten Start- und Endzeitpunkt. Es geht also um Arbeiten nach der Stoppuhr? Das Bild der Stopp- oder Sanduhr trifft nicht wirklich den Kern von Timeboxing im agilen Kontext. Denn über der Timebox steht nach wie vor der Hauptauftrag der Werterzeugung. Eigentlich sollte man die Timebox also besser als Valuebox bezeichnen.

Das Verständnis der Timebox als Valuebox rückt das eigentliche Ziel in den Vordergrund und stellt auch klar, wieviel Organisation in agilen Methoden notwendig ist. Seine Zeit so zu planen, dass am Ende ein vorzeigbares Ergebnis entsteht, ist nicht einfach. Dabei hilft das hohe Engagement und das Commitment des Einzelnen. Wer will schon am Ende eines Sprints nichts zu präsentieren haben! Agile Arbeiter wollen wollen etwas bewegen, sie wollen Wert erzeugen und zwar in sinnvollen Zeiteinheiten.

Wenn die Zeit, die zur Verfügung steht, durch eine Timebox ein klar definiertes Ende hat und am Ende gleichzeitig einen sinnvollen Wert vorzeigbar sein soll, dann muss innerhalb der Timebox ggf. der Wert selber angepasst werden. Aus dem Projektmanagement kennen wir das Dreieck aus Time, Budget und Scope:

  • Die Dimension Zeit ist beim Timeboxing wie schon beschrieben fest. Der einzelne Sprint hat eine klar definierte Länge. Zeit wird damit nur verhandelbar, wenn zusätzliche Sprints geplant werden.
  • Das Budget ist normaler Weise auch klar begrenzt, wenn unter Budget vor allem Manpower gemeint ist. Natürlich kann man das Team kurzfristig erweitern, häufig jedoch ist dies aufgrund der hohen Initialkosten im Sinne der Anlernphase nicht sinnvoll.
  • Damit bleibt nur der Scope, also der geplante Umfang bzw. der abzuliefernde Wert, der innerhalb der Timebox angepasst werden kann. Wenn Komplikationen oder Aufwände sichtbar werden, die in der ersten Schätzung nicht erkennbar waren, dann muss darauf mit Anpassung des Scopes reagiert werden.

Product Owner und Stakeholder müssen dies akzeptieren bzw. fördern. Am Ende ist es für das Produkt und das Unternehmen wichtig, dass möglichst früh ein nutzbarer Wert entsteht, auch wenn dieser zunächst unter den ersten Erwartungen bleibt. Durch agile Methoden wollen wir verhindern, dass einzelne Arbeitspakete über Monate verzögert werden und somit auch über Monate kein Wert am Markt geschaffen wird. Wer schnell Wert produzieren will, der muss akzeptieren, dass dieser Wert in kleinen Einheiten erbracht wird. Ohne dieses Verständnis bleibt die Timebox als leere Methodik zurück. Erst durch das Verständnis der Timebox als Valuebox lassen sich agile Methoden mit Mehrwert praktizieren.

Bild: In Search Of Lost Time von Alexander Boden auf flickr, Verwendung unter cc Lizenz

Simply the Best? Agiles Management und Personalauswahl

„If you can only have 10 on the team, they’d better be the very best that you can find.“ Dies ist eine von 14 zenralen Aspekte für agiles Arbeiten, die Bob Warfield in seinem SmoothSpan Blog aufführt. Als ich mein erstes agiles Projekt erfolgreiche beendete, fragten mich viele Kollegen nach dem Erfolgsrezept bzw. den Erfolgskriterien, denn es war auch das erste agile Projekt für unseren Bereich. Scrum, damals die Basis für unser Projektvorgehen, war recht leicht zu erklären. Aber was braucht es, um dieses Vorgehen auch zum Erfolg werden zu lassen? Ich fragte mich das natürlich auch, denn es sollte nicht nur bei einem erfolgreichen agilen Projekt bleiben. Als das wesentlichste Erfolgskriterium kristallisierte sich für mich folgendes heraus: Arbeite mit Profis zusammen! Dies ist eine vielleicht abgeschwächte Form des oben genannten Zitats, meint im Kern aber etwas ähnliches.

Nun könnte man sagen: tolle Erkenntnisse, dass man mit guten Leute gute Ergebnisse erzielen kann! Aber so einfach ist das nicht. Agile Methoden bilden einen Rahmen, in dem Arbeit selbstorganisiert ablaufen soll. Das agile Manifest sagt, dass die Konzentration auf Individuen und Interaktion wichtiger sind als Werkzeuge und Methoden. Dies unterstreicht die Bedeutung der zusammenarbeitenden Menschen. Sich selbst organisieren zu können heißt aber auch, dass man sein Handwerk schon verstehen muss. Zudem arbeiten agile Teams in kleinen Gruppen, so dass kein Raum zum verstecken bleibt. All dies passt also zu der Bedeutung der Qualität agiler Arbeiter und zeigt, warum diese Qualität im agilen Kontext besonders wichtig ist.

Trotzdem würde ich heute das Erfolgskriterium anders formulieren: Bring den best möglichen Mix aus Menschen als ein Team zusammen. Ich will damit verdeutlichen, dass es nicht reicht, die zehn besten Individuen auszuwählen, für die dann, wie Bob Warfield schreibt, „pay what it takes“ gilt. Keine Frage, Qualität hat ihren Preis. Entscheidend ist aber das entstehende Team, das Gesamtgefüge. Neben der beruflichen Qualifikation muss dabei auch die Persönlichkeit betrachtet werden. Ein Team funktioniert dann, wenn sich sowohl die fachlichen als auch die persönlichen Merkmale der Teilnehmer gegenseitig so unterstützen, dass das Team mehr wird als die Summe seiner Einzelteile.

Bob Garfield gibt zusätzlich noch folgende Tipps, um das Team best möglich zu unterstützen, bzw. die besten Leute optimal ans Teams / Unternehmen zu binden:

  • Make engineering a first class part of the company.
  • Give them a high performance environment to work in.
  • Parallel Career Tracks for Pure Techies and Management.

All dies kann ich unterschreiben, wobei man den ersten und dritten Punkt verallgemeinern muss, denn man kann und sollte auch außerhalb des IT-Bereichs agil arbeiten. Eine der wichtigsten Aufgaben für agiles Management im Bereich Personalauswahl ist aus meiner Sicht aber die Zusammensetzung des Teams optimal zu unterstützen. Die Personalauswahl muss auf das entstehende Team abgestimmt werden und darf nicht nur isoliert betrachtete Superstars auswählen. Hilfreich ist es z.B. potenzielle Kandidaten auch mit dem Team reden zu lassen. Ich verlasse dafür mit dem HR-Manager den Raum und lasse den potenziellen Kollegen und Teile des Teams sich einfach mal beschnuppern. Dabei soll kein Team entstehen, wo sich alle auf anhieb perfekt verstehen. Ein gutes Team braucht auch Spannungspunkte. Diese zu erahnen ist Aufgabe von HR und Manager. Aber ein unverfängliches Kennenlernen gibt beiden Seite eine gute Chance, in die neue neue Konstellation hineinzufühlen.

Die zweite zentrale Aufgabe für agiles Management ist es dann, für dieses Team passende und gleichzeitig den Wert des Unternehmens steigernde Aufgaben auszuwählen. Das Team so gut verstehen lernen, dass man zu der Teamkompetenz passende Aufgaben auswählen kann, ist dafür die Voraussetzung. Natürlich muss dabei immer auch der Mehrwert für das Unternehmen betrachtet werden. Im Zweifel würde ich aber eine bestimmte Aufgabe runter priorisieren, wenn ich dadurch den Output des jeweils aktiven Teams optimieren kann. Dann können auch Personalwechsel nicht mehr nur als Gefahr gesehen werden, sondern auch als Chance mit einer neuen Teamkonstellation ganz neue Teamkompetenzen zu erreichen und andere Themenschwerpunkte setzen zu können, ohne dabei an Fahrt zu verlieren. Hat man mehrere Teams zur Verfügung, lohnt sich je nach aktuellen Themen also auch die Frage, ob die bestehenden Teams verändert bzw. durchmischt werden sollten. Starre Abteilungsgrenzen sind dabei wenig hilfreich. Agilität muss somit auch in der Organisation der Organisation ankommen.

agiler Statusreport

Auf Paul Klee geht das Zitat zurück: „Kunst gibt nicht das Sichtbare wieder, sondern Kunst macht sichtbar.“ Ich muss gestehen, dass ich diese Zeile nicht kannte, als ich vor einiger Zeit – mal wieder – auf der Suche nach einer Möglichkeit war, den aktuellen Status des Produkts, das ich betreue, auf einen Blick sichtbar zu machen. Mir wurde – mal wieder – recht schnell klar, dass klassische Berater-Logik nicht funktioniert. Ein komplexes Produkt lässt sich nicht MECE (mutuale exclusive and collectively exhaustive) zerlegen; zumindest dann nicht, wenn man schnelle, operativ benutzbare Ergebnisse haben will. Es gibt auch nicht das eine Template, dass für jede Situation passt. Die Realität passt eben nicht auf einen standardisierten, vorstandstauglichen Einseiter.

Auf der Suche nach einem alternativen Ansatz bin ich auf die Idee gekommen, ein Bild zu malen. Wenn ich die Komplexität nicht in logische Strukturen gegossen bekommen (es wäre dann wohl auch keine Komplexität mehr!?), dann verzichte ich doch einfach auf diese Strukturen. Und wenn ich die Zusammenhänge ohnehin nicht übersichtlich und umfassend abbilden kann, dann kann ich auch gleich ganz darauf verzichten. Das Bild das ich gemalt habe war am Ende eine Landkarte des Produktes.

Projektreport_Karte

Eine solche Landkarte, unterliegt nicht der Notwendigkeit Themen nach Logik zu trennen. Einzelne Aspekte können mehrfach unter verschiedenen Namen auftauchen, die Namen und Bezeichnungen können doppeldeutig sein.  Auch ist es irrelevant, die Zusammenhänge abzubilden. Man kann bei Bedarf Themen durch geografische Nähe bewusst zusammenführen oder durch natürliche Grenzen Themenfelder trennen. Aber dies muss nicht sein. Diese künstlerische Freiheit ermöglicht es, einen wirklichen Überblick zu erarbeiten. Zudem kann man bei der Gestaltung nach Belieben (schwarzen) Humor walten zu lassen, was insbesondere dann hilft, wenn es dem Land mal gerade nicht so rosig geht. Und wie bei echten Karten ändert sich auch diese Produkt-Landkarte im Laufe der Zeit, was dann im Zeitraffer betrachtet schon viel über die Entwicklung des Produkts verrät.

Eine solche Karte kann als Grundlage für eine Wetterkarte dienen, die für den betrachteten Zeitraum aufzeigt, wie es um das Land / Produkt steht. Ein Statusreport besteht dann z.B. aus Sonne, Regen, Blitzen etc., die über die Karte verteilt werden. Ebenso lässt sich über eine farbige Legende der Status in die Karte einzeichnen. Die Aussage einer solchen Momentaufnahme ist nicht schlechter als ein „ordentlicher“ Statusreport im Berater konformen Template. Allerdings erfordert ein solche Darstellung eine gemeinsame Diskussion bzw. Interpretation und fördert damit die Kommunikation und Interaktion.

Auf den ersten Blick mag die Idee ein Geschäft durch ein Bild zu steuern befremdlich erscheinen, doch damit kann genau das erreicht werden, was Paul Klee über Kunst sagt. Nicht das Sichtbare über Temples und Reports wieder zu geben, sondern Dinge durch gemeinsame Interpretation und Kommunikation sichtbar machen. Gerade im agilen Kontext ist dieses sichtbar machen zwingend, damit selbstorganisierte, interdisziplinäre Teams den notwendigen Gesamtblick auf das Produkt erhalten. Außerdem ist Interaktion ja bekanntlich einer der wesentlichen agilen Werte. Und die hier vorgestellte Form des agilen Statusreport fördert ebene diese Interaktion in besonderem Maße.

Wir nutzen diese Form des agiles Statusreports wöchentlich im Team, um gemeinsam die vergangene Arbeitswoche Revue passieren zu lassen. Anders als in aufpolierten Statusberichten, in denen nur die Top-Prio-Themen auftauchen, verschwinden auf einer Produktkarte keine Themen. Man kann dadurch z.B. erkennen, worum man sich, vielleicht schon viel zu lange, nicht gekümmert hat. Die Diskussion macht aber z.B. auch in anstrengenderen Phase die Sachen sichtbar, die richtig gelaufen sind.

Darüber hinaus nutzen wir die Wetterkarte als Einstieg in unser Sprint Review Meeting. Hier kann mit dem und für das gesamten Team den Status des Produkts diskutieren. Dadurch können die unterschiedlichen Perspektiven, die ein interdisziplinäre Team auf sein Produkt hat, beleuchtet werden, so dass eine Art 360° Blick entsteht.

Kriterien für agile Arbeiter: Sartre statt Zertifikate

Woran können wir erkennen, ob jemand in ein agiles Umfeld passt? Gerade dann, wenn wir auch außerhalb der IT-Abteilung agil arbeiten wollen, treffen wir sehr schnell auf einen Personenkreis, für den Scrum noch immer ein Fremdwort ist. Müssen wir uns bei der Personalauswahl also auf die wenigen beschränken, die agile Erfahrung haben oder zumindest wissen, was agil bedeutet? Und bedeutet ein Scrum-Zertifikat wirklich auch, dass jemand ein guter agiler Arbeiter ist? Meine These dazu lautet: Sartre statt Zertifikate.

Sartre ist einer der bekanntesten Vertreter des Existentialismus dessen Kernaspekte sich gut auf eine agile Kultur anwenden lassen. Der Existentialismus geht davon aus, dass der Mensch „sich sein Wesen selbst schafft“. „Der Existentialismus (…) hält daran fest, dass beim Menschen (…) die Existenz dem Wesen vorausgeht.“ Der Mensch ist also zunächst da, d.h. hat eine “effektive Anwesenheit in der Welt“ und schafft dann sein Wesen, d.h. „die Gesamtheit von Eigenschaften“ selbst. Der Mensch hat immer eine Wahl sich zu entscheiden. Am deutlichsten wird dies, wenn Sartre von der Hoffnungslosigkeit spricht. Hoffnungslosigkeit ist hier in dem Sinne zu verstehen, dass man nicht auf eine Änderung von außen, oben oder sonst wem zu hoffen braucht. „Es ist wahr, dass der Mensch unrecht hätte zu hoffen. Aber was heißt das anderes, als dass die Hoffnung das Schlimmste Hemmnis für das Handeln ist?“ Die einzige Hoffnung liegt im eigenen Handeln.

Aus dieser Freiheit ergibt sich aber gleichzeitig auch Verantwortung. Es gibt keine Ausreden, es gibt nur die eigenen Entscheidungen. „Wählen, dies oder das zu sein, heißt gleichzeitig, den Wert dessen, was wir wählen, zu bejahen (…).“ Diese Verantwortung gilt dabei nicht nur für einen selbst, sondern für alle: „.. selbst wenn wir es nicht wollen, schaffen wir durch jede unsere Taten eine allgemeine Werteskala.“ Und damit tragen wir eben auch mit jeder unserer Taten die Verantwortung für die gesamte Menschheit.

Diese Grundzüge des Existentialismus sind sehr passfähig zu den Anforderungen an agile Arbeiter. Agile Arbeiter müssen der Überzeugung sein, dass sie selbst aktiv einen Beitrag leisten können. Wir brauchen nicht die, die einfach nur Tickets abarbeiten wollen. Wir brauchen die  Hoffnungslosen, die den Anspruch haben, die Tickets aktiv mit zu gestalten. Wir brauchen die, die verstehen, dass sie einen Teil der Gesamtverantwortung für den Projekterfolg und das Team tragen. Gerade auch bei Scrum wird dies deutlich, denn die Erreichung des Sprint-Ziels hängt zwar auch vom Leistungsbeitrag jedes Einzelnen ab, ist aber gleichzeitig eine Teamleistung. Ebenso muss sich jedes Team-Mitglied bewusst sein, dass z.B. die rein körperliche Anwesenheit beim Daily Standup (‚meine Themen sind ja komplett isoliert‘) nicht nur inhaltlich fahrlässig ist, sondern diese Einstellung auch Auswirkung auf die Zusammenarbeit des Team an sich hat. Ein Scrum Team ist im Optimalfall wie das Team Justice League aufgestellt, eine Sammlung von Superhelden, die ihre Spezialkräfte im Sinne des Team einzusetzen wissen.

justice league

Aber wie finden jetzt heraus, ob wir einen solchen agilen Superhelden vor uns haben? Die Wahrscheinlichkeit, dass jemand eine dezidierte Meinung zum Existentialismus vorweisen und artikulieren kann, ist sicher eher noch geringer als die Wahrscheinlichkeit, dass jemand ein Scrum Zertifikat mitbringt. Aber zum Glück müssen wir auch nicht über Sartre diskutieren. Wir müssen über Verantwortungsbereitschaft reden. Wir müssen herausfinden, ob unser Gegenüber im positiven Sinne hoffnungslos ist. Die reine Methodik von Scrum lässt sich vergleichsweise leicht erlernen bzw. vermitteln, was ja gerade auch einer der Vorteile von Scrum ist. Die notwendige Einstellung zur Arbeit im Team, zur Verantwortung und dem eigenen Gestaltungswillen hingegen lässt sich nur äußerst schwer beeinflussen. Sollte ich jemals vor der Entscheidung stehen, bei sonst gleicher Datenlage, mich entweder für einen Existentialisten oder für einen Scrum-zertifizierten Kandidaten entscheiden zu müssen, würde ich mich für den Existentialisten entscheiden.

Bild von CarolMedina auf flickr, Verwendung unter cc Lizenz

Zitate aus „Der Existentialismus ist ein Humanismus“ von Jean-Paul Sartre

 

Der Product Owner als Prediger

Manchmal gibt es diese Momente, in denen man die Welt nicht mehr versteht. Die Fakten liegen auf dem Tisch, die Vor- und Nachteile auf der Hand und trotzdem wird eine Entscheidung getroffen, die all dies scheinbar unberücksichtigt lässt. Gerade für agile Teams, die ein hohes Maß an Gestaltungswillen und Eigeninitiative aufweisen sollten, sind solche Momente kritisch. All zu schnell kann hier eine Situation entstehen, bei der sich das Team vom Unternehmen bzw. den Entscheidungsträgern entfernt. Die eigentliche Kraft des Teams geht verloren. Was können wir dagegen tun? Meine These dazu: Das P in PO steht für Prediger.

Ein mögliche Erklärung für scheinbar nicht nachvollziehbare Entscheidungen gegen alle Fakten liefert die klassische Analyse des Wissens. Sie besagt, dass drei Bedingungen erfüllt sein müssen, damit ein Individuum (I) Wissen über P erlangen kann:

  1. P muss wahr sein
  2. I muss an P glauben
  3. I muss Gründe haben an P zu glauben

Stellen wir uns vor, wir sitzen bei „Wer wird Millionär“ und haben es mit der 500.000-€-Frage zu tun. Wenn wir die Antwort wissen, dann können wir sie beruhigt einchecken lassen. Aber wann können wir sicher sein, die Antwort zu wissen? Gemäß der oben aufgeführten Bedingungen, sollten wir an unsere Antwort glauben (2). Wir müssen also von unserer Antwort überzeugt sein, plattes raten wäre dafür also keine Option. Zusätzlich sollten wir noch unterstützende Gründe (3) haben, an unsere Antwort zu glauben. Gründe, die wir nach außen erklären können, z.B. also, dass wir etwas über das abgefragte Thema gelesen haben. Damit hätten wir die Bedingungen (2)+(3) erfüllt, fehlt also nur noch die erste Bedingung (1). Und diese zeigt an dem Beispiel auch gleich das ganze Dilemma vor dem wir stehen. Denn ob unsere Antwort wirklich stimmt bzw. wahr ist, dass weiß am Ende nur Günther Jauch. Vielleicht haben wir ja leider den Artikel, den wir gelesen haben, falsch verstanden. Wir glauben dann an unsere Antwort, haben auch Gründe daran zu glauben, nur bleibt unsere Antwort dabei leider falsch.

In der Realität sind wir ständig mit tlw. sehr komplexen Fragen konfrontiert. Leider gibt es dabei keinen Günther Jauch, der die richtigen Antworten kennt. Es gibt keinen Spielführer, der uns heimlich Tipps gibt, und keine eindeutige Definition für die richtige Antwort. Deshalb versuchen wir Data Driven zu arbeiten, um die Wahrheit quasi zu messen. Aber ab einem bestimmten Grad an Komplexität helfen uns allein Daten nicht weiter. Wir müssen diese analysieren und Ableitungen treffen und haben auch dann keine Gewissheit über die Richtigkeit der gewonnenen Erkenntnisse. Und dann kommt der Glauben (2) ins Spiel, weil er die Bedingung ist, die wohl fast immer erfüllt werden kann. Die Gründe für den eigenen Glauben (3) sind schnell gefunden, im Zweifel im reichen Erfahrungsschatz, den jeder mit sich rum schleppt. Und wenn hart gemessene Daten, z.B. die Ergebnisse eines A/B-Tests, mal nicht so recht zum eigenen Glauben passen, dann sind diese eben falsch. Wer kann schon garantieren, dass es keinen Fehler in der Testanlage gab? Deshalb gewinnen in der Realität häufig die persönlichen „Glaubenssätze“ über die vermeintlich objektiven Daten.

Dieser Blick auf Wissen und damit auch auf die persönliche Wahrheit und die Grundlage für Entscheidungen zeigt, wie subjektiv wir alle agieren (müssen). Die klassische Analyse des Wissens weckt Verständnis dafür, wie Entscheidungen zustande kommen. Vor allem auch deshalb, weil es hier nicht um ein isoliertes Problem von Entscheidungsträgern geht, sondern weil wir alle vor der gleichen Herausforderung stehen. Darüber hinaus bekommen wir mit der klassischen Analyse des Wissens aber auch ein Mittel an die Hand, Wahrheit und Entscheidungen im Unternehmen zu beeinflussen. Nicht die reine Weitergabe von Fakten und Daten sind relevant, sondern den Entscheidungsträger an etwas glauben zu lassen. Ein Product Owner hat somit auch die Rolle eines Predigers, wenn er das Team und Produkt gut im Unternehmen platzieren will.

Es kann nur Einen geben!?

Im (Geschäfts-)Leben hört man nur allzu häufig Berichte über die Unzulänglichkeiten und Unfähigkeit der Anderen. Da sind die Agenturen, die jeden Trend verkaufen und nur Kosten ohne Nutzen bringen. Da sind die Kunden, die einfach nicht verstehen wollen, was sie eigentlich bräuchten. Da ist der Vorstand, der nur fragwürdige Entscheidungen trifft. Da sind die Mitarbeiter, die immer nur den eigenen Nutzen im Visier haben. Schuld haben also immer die Anderen, man selber aber natürlich nicht. Wenn alle damit Recht haben, dann hat am Ende irgendwie keiner Recht bzw. alle hätten sich gegenseitig bewiesen, dass sie keine Ahnung, davon aber reichlich haben. Nun lassen sich sicherlich viele Beweise dafür finden, dass dies in Summe auf die Menschheit zutreffen könnte. Aber es bleibt ein logisches Problem bestehen, denn jeder einzelne in dem System findet sich selbst ja durchaus fähig. Aber eben dies würde nicht stimmen, hätten alle recht. Dieser Gedanke führt uns also in eine Sackgasse. Die Lösung des Problems besteht darin, dass genau nur einer weiß, wo es wirklich lang geht. Irgendwo müsste also eine Art Übermensch existieren. Das stellt uns dann insofern vor eine handfeste praktische Herausforderung, als dass 99,99999…% von uns quasi nicht zu gebrauchen sind, denn es kann ja nur Einen geben.

Jeder, der in sich so etwas wie einen leisen Zweifel aufkommen spürt, dass er vielleicht doch nicht der Eine, der Unfehlbare ist, sollte an dieser Stelle dazu übergehen, sich als Teil der 99,99999…% fehlerbehafteten Normalos zu akzeptieren und mit all den anderen daran zu arbeiten, möglichst gute Ergebnisse zu erzielen. Sich also nicht fragen, warum die anderen so schlecht sind, sondern fragen, was man selber dazu beitragen kann, um gemeinsam besser zu werden! Dann werden Sachen möglich, die vorher nicht möglich waren. Vielleicht fangen sogar alle an, am gleichen Strang zu ziehen und Spaß an der gemeinsamen Arbeit zu haben – sogar über Abteilungs- und Unternehmensgrenzen hinweg! Das agile Manifest hat dies insbesondere mit der Betonung von Individuen und Interaktionen über Prozesse und Werkzeuge
, von Zusammenarbeit mit dem Kunden über Vertragsverhandlung und von 
reagieren auf Veränderung über das Befolgen eines Plans zu drei der vier Kernwerte gemacht. Gelingt es uns, diese Wert mit Leben zu füllen, dann sind wir schon auf einem ganz guten Weg, um mit unserer eigenen Fehlbarkeit zurecht zu kommen.

Und für alle, die nach wie vor denken, dass sie der oder die Unfehlbare sind: nutzt Eure unglaubliche Macht und tut doch bitte einfach so, als ob ihr auch nur einer von uns seid! Danke! 

Wissen und Glauben

Data Driven ist das große Schlagwort unserer Zeit. Insbesondere durch bzw. im Netz können wir auf beliebig viele Daten zugreifen, Tests durchführen und somit unsere Geschäfte auf Basis von Wissen steuern. Aber warum gibt es trotzdem Diskussionen und scheinbar nicht nachvollziehbare Entscheidungen? Um diesem Problem auf die Spur zu kommen, kann die klassische Analyse des Wissens helfen. Diese postuliert, dass ein Subjekt S weiß, dass P, dann und nur dann, wenn:

  1. P wahr ist
  2. S glaubt, dass P
  3. S hat Gründe zu glauben, dass P

Wissen ist also erstens nur das, was auch wahr ist. So ist z.B. die Aussage Berlin ist die Hauptstadt von Deutschland wahr. Was aber, wenn jemand auf die Frage nach der Hauptstadt von Deutschland zwar Berlin als Antwort gibt, dies aber nur rät? Die Antwort wäre richtig, aber hätte derjenige Wissen? Die zweite oben genannte Bedingung soll genau dies ausschließen, dass nämlich Raten als Wissen klassifiziert wird. Hat also jemand dann wissen, wenn er die richtige Antwort nur errät, aber ganz fest an diese glaubt? Hier kommt die dritte Bedingung ins Spiel, die eine Begründung für den Glauben aus Bedingung zwei fordert. Die Antwort auf die Frage was die Hauptstadt von Berlin ist, sollte also im Falle, dass der Befragte die Antwort tatsächlich weiß ungefähr so lauten: ich bin mir ganz sicher, die Antwort lautet Berlin, das habe ich in der Schule gelernt.

Kommen wir nun zurück zu unserem Ausgangsproblem. Nehmen wir einmal an, wir haben die Hypothese bzw. den Glauben, dass wir durch eine kleine Änderung an dem Layout einer Website, mehr Kunden gewinnen können. In diesem einfachen Beispiel können wir einen A/B-Test durchführen und haben so am Ende ein abgesichertes Ergebnis darüber, welcher der Varianten gemäß dem überprüften Ziel die bessere ist. Wenn unsere Hypothese zu den Ergebnissen passt, dann haben wir oben genannten Anforderungen folgend Wissen gesammelt, denn wir wissen was wahr ist, glauben daran und haben durch unseren Test auch Gründe es zu glauben. Was aber, wenn die Testergebnisse und unsere Hypothese nicht übereinstimmen? Man könnte die vorliegenden Testergebnisse zum Anlass nehmen, um seinen eigenen Glauben neu zu justieren und alles ist wieder im Lot. Oder aber, man hält an seinem Glauben fest und zweifelt z.B. den Test an. Denn wer kann schon 100%ig garantieren, dass es nicht zu irgendwelchen unbemerkten Problemen bei dem Test kam? Und was passiert, wenn wir gar nicht in der Lage sind einen Test zu machen, weil die Problemstellung zu komplex ist?

Die oben genannte Anforderung, dass etwas wahr sein muss, um als Wissen zu gelten, ist in der Realität in vielen Fällen gar nicht eindeutig überprüfbar. Bei der zweiten Bedingung sieht dies natürlich schon ganz anders aus, denn in den meisten Fällen werden wir wohl eine Meinung haben, also an etwas glauben. Dann beginnen wir über die Begründungen für unseren Glauben zu reden, was unter Umständen schon gar nichts mehr mit der Wahrheit zu tun hat. Ganz schwierig wird es, wenn die Begründung für unseren Glauben allein die Erkenntnisse der Vergangenheit sind, getreu dem Motto „das machen wir schon immer so“. Und wenn jetzt noch die Hierarchie ins Spiel kommt, dann haben wir einen Teufelskreis geschlossen, in dem jegliche Entwicklung ausgeschlossen wird.

Was bleibt als Fazit? Wenn wir uns bewusst sind, das Wissen und Glauben sehr eng zusammen hängen, dann haben wir die Chance sowohl uns selbst als auch unsere Mitmenschen zu reflektieren und zu hinterfragen. Vielleicht reicht allein dies in bestimmten Situationen schon aus, um bessere Entscheidungen zu treffen. Darüber hinaus ist dies für mich ein Beleg dafür, sich ganz bewusst nicht nur auf das eigene Wissen zu verlassen, denn vielleicht ist unser Wissen ja eigentlich nur Glauben. Wenn wir stärker auf Austausch und eine offene, ehrliche Diskussionskultur setzen, dann haben wir die Chance dauerhaft bessere Entscheidungen zu treffen und echtes Wissen über unser Geschäft zu sammeln. Dies ist für mich einer der ganz relevanten Eckpfeiler der agilen Idee.