Der Lösungs-Zoo

Hereinspaziert, hereinspaziert, geben Sie ihr Problem direkt bei uns an der Kasse ab. Wir präsentieren den Lösungs-Zoo. Egal welches Problem Sie haben, wir haben attraktive Lösungen am laufenden Band. Wir müssen weder ihr Problem kennen, noch inspizieren wir es und bitte reden Sie nicht mit uns darüber. Mit jeder unserer Lösungen bestehen Sie im Löwenkäfig wie am Trapez!

Ständig Lösungsorientierung, nein danke

Mit dem Hut der Lösungsorientierung formuliert man positive Ziele, teilweise auch ohne sich der Probleme bekannt zu sein, weil sie z. B. wie bei menschlichen Beziehungen versteckt in Wahrnehmung und Aussagen sind. Mittels wertschätzender Kommunikation, positiven Verstärkens und dem Bewusstmachen der verfügbaren Ressourcen umschifft man dabei Beschuldigung und Anklagen. Man richtet seinen Fokus auf die Zukunft.

Sich einer Methode zu  verschreiben ist das eine, das andere ist eine Methode über alles andere zu stellen: Heute ist es teilweise verpönt Probleme ohne Lösung anzusprechen. Das wäre nicht konstruktiv sagt man. Man könne kein Problem diskutieren ohne Lösung, am besten mehr als eine Option. Management könnte man nicht damit aufhalten keine Lösung zu präsentieren, denn die hätten ihre eigenen Probleme.

Ich frage mich an dieser Stelle: Schämt man sich dafür, dass es ein Problem zu lösen gilt und noch nicht direkt eine Lösung präsentieren kann? Oder wirkt man inkompetent, gar dumm, wenn man nicht eine Lösung an der Hand hat? Oder vergisst man, dass es mehr als einen Hut gibt, den man tragen kann?

Es geht soweit, dass manche meinen, man ist ohne Lösungsorientierung nicht mehr positiv. Das ist die eine Art der Interpretation und man verkennt den Zweck der Methode Anschuldigungen hinter sich zu lassen. Der Fehler passiert allerdings früher: Ein Problem ist erstmal eine Beobachtung. Darauf folgt eine Interpretation. Beides zu trennen und zu erkennen, dass die eigene Interpretation fehlerhaft sein kann, erfordert Demut. Betreten wir den Lösungsraum zu früh und validieren wir unsere Beobachtungen nicht, dann wird unsere Lösung dem Problem nicht gerecht und wir jonglieren mit leeren Händen.

Zu ihrem Problem...

...sagen sie jetzt nichts, wir kennen die Lösung!

In der Software-Entwicklung kennen wir es: wir hören unseren Kunden nicht richtig zu und haben die Lösungen schon im Kopf. Wir nehmen durch vorauseilenden Gehorsam und der Überschätzung unserer eigenen Fertigkeiten die Lösung vorweg.

Nur noch adapt, kein inspect mehr

Genauso ereilt es immer wieder ScrumMaster, Consultants und dergleichen. Sie springen sofort auf die Lösungen, ohne sich dem Problem zu widmen. Sie adaptieren, ohne zu inspizieren. Schritt zwei vor Schritt eins. "Habe ich schon mal gehört, so ähnlich gehabt oder klingt wie" heißt es dann und schneller als man bis drei zählt ist eine Lösung parat. Wer Hammer und Schrauben hat nagelt gerne.

Tell me my future von twogypsyhearts (Flickr/CC 2.0)

Dabei gibt es bei Problemen so viel zu holen. Betrachtet man ein Problem gemeinsam aus mehreren Blickwinkeln, kann man tief schürfen: 

  1. Der Blick auf das Sozialverhalten bei dem Problem ist eine Facette.
  2. Gemeinsame bereits erfolgte Beobachtungen zu diskutieren ist großartig. 
  3. Wem ist etwas anderes, vielleicht gegenteiliges aufgefallen? 
  4. Abzusprechen wie man das Problem untersuchen möchte birgt Möglichkeiten. Spanned wird welche Beobachtungen noch zu machen sind.
  5. Welche Anreizsysteme verbergen sich hinter dem Problem, wo sind die Ursachen?
  6. Was bedeutet das Problem lokal, was global?
  7. Mit welchen Problemen steht es in Verbindung?
  8. Was sind Katalysatoren, was Hemmer? 
  9. Was wäre der Lackmus-Test für die Lösung?

 

 

Was übrig bleibt

Neben Lösungsorientierung gibt es noch Problem- und Potentialorientierung. Hier liegen lohnende Perspektiven. Warum nicht den Hut wechseln und ein Problem aus allen drei Perspektiven beleuchten?

Vielleicht es einmal wieder so machen wie früher Toyota in den USA: Ein Manager wird von seinem Vorgesetzten gebeten über die Probleme zu reden, damit sie diese gemeinsam lösen können. Das Selbstverständnis war dort, dass sie dafür da waren Probleme zu kennen und zu lösen. 

Vielleicht ist es auch nur eine Einstellungssache, ob ein Problem etwas ist, was man meiden sollte.

SVNWNK

Das große M

Tom DeMarco nennt es die große "M"ethodik. Das große M stellt eine Dysfunktion in Organisationen dar. Man spricht davon, wenn blind auf eine Methodik vertraut wird und man die Methodik höher stellt als die Menschen, die sie ausführen müssen. Wem das vertraut vorkommt, dem ist der Teilsatz "Scrum-Einführung mit Management-Support" sicherlich bekannt.

Die Einführung einer Methodik vollzieht man auf zwei Arten:

  1. Methodik als Mittel angepasst an Situation, Plan und Organisation
  2. Methodik als Standard, auszuführen nach Rezept

Nutzt man eine Methodik, um sie wie bei 1. selbst an die eigenen Bedürfnisse anzupassen, wird man wenig an der Sinnhaftigkeit der Methodik zweifeln. Wichtig ist hier, sich seines Systems in dem man sich befindet klar zu sein. Obwohl die meisten Menschen sofort bejahen, dass sie diesen Überblick haben, wird auf den 2. oder 3. Blick meist klar, dass das nicht der Fall ist.

Wenig Raum in dieser Gasse - vielleicht eine Abkürzung aber sicher kein Raum für beste Ergebnisse.

Schreibt man eine Methodik wie bei 2. vor, die zwanghaft umgesetzt werden muss, verringert man den Status der Menschen, die man zur Methodik zwingt. So sagt man ihnen doch deutlich, dass die Kompetenz bei der Methodik liegt und nicht in den Köpfen der Menschen. Man degradiert sie und sie antworten mit angepasster Methodenhörigkeit als Protest, angedeuteter Inkompetenz als Widerstand oder offenen Anfeindungen als Ablehnung. Tritt ein Fehler auf, kann man ihn der Methodik zuschieben, man ist die Verantwortung los - prima!

Durch die Entmündigung verliert man das Commitment, da die bestmögliche Leistung und der Stolz der Menschen durch die Methodik blockiert wird.  Das ist nur die menschliche Seite. Die Imitation führt oft auch zu mangelhaften Ergebnissen, da Situationen nicht 1:1 übertragbar sind und methodenabhängige Folgeeffekte in jeder Umgebung wünschenswert sind.

Was ich nicht sage

Methoden "by the book" auszuführen ist schlecht. Das sehe ich nicht so.

Meiner Erfahrung nach waren beispielsweise die erfolgreichsten Scrums die, die "by the book" umgesetzt wurden. Jedoch lag dort auch immer der Fokus auf den Menschen und der Interaktion, und die Methodik war nicht Aggressor. Insbesondere dort wo ein Standard fehlt, kann eine Methode eine Baseline setzen. Wenn man seine Arbeitsweise ändert, lohnt es sich an einen Standard zu halten und sich davon aus fortzubewegen.

Was ich sage

Menschen benötigen die Herrschaft über ihre eigenen Prozesse. Keine aufgezwungen Prozesse, die fern ihrer Realität aufgezwungen werden.

Ein Beispiel:

Eine Abteilung wurde bestimmt der Prototyp für eine Scrum-Skalierung zu werden: 3 Teams, neu geschnitten und alle direkt nach Scrum arbeiten. Was für zwei Teams eingeschränkt in Ordnung war, war bei einem Team extrem kontraproduktiv, da sie bereits ihren besten Prozess gefunden hatten: ein Flow-System von der Anforderung direkt in die Produktion, optimiert von den Menschen, die bereits jahrelang Erfahrung mit ihrem eigenen System hatten. Einige neue Praktiken hätten sicherlich geholfen. Das fremde Paket zerstörte Motivation, Commitment und Durchsatz.

Was man noch bedenken sollte

Alle, die seit Jahren auf den Scrum-Hype aufspringen und alles Scrumatisieren verpassen eines: die Vielfalt es besser machen zu können. 

SVNWNK 

Arbeitsplatzschmerzen - Nicht nur für Wissensarbeiter

Wenn der Arbeitsplatz schadet

Es ist wenig verwunderlich, dass große Firmen wie Google stolz auf die Arbeitsplätze für ihre Mitarbeiter sind und sie der Welt zeigen.  Ist doch der Arbeitsplatz entscheidend bei der Wahl für oder gegen ein Unternehmen. Denn über die Arbeitsplatzgestaltung lässt sich viel auf die Unternehmenskultur schließen. Der Arbeitsplatz drückt aus, was unausgesprochen bleibt: wir atmen etwas der Kultur ein, zumindest suggeriert unser Hirn uns das, und wir stellen Erwartungen und treffen Annahmen. Obwohl Kultur spannend ist, möchte ich hier über die Gestaltung von Arbeitsplätzen von Wissensarbeitern schreiben. Über unterschiedliche Arbeitsplätze, die ich gesehen und über das was ich dort gefühlt habe, über das was für mich wichtig ist an einem Arbeitsplatz.

First things first

Wenn Du deine Leute über ihren Arbeitsplatz entscheiden lässt, dann zahlen sie dir das tausendfach zurück. Überstimmst Du sie bei der Gestaltung des eigenen Arbeitsplatzes, dann zerkratzt Du ihre Verbindung zu dir. 

Ein Beispiel: Die Bürowände gehören den Menschen, die dort arbeiten und nicht irgendeinem Hausdienst, Management oder externen Beratern. Keine Diskussion!

Pigs und Chicken auf der Arbeit

Ein Arbeitsplatz im Hauptquatier von Zappos. By lizzielaroo CC-BY-SA-2.0  or CC-BY-SA-2.0, via Wikimedia Commons

Der Arbeitsplatz sollte der Ort sein an dem gearbeitet wird, sofern der Arbeitsplatz einem nicht daran hindert.

Ein Muster dem viele Agile Transitionen folgen ist Colocation. Sicherlich ist Colocation mächtig, jedoch ist das Wichtigste dabei die Leute selbst zu fragen, in welchen Konstellation sie gerne zusammensitzen möchten: ein Raum, zwei Räume, wie viele Leute in einem Raum, was auch immer. Als Chicken sollte man nicht über sie bestimmen, sie in einem Pferch einsperren. Vertraue den Leute, die die Arbeit verrichten und nenne ihnen die Einschränkungen und den Rahmen.

Separation, Fragmentierung und ungezwungener Austausch

Viel Schaden wird am Arbeitsplatz dadurch angerichtet, dass Teams auseinander gerissen und separat untergebracht werden. Wahrscheinlich leidet die Arbeit darunter, wenn Teammitglieder losgelöst voneinander. Was dabei definitiv verloren geht, ist der ungezwungene Austausch untereinander. Über diesen Austausch bauen sich Verbindungen und damit eingehend Vertrauen auf und es entstehen Handlungsspielräume. Man verliert viel, wenn man Teams nicht zusammen sitzen lässt.

Zudem fördern verstreute und verteilte Teams Verschwendung (Waste). Wenn man es vermeiden kann, dann sollte man solche Teams nicht in Betracht ziehen - mit einer Ausnahme: das Team möchte es selbst so. Teams, die bestimmt werden agieren üblicherweise weit unter ihren Möglichkeiten. Verteilte Teams, die bestimmt werden tun sich noch weitaus schwerer.

Boxenstop von McLaren 2006 in Malaysia. By Kamalsell (Flickr) CC-BY-2.0, via Wikimedia Commons

Teams auf verschiedene Standorte aufzuteilen ist schädlich, aber Teammitglieder in ihren Aufgaben zu fragentieren ist weitaus schlimmer. Arbeiten Leute an mehr als einem Projekt, Produkt oder was auch immer, dann führt das dazu, dass sie weniger fokussiert arbeiten und mit enorm mehr Störungen umgehen müssen. Sie ringen und stolpern die meiste Zeit, da es ihnen schwer fällt mit der Anzahl der menschlichen Interaktionen umzugehen. Das hindert sie wiederum, sich in einen Flow-Zustand zu begeben. Bevor es ihnen gelingt etwas abzuschließen, reißt sie wieder jemand heraus und stiehlt ihre Aufmerksamkeit. Man fühlt sich dann wie ein Formel 1 Auto, das für immer beim Boxenstop steht: viel Power, doch keine Performance, da ständig jemand einem die Reifen und andere Teile wechselt. Leider ist dieses Szenario weit verbreitet und erzeugt mehr Verschwendung als Wert.

Ruhe und der Flow-Zustand

Von einem Flow-Zustand spricht man, wenn Menschen beim Arbeiten in eine Leichtigkeit verfallen. Um einen Flow-Zustand zu erreichen, benötigt man Zeit. Üblicherweise erledigt man während eines Flow-Zustands außerordentlich viel. Um dorthinzukommen muss man sich konzentrieren, dafür braucht man Ruhe. Um einen Arbeitsplatz zu schaffen, der das unterstützt, fragt man am besten die Leute selbst. Sie werden sehr gute Vorschläge machen, was sie benötigen um ungestört zu arbeiten. Lässt man sie, werden sie ihren Arbeitsplatz verbessern. Besser man ist zuvorkommend und hilf ihnen dabei, den besseren Arbeitsplatz zu schaffen. Das Prinzip Colocation unterstützt auch dabei, um in einem Flow-Zustand zu kommen: Teammitglieder tendieren dazu zur gleichen Zeit ruhig zu werden und ihre Arbeit zu verrichten, das führt für gewöhnlich zu weniger Unterbrechungen und Störungen. Fragmentierung von Teams, wie oben angesprochen, führt letztlich zu wenig bis gar keiner ruhigen Zeit zum arbeiten.

Natürlich und ...

Sicherlich ist das was ich hier schrieb nichts Neues, nichtsdestotrotz wird es viel zu oft überhört. Oftmals hat es gar nicht so viel damit zu tun, dass bspw. das Management unfähig ist diese Konzepte anzunehmen, es fällt Menschen viel schwerer die alten Ideen zu vergessen, wie John Maynard Keynes sagen würde.

SVNWNK

this article in English: click 

 

Ich habe fertig

"Ich habe fertig"

Als Trappatoni 1998 seine Pressekonferenz mit den Worten "Ich habe fertig!" beendete, war allen Anwesenden unmissverständlich klar, was er mit fertig meinte. In der Software-Entwicklung sieht das oft noch anders aus. Es stapeln sich Berge von unsichtbarer, ungetaner Arbeit, Aufgaben und Aktivitäten, die zum Ende einer Story, eines Sprints und eines Releases anstehen. Damit mag eine Entwicklung für den einen "fertig" sein, für den anderen bedeutet es den Anfang weiterer Aktivitäten, bevor die Funktion tatsächlich abgeschlossen ist. Fertig (done) ist oft ein weites Feld, welches es zu beackern gilt und es benötigt eine Änderung der Arbeitsweise um am Ende ein stabiles Produktinkrement zu liefern. Eine gute Definition of Done ist nicht mit einer Definition getan, üblicherweise ist es ein Weg zur Professionalisierung: "Therefore, a group defines their DoD as their current technical and organizational ability - typically starting below the perfection challange. [...] Over time, as the group improves, their DoD expands until it is equal to truly potentially shippable." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 170)

Wenn es ein Weg ist, dann stellt sich berechtigterweise die Frage: "Wo stehen wir gerade und was hat dazu geführt, dass wir noch keine Definition von fertig haben?"

Jeff Sutherland und Ken Schwaber führen für den zweiten Teil der Frage folgende Gründe an: "Many of the Scrum Development Teams with which we have worked were initially unable to develop ready-to-use increments of software bye the end of a Sprint. Transparency wasn't required from them in the past, so they often do not have the technical skill or adequate tools to rapidly build transparent software functionality" (Jeff Sutherland, Ken Schwaber, Software in 30 Days, 2012, p. 91) - für den ersten Teil der Frage gilt: "Ask the team."

Wir haben über offene Tätigkeiten und Aktivitäten gesprochen, die nicht im normalen Entwicklungsalltag aufgenommen wurden. Wie bringt man nun die gesammelten, ungetanen Aktivitäten in die Software?

Dazu gibt es zwei Möglichkeiten:

  1. Man führt sie durch, oder fängt an sie durchzuführen
  2. Man führt sie nicht durch und erzeugt technische Schuld (technical debt) und erstickt an ihr

Führt man die offenen Aktivitäten durch und ist man dem fallenden Wasser noch sehr nah (Vorsicht, schlechtes Wortspiel), dann tendieren viele Organisation dazu extra Phasen (Sprints) einzubauen, damit stabilisiert man vor einem Release das Produkt und bereinigt die gefundenen Fehler (Hardening). Das gleicht oft einer Springflut, die auf eine Staumauer zu rast.

Wir übersehen bei einem solchen Vorgehen gerne: "'Hardening' - an aspect of Undone Work - is so common that some do not see it for what it is: a failure, not a solution." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 175)

Hardening läuft wesentlich einer Sache entgegen: Qualität kann nicht nach der Entwicklung entstehen, sie muss Teil der Entwicklung sein. Ziel darf nicht sein bspw. etwaige Fehler einzusammeln, stattdessen ist es Ziel den eigenen Prozess so zu gestalten, dass Defekte in Funktionalität und Design während der täglichen Arbeit bereinigt werden. 

Djikstra sagt dazu: "Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce bugs to start with." (Djikstra, The Humble Programmer, 1972) - und geht noch einen Schritt weiter und spielt auf testgetriebene Entwicklung an - für mich ein wesentlicher Bestandteil von fertig. In jedem Fall sagt er, dass der Entwicklungsprozess seine Fehler unmittelbar am Anfang zu suchen hat und am besten keinerlei Fehler produzieren sollte - ein klarer Ausspruch gegen Hardening-Phasen, sondern vielmehr:

"Work of iteration = Product Backlog Items + Definition of Done" (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 171)

Stellt sich nun die Frage, was gehört in eine Definition von Fertig? Auch hier fragen Sie am besten ihr Team was es bereits leistet, gerne leisten würde und informieren Sie sich darüber was in ihrem Umfeld Standard ist. Zielführend ist es sich an den oberen 20% zu orientieren, über den Rand hinauszusehen und den Standard nur als Nulllinie für Verbesserung anzusehen.

Hier ein Beispiel für ein paar wichtige Merkmale einer Definition von Fertig für die Level Story, Sprint und Release:

Story-Level (fertig für jede Story)

  • Clean code
  • Unit testing with TDD
  • Continuous integration
  • Automated acceptance testing
  • Technical documentation

Sprint-Level (fertig für jeden Sprint)

  • Performance testing
  • Exploratory testing
  • User handbook
  • Process test
  • Installation notes

Release-Level (fertig für jedes Release)

  • Process tests with current live data
  • Packaging and installation notes
  • Key user training

Wie sehen nun Schritte auf einem Weg zur Definition of Done aus?

  1. Brainstorming: Welche Aktivitäten kennt das Team bereits  und welche werden vom Team ausgeführt?
  2. Zuordnen der Aktivitäten zu den einzelnen Level: 
    1. Wann kann das Team wann liefern? Startend auf dem Story-Level fragen Sie das Team welche Aktivitäten es pro Story zum heutigen Stand liefern kann (keine Wunschträume). Alles was nicht pro Story geliefert werden kann, wird auf das Sprint-Level geschoben.
    2. Erneut die Frage: Was kann das Team liefern? - dieses Mal für das Story-Level (weiterhin keine Wunschträume). Alles was nicht pro Sprint geliefert werden kann, wird auf das Release-Level geschoben.
    3. Nun sind alle Aktivitäten in die drei Kategorien Story-Level, Sprint-Level & Release-Level eingeteilt. Sofern es Tätigkeiten gibt, die existentiell für die Produktion, d. h. für den Praxisgang sind eröffnen Sie ein weiteres Level (Produktions-Level) und wiederholen die obigen Schritte für Release- und Produktions-Level.

Nun haben Sie eine initiale Definition von Fertig. Eine Definition von Fertig ist ein Arbeitsstand, ein sogenanntes lebendiges Dokument, das sich verändern, verbessern sollte. Das heißt konkret: Geben Sie ihnen und ihrem Team immer wieder die Chance und Aufgabe zur Reflektion der Definition von Fertig. Hierfür ist es wichtig die Definition zu visualisieren, am besten im Stil eines Boards, bei dem sich die Aktivitäten verschieben lassen. Als bspw. ScrumMaster finden Sie heraus wo welche Aktivitäten am sinnvollsten aufgehoben sind. Sind Tätigkeiten teuer, lohnt es sich wahrscheinlich diese für mehr als eine Story durchzuführen. Gibt es Tätigkeiten, die sich ein Level zu weit oben, z. B. im Release-Level wiederfinden, dann gilt es herauszufinden was die Hindernisse sind, um diese Aktivität früher durchzuführen. Es handelt sich tatsächlich um Hindernisse, für die meist die Mittel z. B. das Wissen/Fähigkeiten fehlen.

Abschließend noch ein Satz: Das Team definiert hiermit auch seinen Arbeitsethos, das Selbstwertgefühl für die eigene Arbeit. Das Meiste was Sie hier finden ist nicht verhandelbar, im Sinne von "wir können das mal weglassen", vielmehr ist es ein Teil der Motivation, warum ihr Team seine Arbeit macht. Zwingen Sie ihr Team dazu darauf zu verzichten, dann kostet sie das spürbar Produktivität.

In diesem Sinne: "Ich habe fertig." 

SVNWNK