Mittwoch, 9. April 2014

Wichtiges verlässlich erledigt kriegen

Erledigt wird nur, was dringend ist. Ich denke, darin stimmen wir überein.

Aber es gibt Wichtiges und es gibt Dringendes. Beides muss erledigt werden – nur schiebt sich das Dringende scheinbar oft, allzu oft vor das Wichtige.

Das Wichtige

Das ist misslich und früher oder später gefährlich, denn das Wichtige ist ja das, was getan werden muss. Das macht seine Definition aus: Was bei Unterlassung über kurz oder lang zu einer Gefährdung der Existenz eines Systems führt, ist wichtig.

Ein Beispiel: Der Zweck einer Softwareschmiede ist (zumindest), mit Software soviel Geld zu verdienen, dass die daran beteiligten Menschen auf unbestimmte Zeit, d.h. jetzt und in Zukunft ihr Auskommen haben.

Im Hinblick auf diesen Zweck ist es unter anderem wichtig...

•    fähige und motivierte Menschen zu beschäftigen (Personalwesen),
•    attraktive Software herzustellen (Softwareentwicklung),
•    die Software dem Markt bekannt zu machen (Marketing),
•    für die Software Kunden zu bekommen (Vertrieb),
•    Kunden zu betreuen (Support, Schulungen)
•    mit Kunden und Lieferanten und Mitarbeitern abzurechnen (Buchhaltung)
•    Steuern zu zahlen (oder auch zu sparen) (Buchhaltung, Steuerberatung)
•    den Markt zu beobachten und Strategien zu definieren (Geschäftsführung)

Wenn eine dieser und weiterer Wichtigkeiten für längere Zeit unbeachtet bleibt, dann wird die Existenz der Softwareschmiede bedroht.

Nicht wichtig ist gewöhnlich hingegen, einen speziellen Mitarbeiter zu bekommen/halten, eine bestimmte Rechnung zu schreiben, ein spezifisches Feature einzubauen, einen bestimmten Kunden zu bekommen, einen speziellen Rechner zu kaufen usw.

Einzelnes ist nicht wichtig, sondern höchstens dringend. Oder wenn Einzelnes wichtig ist, dann ist es eine systemrelevante Größe. Dann ist Gefahr im Verzug!

Da nun selbstverständlich ausschließlich getan werden soll, was unter das Dach von etwas Wichtigem gehört, ist das Dringende immer auch etwas Wichtiges.

Damit schließt sich der Kreis: Wichtiges wird also doch getan. Zumindest sobald es dringend geworden ist. Das bedeutet unzuverlässig. Und das bedeutet oft spät. So spät, dass die Arbeit sich ausnimmt wie krampfhaftes Zucken, denn koordiniertes Voranschreiten.

Wie kann das verhindert werden?

Das Dringende

Wichtiges und Dringendes sind mithin keine Gegensätze. Dringendes ist vielmehr eine Sonderform des Wichtigen. Was es so besonders macht, das ist seine Konkretheit in Bezug auf Zustände.

Dringendes hat einen konkreten Ziel- oder Erledigungszustand sowie einen existenzbedrohenden Zustand. Immer ist es an Zeit gekoppelt, oft auch an einen Termin. Erledigung des Dringenden soll den Zielzustand herstellen; bleibt das Dringende hingegen unerledigt, tritt der existenzbedrohende Zustand ein.

Beispiel 1: Steuererklärung. Steuern zu zahlen, ist wichtig. Deshalb muss jährlich eine Steuererklärung abgegeben werden. Diese Tätigkeit ist jedoch nicht per se dringend. Sie wird erst mit der Zeit dringend, wenn der Abgabetermin näher rückt. Verstreicht der Abgabetermin ohne Steuererklärung, kann das existenzbedrohende Folgen haben.

Beispiel 2: Angebotsabgabe. Aufträge zu gewinnen, ist wichtig. Deshalb müssen immer wieder Angebote abgegeben werden. Oft unterliegt diese Abgabe einem Termin. Ein Angebot abzugeben ist jedoch nicht per se dringend. Es wird erst mit der Zeit dringend, wenn der Abgabetermin näher rückt. Verstreicht der Abgabetermin ohne Angebot, kann das – zumindest wenn es häufiger geschieht – existenzbedrohende Folgen haben.

Beispiel 3: Geldreserve. Eine Geldreserve zu haben, ist wichtig. Nur so können Schwankungen im Umsatz ausgeglichen werden, um weiterhin Verbindlichkeiten nachzukommen und Löhne zu zahlen. Deshalb ist die Aufstockung der Geldreserve jedoch nicht per se dringend. Sie wird es erst, wenn sich die Geldreserve dem Nullpunkt nähert. Allemal wenn die Geldreserve auf Null ist, ist die Existenz bedroht, sofern die Umsätze zu schwach sind.

Zielzustand und existenzbedrohender Zustand sind in den Beispielen klar. In den ersten Beispielen ist der Wechsel vom aktuellen Zustand in den einen oder anderen quasi binär und termingebunden. Im dritten Beispiel hingegen ist er graduell und nicht termingebunden, sondern wertgebunden.

Wann wird eine Tätigkeit oder allgemeiner der Eingriff in die Entwicklung eines Zustands nun dringend? Wenn das Risiko groß wird, in der verbleibenden Zeit den Zielzustand nicht zu erreichen.

image

Das Risiko ist an den Aufwand gekoppelt. Ist der Aufwand sehr klein und auch nicht selbst noch mit Unwägbarkeiten behaftet, gibt es bis kurz vor Erreichen des existenzbedrohenden Zustands keine Dringlichkeit. Ist der Aufwand hingegen groß oder gar unbekannt, stellt sich Dringlichkeit schon lange vor Erreichen des existenzbedrohenden Zustands ein.

Zu Beispiel 1: Wie groß ist der Aufwand für eine Steuererklärung? Bei mir dauert es ca. 1 Tag, um alle Unterlagen und Daten zusammenzutragen. Anschließend braucht der Steuerberater nochmal ca. 4 Wochen. Diese Aufwände sind mit wenig Unsicherheit behaftet. D.h. dringend wird für mich die jährliche Steuererklärung vielleicht 5 Wochen vor Abgabetermin.

Zu Beispiel 2: Wie groß ist der Aufwand für das Angebot? Vielleicht dauert es nur 1 Stunde, vielleicht dauert es aber auch 1 Woche, um alles durchgerechnet und formuliert zu haben. Wie unwägbar ist der Aufwand? Statt 1 Stunde könnten es auch 2 sein? Statt 1 Woche auch 3? Wenn der Versand per Email quasi in Nullzeit erfolgt, dann wird das Angebot 2 Stunden bzw. 3 Wochen vor Abgabetermin dringend.

Zu Beispiel 3: Wie groß ist der Aufwand, die Geldreserve wieder aufzustocken bis sie das nächste Mal in Anspruch genommen werden muss? Vielleicht geschieht das durch eine absehbare Zahlung eines Kunden in der nächsten Woche, vielleicht braucht es aber auch Wochen und Monate. Im ersten Fall tritt Dringlichkeit vielleicht gar nicht ein, weil die Entwicklung des Reservebestands bis nächste Woche nicht bei Null angekommen sein wird. Im zweiten Fall ist die Aufstockung eher kontinuierlich dringend, solange die Reserve unterhalb einer Sollmarke liegt.

Das Wichtige verdringlichen

Mit der Zeit wird alles Wichtige dringend. Wenn wir das aber passiv zulassen, dann reagieren wir nur noch. Dann sind wir nicht mehr Herr im eigenen Haus, sondern werden „Spontanbränden“ zur ewigen Feuerwehraktionen gezwungen.

So lässt sich ein Unternehmen führen – sogar recht lange, wie ich immer wieder feststellen muss. Aber macht das Spaß? Ist das ökonomisch? Das bezweifle ich.

Ich ziehe Agieren dem Reagieren vor. Ich ziehe fließende ruhige Abarbeitung dem Hinterherhecheln vor.

Dafür ist es unabdingbar, das Wichtige nicht aus den Augen zu lassen. Sonst erschreckt es uns irgendwann.

Wenn nun aber anscheinend nur das Dringende getan wird, muss das Wichtige von vornherein auch dringend sein. Wir müssen es also bewusst und angemessen verdringlichen. Wie kann das geschehen?

Beobachtung

Am Anfang steht für mich, sich des Wichtigen überhaupt erst einmal bewusst zu werden – und dann das Wichtige zu beobachten. Wie entwickeln sich wichtige Metriken? Steigen oder fallen Mitarbeiterfähigkeit, Mitarbeitermotivation, Vertriebserfolg, Softwarequalität, Betreuungszufriedenheit usw.?

Daraus ergeben sich früher oder später wünschenswerte und existenzbedrohende Werte für die Metriken und auch Entwicklungskurven.

Planung

Wenn insbesondere die existenzbedrohenden Zustände und ihre Entwicklungskurven bekannt sind, dann plane ich konkrete Kompensationen ein, soweit das geht. Für die Steuererklärung trage ich einen Tag 5 Wochen vor dem Abgabetermin ein. Für die Angebotsabgabe blocke ich z.B. 4 Stunden ein oder zwei Tage vor Abgabetermin – sobald ich den kenne.

Auf diese Weise überrascht mich das Wichtige nicht, sondern ich kann ihm mit einem Blick in den Kalender immer ins Auge sehen. So kann ich andere Tätigkeiten danach ausrichten und das Wichtige läuft nicht Gefahr, unter den Tisch zu fallen.

Gewohnheit

Nicht alles Wichtige ist termingebunden oder in seiner Entwicklung länger vorher absehbar. Punktuelle Termine kann ich in den Kalender nicht eintragen. Deshalb muss ich aus der Behandlung des Wichtigen eine Gewohnheit machen.

Meine Geldreserve stocke ich regelmäßig jeden Monat mit einem bestimmten Betrag auf. Um meine Fakturierung kümmere ich mich regelmäßig einmal im Monat. Um meine Positionierung kümmere ich mich jeden Tag eine Stunde. Um das Lernen kümmere ich mich jede Woche 4 Stunden usw.

Hier löst nicht ein „Hau-ruck-Aufwand“ das Problem, sondern Kontinuität. Das Wichtige wird nicht on-demand angegangen, sondern ständig in mehr oder weniger kleinen Häppchen. Das Motto: “Stehter Tropfen hölt den Stein.”

Automatisation

Geplante und rhythmisierte Maßnahmen muss ich noch selbst übernehmen. Ein nächster Schritt ist die Übertragung des Wichtigen an einen Automaten. Der kann geplant, rhythmisch oder on-demand Zustände beobachten und kompensierende Maßnahmen durchführen. Ein Beispiel dafür ist der Dauerauftrag ans Finanzamt für die Einkommenssteuervorauszahlung. Aber auch die Garbage Collection einer Runtime gehört dazu: statt das Wichtige – Speicherverwaltung – dem “Zufall” (oder der mehr oder weniger entwickelten Fähigkeit von Entwicklern) zu überlassen, automatisiert die Runtime die Berücksichtigung dieses Aspekts.

Stakeholder

Wenn eine Automatisation nicht möglich ist, setze ich einen menschlichen Stakeholder ein, dessen (Haupt)Aufgabe das Wichtige ist. Sobald ich mehr mit Abarbeitung des Geplanten und des Kontinuierlichen und der Beobachtung des Wichtigen zu tun habe, als meine Arbeitszeit zulässt, sollte ich Teile des Wichtigen „outsourcen“.

Das gilt auch, wenn ich für das Wichtige unterschiedlich qualifiziert bin. Es mag genauso wichtig sein, eine neue Website aufzusetzen wie neue Kunden zu gewinnen. Aber ich bin besser qualifiziert, für mich Kunden zu finden, als meinen Website zu überarbeiten mit all den HTML5/CSS/JS-Feinheiten, die heute state-of-the-art sind.

Nach der Manifestation des Wichtigen im Kalender und im Rhythmus kommt also die Manifestation in Form einer Person. Damit bekommt das Wichtige zwei Beine, die immer wieder den Weg zu mir finden, um Input einzufordern. Das ist dann wiederum für mich wichtig und sollte ebenso geplant oder rhythmisiert werden.

Zusammenfassung

Wenn sich Dringendes immer wieder störend in unseren Arbeitsfluss mischt, läuft etwas falsch. Dann haben wir das Ruder aus der Hand gleiten lassen.

Unerwartet Dringendes gilt es mit aller Macht zurückzudrängen und zur Ausnahme zu machen. Stattdessen müssen wir versuchen, das Wichtige bewusst so zu konkretisieren, dass es sich wie Dringendes ausnimmt, geplantes Dringendes. So können wir auch erkennen, wenn es über unsere Kräfte geht. Dann müssen wir Hilfe suchen.

Es ist also nicht schlimm, wenn nur Dringendes erledigt wird. Wir dürfen uns davon nur nicht überraschen lassen. Umarmen wir also das Dringende. Machen wir uns seine Kraft zunutze.

Montag, 7. April 2014

Arbeitszeiteinteilung für Veränderung

Der Wunsch, irgendwie besser Software zu entwickeln, ist weit verbreitet. Irgendwas stört in jedem Projekt. Irgendwie hakt es in jedem Team. Viele leiden unter der Last von Legacy Code. Andere kämpfen mit Qualitätsproblemen oder unzuverlässiger Lieferung.

Zur Verbesserung der Situation lässt sich dann natürlich allerlei raten. Mehr Clean Code, konsequentere Agilität, bessere Infrastruktur, modernere Tools und Technologien usw. usf. bieten sich an. Die Wiese ist bunt und groß, von der man sich einen Strauß an Maßnahmen pflücken kann.

Der schönste Blumengruß kann jedoch keine Wirkung entfalten, wenn es an einer Vase fehlt. Dann freut sich der Empfänger – und weiß anschließend nicht recht, wohin damit.

Zunehmend scheint mir das der Fall zu sein. Organisationen kommen aus ihren Problemen nicht raus, weil es ihnen am Grundsätzlichsten fehlt, um überhaupt irgendwelche Maßnahmen umzusetzen.

Die Arbeitszeit ist nämlich gefüllt mit Tagesgeschäft, d.h. mit Dringendem, mit Zeugs, das einfach irgendwie weggeschafft werden muss.

image

Da ist kein Raum, um irgendetwas anderes noch unterzubringen. Da ist auch kein Raum für Fehler – jenseits derer, die ja ohnehin passieren.

imageÜberall wird ohne Puffer gearbeitet. Die Arbeit fließt so wie Berufsverkehr zur Rush Hour: Es geht voran, aber langsam. Und wehe, es hakt irgendwo!

Platz für Neues gibt es in solcher Arbeitsweise nicht. Der vorhandene Zeitraum ist ja schon ausgefüllt.

Und so sitzt man da in seiner Misere. Es tut weh, man weiß, dass es anders sein sollte, man ist guten Willens – aber man sieht sich auch außerstande, Maßnahmen anzugehen und verlässlich umzusetzen.

Am schönsten wäre es, wenn mit Tips & Tricks alles besser würde. Nicht lange lernen oder umdenken, nur hier und da eine Kleinigkeit ändern – am besten durch Einsatz eines Tools – und schon wird aus einer verstopften Autobahn eine Rennstrecke.

Nun… dazu kann man nur sagen: dream on!

So funktioniert es nicht. Nirgends. Das bedeutet nicht, dass nicht hier und da Tips & Tricks bewirken können. Nur reichen Tips & Tricks nicht aus. Eine Organisation, die über längere Zeit Schmerzen spürt, leidet an etwas, das tiefer liegt.

Um diese tiefer liegende Ursache angehen zu können, ist mehr nötig, als hier und da kleine Tips & Tricks umzusetzen. Dafür braucht es Raum, zeitlichen Raum und womöglich sogar physischen Raum.

Das Minimum in dieser Hinsicht sieht für mich so aus:

image

Ja, ich glaube, weniger geht nicht. Und ich werde immer unwilliger, mit Organisationen zu arbeiten, die ihre Arbeit nicht so einteilen können.

  • Reflexion, 5% bzw. 2h/Woche: Ohne Reflexion gibt es keinen Weg. Reflexion bedeutet nämlich Innehalten, d.h. einen Punkt zu bestimmen, an dem man steht und von dem aus man betrachten kann, woher man gekommen ist und wo im Verhältnis zum Ziel man sich befindet. Gibt es Abweichungen, bietet die Reflexion Chance zur Kurskorrektur. Geradlinige Veränderung zum Besseren gibt es nicht. Verbesserung insbesondere chronischer Leiden ist kein ballistischer Flug; es kann keine Maßnahme “abgeschossen” werden, die nach einiger Zeit einfach ins Ziel trifft. Das gilt auf persönlicher wie organisatorischer Ebene. 2 Stunden Reflexion pro Woche sind für mich das Minimum, um insb. in expliziten Veränderungsprozessen, den Weg zu finden. Die können sich aus persönlicher Reflexion und Reflexion im Team zusammensetzen, z.B. jeder Einzelne pro Tag 15 Minuten und das Team einmal pro Woche 45 Minuten.
  • Lernen, 10% bzw. 4h/Woche: Methoden, Tools, Technologien, Konzepte sind ständig im Wandel. Wer glaubt, nebenbei durch gelegentliche Lektüre der c’t am Ball bleiben zu können, lebt in einer Illusion. Persönlicher Marktwert und die Fähigkeit von Teams nehmen ohne explizites und regelmäßiges fokussiertes Lernen ständig ab. Lernen passiert nicht nebenbei. Dafür braucht es einen speziellen Raum – und zwar innerhalb der Arbeitszeit. Mindestens 4 Stunden pro Woche scheinen mir das Minimum. Das kann ein Nachmittag sein oder zwei Mal 2 Stunden. Weniger Lernzeit en bloc jedoch bringt zu wenig Fokus. Was und wie gelernt wird, ist weniger wichtig, als dass gelernt wird. Lernen bedeutet: etwas anders machen als üblich, Spaß haben, Fehler erlauben. Es kann grundlegend gelernt werden, d.h. vom Inhalt her sehr frei, oder auch angewandt, d.h. schon mit Blick auf ein konkretes Problem. Organisationen, die im Wettbewerb stehen, können sich einen Verzicht auf kontinuierliches Lernen letztlich nicht erlauben. Wer nicht durch Lernen den state-of-the-art ständig exploriert, hat keinen “Wissenspuffer”, aus dem er Neues, Cooles, Begeisterndes schöpfen kann.
  • Strategisches, 12,5% bzw. 5h/Woche: Losgelassen frisst das Tagesgeschäft, d.h. das Dringende, das Plötzliche alle Arbeitszeit. Das darf aber nicht sein, denn das Tagesgeschäft ist nicht zukunftsorientiert. Es blick nur vor die Füße und zurück. Den Blick nach vorne stellt die Strategie dar. Sie definiert, was wichtig ist. Zu jeder Zeit gibt es in dieser Hinsicht auch nur ein Wichtigstes. Das gilt für jeden Einzelnen wie Organisationen. Ich nenne das den “Highlander”, weil es nur einen geben kann, einen wichtigsten Zielpunkt, auf den man zusteuert. Ist der erreicht, dann gibt es einen neuen usw. Was der Highlander-Zielpunkt ist, in welcher Entfernung er liegt… das ist einerlei. Gewiss ist jedoch, dass er nicht erreicht wird, wenn man sich ihm nicht konsequent Schritt für Schritt nähert. Das bedeutet für mich: an jedem Tag muss dem Highlander mindestens 1 Stunde gewidmet werden. Eine Stunde konzentrierte Arbeit für das wichtigste strategische Ziel sorgt dafür, dass die Verlässlichkeit extrem steigt.
  • Tagesgeschäft: Wenn Strategie, Lernen und Reflexion bedient sind, kann die restliche Arbeitszeit mit dem Tagesgeschäft gefüllt werden. Das gibt es und es wird bleiben. Aber es muss in seine Schranken verwiesen werden.

Es mag sich viel anhören, mehr als 25% der Arbeitszeit auf “so softes Zeugs” zu verwenden. Jahre der Beratungspraxis und Jahre der persönlichen Beobachtung meiner Selbstständigkeit haben mich jedoch zu der Einsicht gebracht: weniger geht nicht.

Weniger mag kurzfristig mal funktionieren. So wie man auch mal 100m sprinten kann und dabei das Atmen vergisst. Aber mittel- und langfristig ist weniger zu wenig. Wenig bedeutet Umherirren oder gar Stehenbleiben. Weniger erzeugt über kurz oder lang Schmerzen.

Das ist wie mit dem eigenen Körper: Nach einem strammen Spaziergang, ist es ok, die Beine hochzulegen. Aber wer 3 Wochen im Sessel verweilt, der entwickelt alle möglichen Probleme von Sehnenverkürzung über Muskelatrophie bis Dekubitus.

Natürlich stellt sich eine solche Arbeitszeiteinteilung nicht einfach so ein. Ein Poster auf dem Flur und eine markige Ansprache unter dem Motto “Wir wollen jetzt eine lernende Organisation werden!” sind nicht genug. Es reicht auch nicht, die Zeiträume für Reflexion, Lernen und Strategisches zuzugestehen. Das ist nur Förderung. Die ist notwendig, aber nicht hinreichend. Dazu muss Forderung kommen. Reflexion, Lernen und strategische Arbeit müssen eingefordert werden. Und das ist eine Aufgabe für das Management – sogar zunächst eine strategische.

Montag, 10. März 2014

Attrappen gestütztes Nachdenken

Wie viel Design vor dem Codieren darf es denn sein? Diese Frage erhitzt immer wieder die Gemüter. Neulich auch das von Robert C. Martin. Der reagierte nämlich sehr barsch auf einen Blogartikel von Justin Searl.

Martin sieht nun einen Unterschied in der Notwendigkeit zu entwerfen zwischen größeren Strukturen und kleineren. Für die einen sollte man explizit entwerfen, für die anderen sich durch TDD treiben lassen. Ich allerdings erlaube mir anderer Meinung zu sein. Für mich gibt es keine wie von Martin beschriebene Diskontinuität. Vielmehr sehe ich Software als selbstähnliche Struktur, die deshalb auf allen Ebenen auch ähnlich behandelt werden will. Ausführlicher erkläre ich das ein einem englischen Blogartikel.

Damit sei das Thema erledigt – doch dann ließ mich der Artikel von Searl nicht recht los. Der beschreibt nämlich einen TDD-Ansatz, den Searl für mindestens didaktisch günstiger hält als “den traditionellen”.

Schon beim ersten Lesen flog mich da eine Ähnlichkeit zu Flow-Design an, doch ich konnte sie noch nicht recht greifen. Als mir jedoch die Mock-Frameworks TypeMock Isolator und JustMock einfielen, habe ich mich darangesetzt, und Searls Vorschlag ausprobiert. Das Ergebnis hat mir sehr gefallen.

Schon lange setze ich keine Mock-Frameworks mehr ein, weil die Zahl der Attrappen zum Test meiner Flow-Designs klein ist. Für noch ausgefeiltere Mock-Frameworks wie die beiden hatte ich deshalb schon gar keinen Bedarf. Doch jetzt finde ich sie sehr nützlich. Lange hat das Profiler-gestützte Mocking auf einen Einsatzzweck bei mir gewartet, nun ist er da: mit JustMock kann ich Flow-Designs schneller in Code übersetzen – und das top-down.

Wie ich mir das denke, habe ich in einem längeren englischen Blogartikel beschrieben. Der ist als Dialog abgefasst, weil er eine Herangehensweise an TDD beschreibt – wie weiland Martin es getan hat.

image

Den Dialog zu schreiben, hat Spaß gemacht. Das war mal ein ganz anderes Format als sonst. Doch, ja, ich gebe zu, er ist ein bisschen lang und gewunden geworden. Jedenfalls für den normalen Leser im Web, der schnell, schnell Informationen sammeln will.

Deshalb habe ich das Vorgehen in einem englischen Folgeartikel nochmal systematischer beschrieben. “Informed TDD” habe ich diese Herangehensweise genannt, weil hier TDD nicht “blind” aufgrund von Testfällen betrieben wird, sondern geleitet durch ein entwerfendes Nachdenken.

image

Ich verstehe, wenn manchem der Entwurf am Flipchart zu theoretisch ist. Zwar halte ich das für eine Gefühl, das sich mit etwas Übung überkommen lässt – doch erstmal ist es halt so. Mit “Informed TDD” kann hier jedoch schneller abgeholfen werden: Das Nachdenken kann kürzer ausfallen, weil es das Problem zunächst weniger tief durchdringen muss. Schneller kann man zur Tastatur greifen und schonmal Code schreiben, der das Nachdenken verifiziert. Schrittweise werden die durch “hartes TDD” zu lösenden Probleme auf diese Weise kleiner.

Attrappen stützen also das Nachdenken. Und das ganz modern ohne spezielle Vorkehrungen für eine Injektion von Funktionalität.

Samstag, 1. März 2014

Vertragsstrafe einmal anders

imageWer einen Vertrag verletzt, der wird bestraft – auf die eine oder andere Weise. Ohne Konsequenzen wären Verträge so nützlich, wie elterliche Ermahnungen an schreiende Kinder vor dem Süßigkeitenregal im Supermarkt, wenn am Ende doch der Schokoriegel gekauft wird, damit endlich, endlich Ruhe ist.

Ob Verträge schriftlich sind oder nicht, ist unerheblich. Sie entstehen schon durch eine mündlichen Abrede über Leistung und Gegenleistung.

Soweit alles ganz normal und grundsätzlich nützlich. “Einklagbare” Verträge sind ein Fundament unserer Zivilisation seit Jahrhunderten. Schon die Römer sagten: pacta sunt servanda.

Wie jedes System kann aber auch dieses pervertieren. Dann tritt der eigentliche Zweck in den Hintergrund. Der Vertrag wird dann zu einer Art Ersatzbefriedigung – und mit der Zeit zu einem Suchtmittel. Das scheint mit zunehmend der Fall.

Unsicherheit herrscht allerorten. Wie wird die Zukunft? Kann man der anderen Seite vertrauen? Das sind Fragen, die alle Parteien im Geschäftsleben ständig umtreiben. Die Lösung scheint dann in wasserdichten schriftlichen Verträgen zu liegen. Ha! Damit hat man dann alles im Griff. Vor allem die Gegenseite. Die muss dann liefern. Und wenn nicht, dann setzt es was.

Was für eine Illusion! Was für eine Behinderung!

Wie gesagt, in Maßen eingesetzt, helfen explizite Verträge zu klären. Aber was ich in letzter Zeit erlebt habe, sprengt aus meiner Sicht dieses sinnige Maß.

Allerorten werden mit Geheimhaltungsverträge vorgelegt, nur weil ich ein inhouse Training mache. Immer wieder aber sind es auch Verträge über eine Trainingsmaßnahme oder einen Beratungsauftrag. 5, gar 10 Seiten mittelgroß beschrieben gilt es dann zu prüfen. Denn die Arbeit einer Rechtsabteilung eines Kunden kann ich ja nicht in treuem Glauben einfach so unterzeichnen. Solche Verträge werden ja nicht mit mir schrittweise ausgehandelt, sondern mir vorgesetzt. Also muss ich sie zuerst verstehen, dann ggf. nachverhandeln. Das kostet mich nicht nur Mühe – das ist auch ganz grundsätzlich ohne Sinn und Verstand.

Denn worüber reden wir hier? Über einen Rüstungsauftrag? Über Millionenprojekte?

Nein, wir reden über sehr persönliche Beziehungen zwischen Kunden und mir. Mein Arsch ist immer in der Schusslinie. Das bedeutet: Wenn ich Mist baue, dann bin ich raus. Das ist die immer drohende Konsequenz bei meinen Einsätzen. Schon deshalb bemühe ich mich, einen guten Job zu machen. Aber natürlich auch noch aus anderen Gründen.

Da ich keine Rechtsabteilung als “eh da”-Kosten in meinem Budget habe, empfinde ich diese Verträge als zunehmend belastend. Konzerne (und auch kleinere Unternehmen) versuchen damit eine bürokratische Pseudosicherheit herzustellen, die nichts, aber auch gar nichts zur Sache – z.B. Clean Code oder Teamoptimierung – beiträgt.

Und deshalb ist nun Schluss damit. Nicht nur Datenkraken greifen um sich, sondern auch Vertrags- und Bürokratiekraken. Das nehme ich nicht länger hin.

Verändern kann ich diese Unternehmen natürlich nicht direkt. Aber ich kann mit ihnen reden. Manchmal hilft das schon: Wenn ein Geschäftspartner von Vertrag spricht, dann sage ich “Nein, danke. Ich brauche keinen.” Ein solches Beispiel ist developer media, mit denen ich ein Seminar zum Thema Softwarearchitektur und zusammen mit Andrea Kaden eines zum Thema Zeitmanagement mache.

Dort wollte man mir zum Abschluss der Planungsgespräche einen Vertrag schicken – und ich habe Nein gesagt. Das fand man völlig ok. Sehr schön. Interessanterweise gab man dann auf Nachfrage an, dass insbesondere junge Trainer einen Vertrag wollten. Das hat mich gewundert. Ich hatte gedacht, dass junge Menschen eher informell arbeiten wollen.

Was aber, wenn das Gespräch nichts nützt? Dann erhebe ich eine Vertragsunterzeichnungsgebühr von 300 EUR zzgl. MwSt pro schriftlichem Vertrag. Die ist leider nötig, weil ich Verträge ja auch meinem Rechtsanwalt vorlegen muss, um auf Augenhöhe mit dem Vertragspartner zu sein. Das ist doch verständlich, oder?

Und wenn nicht, dann darf man das gern auch als eine widerständige Reaktion sehen. Ich will mich einfach nicht jedem System anpassen müssen, das kontraproduktiv handelt. Mir fehlt schlicht das Vertrauen, dass so eine Maßnahme wirklich, wirklich wichtig und zu beiderseitigem (!) Vorteil ist. Bis zum Beweis des Gegenteils sind solche Verträge, wie sie mir in meiner Arbeit begegnen, parasitäre Erscheinungen von Subsystemen – Rechtsabteilung, Einkauf, Geschäftsleitung… –, die über das Ziel hinausschießen. Da geht es nicht mehr um eine sinnvolle Klärung, sondern platt ums “Arsch absichern”.

Gerade erst habe ich von einem Fall gehört, wo ein externer Trainer einmal etwas über ein Unternehmen “ausgeplaudert” hat – und das den Weg in die falschen Ohren gefunden hat. Da war es vorbei mit der Ungezwungenheit. Fortan müssen nun alle externen Trainer 3 Seiten Geheimhaltungsvereinbarung unterschreiben.

Und was bringt die? Nichts. Durch die 3 Seiten wird niemand ein besseres Gedächtnis bekommen, um sich zu erinnern, was er nicht ausplaudern sollte. Niemand bekommt einen besseren Maßstab für sensible Daten. Vor allem aber enthält die Vereinbarung keine (!) Konsequenzen bei Zuwiderhandlung. Jedenfalls keine jenseits dessen, was ja ohnehin passieren würde: die Aufkündigung der Zusammenarbeit.

Nein, ich will die Pseudosicherheit von Verträgen nicht länger unterstützen. Als Signal “an das System” sende ich deshalb etwas, das Unternehmen verstehen: Kosten. Wer Verträge will, bekommt sie – muss dafür aber bezahlen. Dann kann sich “das System” überlegen, ob es sich lohnt, die Pseudosicherheit aufrecht zu erhalten.

Montag, 13. Januar 2014

Rekursive Produktivität

Das drängendste Problem der Softwareentwicklung heute scheint mir Unzuverlässigkeit. Darin unterscheidet sie sich nicht von der Deutschen Bahn. Nicht Performance oder Skalierbarkeit oder Sicherheit oder Usability oder ein Mangel an Kunststücken sind das Problem. Allermeistens kann Technologie das, was gebraucht wird, um die nicht-funktionalen Anforderungen zu erfüllen. Das war vor 20-30 Jahren noch anders.

Nein, heute hapert es bei der Lieferung. Sie ist unzuverlässig, weil wir knietief im Brownfield waten. Sie ist unzuverlässig, weil der Herstellungsprozess unsystematisch ist. Es mangelt an Evolvierbarkeit und Produktionseffizienz.

Auch wenn ich mich viel und gern mit Evolvierbarkeit beschäftige, glaube ich jedoch, dass die Produktionseffizienz zuerst angegangen werden muss. Denn ohne ein systematisches Vorgehen gibt es auch keine Verlässlichkeit für Maßnahmen zur Erhöhung der Evolvierbarkeit.

Und wie die Produktionseffizienz steigern? Klar, mit der Einführung von Agilität! Leider ist das aber nicht so einfach. Teams und Unternehmen können nicht einfach einen Schalter umlegen und schon wird agil gearbeitet. Bei aller Einsicht und gutem Willen der Organisationen ist das auch sehr verständlich: Wie soll denn eine solche Veränderung verlässlich durchgeführt werden, wenn Verlässlichkeit das Grundproblem ist?

Die Einführung agiler Vorgehensweise versandet bzw. scheitert so oft, weil es an einem Meta-Prozess fehlt. Wer das Lernen verlernt hat, der hat es schwer, ein lernendes Vorgehen zu erlernen. Ist doch klar.

Zumindest in Scrum steckt zwar etwas von dieser Meta-Ebene: die Retrospektive. Doch die kommt mir dort wie ein Anhängsel vor. Andere Aspekte sind klarer formuliert. Und vor allem ist die Retrospektive in dem Prozess, der eingeführt werden soll, und nicht vor oder über ihm. Scrum kommt ohne Bootstrap.

Aber nicht nur auf der Meta-Ebene fehlt mir etwas. Am anderen Ende hapert es auch: bei der Verlässlichkeit jedes einzelnen. Die ganz persönliche Zuverlässigkeit ist oft mangelhaft. Joel Spolsky hat empfohlen, nach Bewerber nach zwei Kriterien auszuwählen: smart + gets things done. Mir scheint, das zweite Kriterium wird nur selten angewandt.

Bitte verstehen Sie mich recht: Überall wird fleißig, fleißig gearbeitet. Man bemüht sich redlich wegzuschaffen, was da täglich an Aufgaben auf den Schreibtisch schneit. Alle legen sich ins Zeug. An Einsatzfreude (bis zur Selbstaufgabe) habe ich es ganz selten mangeln sehen. Doch guter Wille allein führt ganz offensichtlich nicht zu Verlässlichkeit. Im Kleinen fehlt mithin die Grundlage für erfolgreiche Veränderungen.

Über die Gründe für diese Misere will ich hier nicht lange spekulieren. Vielmehr möchte ich mir Gedanken machen, wie sich daran etwas ändern ließe. Meine derzeitige Vorstellung: Wir müssen die Softwareentwicklung weiter von romantischen Vorstellungen befreien. Wir müssen genauer hinsehen. Wir müssen eine Bild dafür entwickeln, wie Softwareherstellung ganz fundamental als Prozess funktioniert.

Aber nun genug der Vorrede. Hier mein Ansatzpunkt:

Der Prozessor

Ich glaube, wir müssen uns leidenschaftslos als Prozessoren verstehen. Wir alle sind Informations- bzw. Materialprozessoren. Ständig, nicht nur bei der Arbeit. Aber auf die will ich mich hier konzentrieren.

Jeder Beteiligte an der Softwareherstellung ist dazu da, Input in Output zu verwandeln:

image

Anforderungen sollen in Code übersetzt werden. Die Kollegin bittet um Hilfe mit ein paar Screenshots. Der Vertrieb ruft an und möchte Auskunft über den Stand der Entwicklung. Tausenderlei Dinge sind zu erledigen. Aufgaben prasseln aus allen Richtungen auf uns ein.

Und das geht jedem so. Sie und ich sind nicht allein. Wir sind vielmehr in einem Netz von Aufgabenflüssen aufgehängt.

image

Manche Aufgaben fließen von außen in dieses Netzwerk ein. Andere entstehen erst im Netzwerk während der Erledigung solcher Aufgaben. Insofern entstehen manche Aufgaben auch in uns für uns.

So ist das: Wir sind “nur” Prozessoren in einem Netzwerk. Aber waren wir das nicht immer schon? Klar. Doch etwas hat sich verändert: Früher war das Netzwerk nicht so engmaschig. Früher waren wir getrennter von einander, weil es an Kommunikationswegen mangelte.

Heute ist jeder jederzeit erreichbar. Technisch ist das möglich. Und zusätzlich will heute auch noch jeder jederzeit erreichbar sein – oder muss. Das bedeutet, die Zahl der Einflüsse im wahrsten Sinn des Wortes, d.h. dessen, was wann in uns einfließen kann, ist explodiert.

Demgegenüber hat sich jedoch eines nicht verändert: Wie wir grundsätzlich funktionieren. Wir sind dieselben geblieben. Wir können immer noch nur eine Sache zur Zeit erledigen. Uns sind keine Prozessorkerne zugewachsen. Unsere Aufmerksamkeit ist begrenzt in Breite und Dauer. Auch wenn wir Prozessoren sind, sind wir doch keine Maschinen.

Wir können zwischen verschiedenen Aufgaben nicht so schnell Umschalten wie eine CPU. Je häufiger wir umschalten, desto größer der Umschaltaufwand. Und je häufiger wir umschalten, desto geringer die Qualität unserer Transformationen.

Ich denke, das wissen sie aus eigener Erfahrung.

Systematische Transformation

Wie nun angesichts dieser Begrenzungen transformieren? Das ist ganz einfach und hat sich in den letzten 5.000 Jahren wohl nicht verändert: konzentriert eins nach dem anderen.

Kein Strampeln und Schreien ändert daran etwas. So funktionieren wir einfach. Das ist eine Gesetzmäßigkeit wie die Gravitation oder der zweite Hauptsatz der Thermodynamik. Wir müssen uns damit arrangieren. All unsere Arbeit muss sich danach ausrichten.

Es ist so einfach – und doch so schwierig. Ich weiß. Jeden Tag ringe ich ja auch damit. Seit ich mich aber bemühe, die Situation systematischer zu betrachten, gelingt es mir immer besser. Früher ist der Mensch ja auch nicht geflogen – aber seit er sich systematisch mit den Naturgesetzen auseinandersetzt, haben wir es in dieser Hinsicht weit gebracht, würde ich sagen. So glaube ich daran, dann es auch unsere Produktivität beflügelt, wenn wir uns systematischer damit befassen.

Also: Als Prozessor können wir uns nur mit 1 Aufgabe zur Zeit befassen. Das ist die aktuelle Aufgabe. Darüber hinaus gibt es aber noch eine ganze Reihe weiterer Aufgaben, die auf unsere Aufmerksamkeit warten, um erledigt zu werden. Ständig kommen darüber hinaus neue hinzu. Und alle haben eine unterschiedliche Priorität und womöglich unbekannte Größe.

Ob wir uns überlastet fühlen oder nicht, hängt u.a. davon ab, ob Aufgaben schneller einfließen als Transformationsergebnisse ausfließen.

image

Die minimale Systematik besteht nun darin, denke ich, unsere Begrenzungen zu honorieren und nicht bei Eintreffen einer neuen Aufgabe die Bearbeitung der aktuellen zu unterbrechen.

Ja, das meine ich so: Lassen Sie sich nicht mehr unterbrechen!

Unterbrechungen sind das Grundübel heutiger Unproduktivität von “Knowledgeworkern”. Je mehr Teams ich sehe, je genauer ich auf meine eigene Arbeitsweise achte, desto klarer wird mir das.

Das Ziel muss lauten:

Zero Interrupts! Zero Notifications!

Was kann denn wichtiger sein, als dass Sie die aktuelle Aufgabe zuende führen?

Sie mögen einwenden, dass immer etwas Wichtigeres auf Sie zuströmen könnte. Denn was, wenn der Kunde nicht mit Ihrer Software arbeiten kann, wenn dort ein Fehler jede Minute viel Geld kostet? Sie haben Recht, dann muss sofort gehandelt werden. Aber: Müssen wirklich Sie handeln – oder gibt es dafür nicht vielmehr einen “Notfallprozessor”? Und wie oft tritt dieser Fall ein? Einmal im Monat? Dann müssen wir nicht darüber reden, denn mir geht es um das übliche Tagesgeschäft. Wir sollten uns nicht durch Sonderfälle davon abhalten lassen, für den Normalfall eine Systematik zu finden. Wenn wir die haben, dann können wir innerhalb derer auch Sonderfälle abarbeiten.

Wenn es nun keine Unterbrechungen – externe und selbst erzeugte – mehr gibt, hat das zweierlei zur Folge:

  • Wir brauchen einen Puffer (aka Warteschlange), in die neue Aufgaben einfließen, während wir noch mit der aktuellen beschäftigt sind.
  • Wir brauchen einen Mechanismus, um in Balance zu bleiben. Wir sind ja nicht allein, sondern brauchen andere, wie sie uns brauchen. Wir dürfen uns also nicht isolieren. Eine gewisse “responsiveness” ist nötig.

Der Puffer entkoppelt uns von anderen Prozessoren. In ihn schieben (push) die (oder wir selbst) Aufgaben hinein. Das stört uns aber gar nicht oder nicht sehr in unserer Konzentration. Wir arbeiten unsere aktuelle Aufgabe ruhig ab. Erst wenn wir damit fertig sind, entnehmen wir unserem Puffer eine neue (pull).

image

Das Ergebnis unserer Transformation schieben wir natürlich in den Puffer eines anderen Prozessors. Das mag der sein, von dem wir eine Aufgabe bekommen haben, oder ein anderer.

image

Das sieht doch schon ordentlicher aus, oder? Das Netzwerk ist zwar nicht weniger verwoben – wir werden aber nicht mehr von den fließenden Aufgaben überflutet. Sie laufen jetzt in das Auffangbecken unserer Puffer.

Manchmal gibt es dabei “Aufgabenkaskaden” im Rahmen von offiziellen Prozessen, z.B. dem Softwareentwicklungsprozess der vom Kundenwunsch bis zum Release reicht. Manchmal geht es aber auch nur um informelle Dialoge zwischen zwei Prozessoren, sozusagen ad hoc Microprozesse.

image

Wie nun die Aufgaben im Puffer priorisiert werden, lasse ich hier mal dahingestellt. In jedem Fall steht die jeweils dringlichste Aufgabe deutlich sichtbar darin. Ihr widmen wir uns, wenn wir wieder Zeit haben.

Und wann haben wir wieder Zeit? Eigentlich erst, wenn wir die aktuelle Aufgabe fertiggestellt haben. Wenn das jedoch Stunden, Tage, Wochen dauern sollte… dann dürfen wir nicht so lange von der Bildfläche verschwinden. Außerdem können wir womöglich gar nicht so lange konzentriert an einer Aufgabe arbeiten. Unsere Aufmerksamkeitsspanne ist begrenzt. Oder wir müssen auf Input warten, ohne den wir nicht weiterarbeiten können.

Es ergeben sich also aus unseren eigenen Begrenzungen bzw. aus den Aufgaben selbst durchaus Unterbrechungspunkte, gegen die wir nichts tun können. Die Konzentrationsfähigkeit scheint mir z.B. bei 30-45 Minuten und bei 90-120 Minuten natürliche Grenzen zu haben. Warum das nicht nutzen, um in Kontakt zu bleiben mit unserer Umwelt? Wir können ganz regelmäßig und damit verlässlich unseren Puffer durchsehen, ob etwas Dringenderes als die aktuelle Aufgabe unserer Aufmerksamkeit bedarf. Richten Sie es daher am besten so ein, dass Sie nur 1 Puffer haben. Dann gewinnen Sie am schnellsten Überblick über die wartenden Aufgaben.

Unvermeidliche Unterbrechungen können wir nutzen, um für andere direkt (synchron) ansprechbar zu bleiben. Ein Kollege, der sie gestern noch mit einer längeren Problemklärung unterbrochen hat, ist morgen sehr wahrscheinlich bereit, auf Ihre nächste “Sprechzeit” zu warten. Denn die ist im Mittel nur vielleicht 20 oder 60 Minuten entfernt. So lange können die allermeisten Themen warten.

Denken Sie daran: Zero Interruptions!

Dasselbe gilt auch für Emails, Chat (Skype, Whatsapp), Twitter, Facebook, Newsgroups, RSS-Feeds und was der Social Media mehr sind. Das alles kann eine Stunde oder gar länger warten. Ihre Aufgabe ist die konzentrierte, weil schnellstmögliche und bestmögliche Abarbeitung von Aufgabe, nicht die Verarbeitung von Notifikationen. Aufnahme und Einordnung neuer Aufgaben darf nur einen Bruchteil Ihrer Zeit verzehren.

Deshalb denken Sie auch daran: Zero Notifications!

Ziehen Sie sich Informationen/Aufgaben, wenn Sie bereit dafür sind. Das gilt für elektronische wie menschliche Quellen.

Was nun, wenn Sie eine Aufgabe noch nicht abgeschlossen haben, aber eine andere höhere Priorität hat? Dann können Sie nach einem natürlichen bzw. unvermeidlichen Unterbrechungspunkt die Aufgabe wechseln. Seien Sie sich allerdings bewusst, dass Sie damit ein Stück unverlässlich gegenüber der nun unterbrochenen Aufgabe werden. Sie sollten deshalb die Zahl der Aufgaben “on hold” begrenzen.

image

Haben Sie nie mehr als vielleicht 2 oder vielleicht 3 Aufgaben in Arbeit, d.h. begonnen (aus dem Puffer entnommen), aber noch nicht abgeschlossen. Das könnte eine sehr kleine für zwischendurch sein (ein Anruf), eine, an der sie danach aktiv weiterarbeiten, und eine, bei der Sie auf einen Input zur Weiterarbeit warten müssen.

Tun Sie sich diesen Gefallen der Work-in-Progress Limitierung. Sie werden entspannter arbeiten, sie werden verlässlicher liefern. Ihre Kollegen werden es Ihnen also auch danken – früher oder später.

Gleichfalls sollten Sie die Zahl der Aufgaben in Ihrem Puffer begrenzen. Von außen ist nämlich nicht immer einfach zu unterscheiden, ob Sie schon mit einer Aufgabe angefangen haben oder ob sie noch unbearbeitet im Puffer liegt. Für andere Prozessoren gilt eine Aufgabe als übergeben, wenn Sie im Puffer liegt.

Wenn Sie jedoch den Puffer begrenzen, dann können von anderen Prozessoren keine Aufgaben mehr darin abgelegt werden. Bzw. Sie können keine mehr annehmen und dort ablegen. Sie machen dann dicht – und üben sog. back pressure aus. Aufgaben können aus anderen Prozessoren nicht mehr zu ihnen weiter-/abfließen und müssen dort on hold gehen. Damit steigt deren WIP usw.

Das hört sich negativ an – aber für wen? Für Sie? Für den anderen Prozessor? Für das Gesamtsystem oder den Kunden?

Tatsächlich ist das jedoch kein Bug, sondern ein Feature solcher Systematik. Anders kann das Gesamtsystem – Team, Abteilung, Unternehmen – nämlich nur schwer bemerken, wann Überlastung eintritt. Solange Sie zu Unterbrechungen Ja sagen, solange Sie grenzenlos Aufgaben annehmen, scheint alles zu klappen – nur dass es zu mysteriösen Unzuverlässigkeiten und Qualitätsmängeln kommt. Und das, wo doch alle unter Hochdruck mit bestem Willen arbeiten.

Was ich hier empfehle, ist nichts anderes als so etwas wie Personal Kanban + Pomodoro Technique. Werden Sie zum preemptive multitasking Prozessor mit WIP Limit :-)

Ja, ohne ein gewisses Maß an Multitasking geht es nicht. Damit meine ich nicht, dass Sie während des Einparkens telefonieren und simsen sollen ;-) Das funktioniert nicht. Aber 2-3 verschiedene Aufgaben, zwischen denen wir im Verlaufe eines Tages springen, halten wir schon aus. Ohne geht es auch nicht, sondern isolieren wir uns zu stark von anderen. Und ich denke sogar, eine gewisse Vielfalt ist sogar bekömmlich. Ein Anruf zwischendurch macht auch mal den Kopf frei vom Bug Fixing. Eine Präsentation kann davon profitieren, zwischendurch mal eine technische Frage zu beantworten. Usw.

Hier ein Ausschnitt aus meinem Personal Kanban Brett bei leankit.com:

image

Links die Spalte für meinen Puffer. In der Mitte eine Aufgabe in Arbeit und eine kontinuierliche “Hintergrundaufgabe”, die mich jeden Tag ein paar Minuten kostet. Rechts das, was ich schon erledigt habe. Das blende ich jedoch meistens aus. Was interessieren mich meine Aufgaben von gestern? ;-)

An der aktuellen Aufgabe arbeite ich konzentriert: ununterbrochen, unnotifiziert. Zumindest, bis ich merke, dass meine Konzentration sinkt oder meine Pausenzeit erreicht ist. Dann wechsle ich mit meiner Aufmerksamkeit. Vielleicht schaue ich für ein paar Minuten Emails durch und trage neue Aufgaben in meinen Puffer ein. Vielleicht lese ich einen Artikel oder gehe Essen. Anschließend weiter mit meiner einen aktuellen Aufgabe.

So kriege ich wirklich was gebacken. Für mich und andere zufriedenstellend und verlässlich. Das Brett ist ein Fokussierungswerkzeug für mich. Gegenüber anderen ist es aber auch ein Rechtfertigungswerkzeug. Wenn ich nämlich dieses Brett mit seinem Füllstand von Puffer (linke Spalte) und Prozessor (mittlere Spalte oben) zeige, dann wird anderen schnell begreifbar, dass auch ich nur begrenzte Kapazität habe. Neue Aufgaben können also nicht einfach sofort begonnen werden. Manchmal sind sogar schon gepufferte Aufgaben zu entfernen zugunsten neuer – ein Preis, den ein Auftraggeber zu zahlen bereit sein muss.

Aber ich will mich hier auch nicht in Details des Umgangs mit so einem “Zeitmanagementbrett” ergehen. Mir war es erst einmal wichtig, Ihnen die Grundpfeiler für mehr persönliche Abarbeitungsverlässlichkeit vorzustellen. Jetzt möchte ich lieber das ganze skalieren…

Das Team als Multiprozessor

Was für uns alle persönlich gilt, gilt auch für ein Team: es ist ein Prozessor, der Input in Output transformieren soll.

image

Insofern gilt für das Team dasselbe wie für Sie: es braucht einen Puffer und Limits. Sonst kann es nicht verlässlich arbeiten. Sonst kann es dem Gesamtsystem nicht anzeigen, wenn es überlastet ist.

image

Organisationen sind also rekursiv. Als Ganzes, in Teilen und auf Ebene des einzelnen Mitarbeiters geht es um Prozessoren, die besser arbeiten, wenn man sie nicht unterbricht. Unzuverlässigkeit kann sich auf jeder Ebene einstellen – und tut das regelmäßig. Deshalb ist eine systematische Betrachtung so wichtig. Verlässlichkeit ist kein Zufall und nichts Softes, Zwischenmenschliches. Sie ergibt sich nicht aus gutem Willen. Ich würde sogar sagen: guter Wille ist oft ihr Gegner. Denn guter Wille (im Verein mit seiner dunklen Schwester Angst) ist begrenzungslos – bis eine physische Grenze erreicht ist.

image

Team und Unternehmen als Prozessoren sind nicht atomar. Das heißt, es können grundsätzlich Aufgaben parallel verarbeitet werden. Es treten mithin Prozesse deutlich in den Blick, d.h. die Transformation über mehrere Schritte hinweg. Dafür werden Unternehmen ja auch gegründet: um etwas in Zusammenarbeit mit niedrigeren (Transaktions)Kosten als ein Markt herzustellen.

Der Hauptprozess der Softwareentwicklung sieht dabei so aus:

image

Wobei jeder Produktionsschritt mit einem oder mehreren “Mitarbeiterprozessoren” besetzt sein kann, die dann wieder in gleicher Weise mit Puffer und WIP-Limit organisiert sind.

Jetzt verstehen Sie vielleicht besser, warum ich glaube, dass es sehr schwer ist, verlässlich ein neues Vorgehensmodell oder sonst eine Veränderung einzuführen. Solange nämlich nicht dieses Grundorganisationsprinzip verstanden ist, ist jegliche Maßnahme auf den Zufall angewiesen. Verlässlichkeit existiert ja nicht einmal auf der untersten Ebene. Wie soll sie da auf höheren Ebenen entstehen?

Zum Glück gelten auf jeder Ebene dieselben Gesetzmäßigkeiten. Es muss also nur einmal für alle Ebenen diese Systematik verstanden werden.

Der Rest ist dann Feinheit :-) Nein, leider nicht. Dann beginnt erst die Arbeit. Nämlich die an der Justierung der Puffer und Limits. Aber das ist eine Geschichte für ein anderes Mal :-) Darüber gibt es viel Literatur. Stichworte sind Theory of Constraints, Lean Production/Development, Kanban, Queueingtheorie usw.

Allen liegt jedoch derselbe Gedanke zugrunde: Dass wir alle auf vielen Ebenen in vernetzten Prozessen arbeiten. Und dass wir deshalb diese Prozesse möglichst sichtbar machen sollten. Denn sonst haben wir es schwer, sie zu verbessern.

Freitag, 3. Januar 2014

Eklektische Programmierung

Jetzt hab ich genug. Mir hängt das ganze Gerede über Für und Wider von Objektorientierter Programmierung (OOP) und Funktionaler Programmierung (FP) zum Hals raus. Ich mag nicht mehr.

Es ist zwar nicht egal, ob OOP oder FP. Der eine Ansatz hat für manche Szenarien Stärken, der andere Ansatz für manche Szenarien Stärken. Und? Warum sollte ich mich deshalb entscheiden müssen? Warum sollte OOP gewinnen, warum FP die Welt erobern? Das ist doch alles Quatsch. Solche Überlegungen binden geistige Kapazität, die wir besser einsetzen können.

Es geht nicht um die Frage, ob OOP oder FP. Es geht nicht um entweder-oder. Es gibt keinen Grund, warum es nicht ein sowohl-als-auch geben sollte.

Und schon gar nicht geht es um eine bestimmte Programmiersprache. Vorgestern Java, gestern C#, Python, Ruby, nun Go, Clojure, Erlang, Elixir – und natürlich gestern wie heute JavaScript? Gott ist das langweilig.

Ich mag mich nicht mehr entscheiden müssen. Ich will beides: OOP + FP. Das ist die Frage, die ich an Sprachen in Zukunft stellen werden: Kannst du mir volle OOP-Power geben und (!) kannst du mir volle FP-Power geben? [1]

Deshalb beschäftige ich mich gerade auch mit F#. Das ist eine hybride Sprache, allerdings geboren aus der FP. Da kommt für mich vieles eklektisch zusammen. Ich kann z.B. einen Stack à la FP implementieren und nutzen:

image

Oder ich kann ihn à la OOP definieren und nutzen:

image

Das sieht dann ähnlich einer Implementation in C# aus – ist nur etwas knapper formuliert, weil F# Typinferenz und eine leichtgewichtigere Syntax bietet. Hier zum Vergleich C#:

image

Oder ich kann in F# Objekte aus C# (bzw. aus .NET Assemblies) nutzen – und umgekehrt.

Mit F# muss ich mich nicht mehr entscheiden. Ich habe die volle Power von OOP und FP “at my fingertips”.

Nun kann ich frei überlegen, wann ich welchem Paradigma den Vorzug gebe. Ist ein Stack besser mit FP- oder OOP-Mitteln implementiert? Wie steht es mit der Logik für ein Spiel? Wie steht es mit einem View Model? Wie mit einem EventStore? Wie mit dem Domänendatenmodell?

An den Grenzen meines Codes stoße ich dann allerdings auf Infrastruktur. Mit der muss ich mich arrangieren, die präsentiert sich mir in Form von APIs. Natürlich muss meine Sprache mir den Zugriff erlauben.

Und ansonsten… Freiheit!

Denn erst wenn wir beide Paradigmen gleichwertig zur Verfügung haben, können wir zum Wesentlichen kommen: Was denn in welchem Fall der geeignete Ansatz sei.

Solange Sprachen noch beim einen oder anderen Paradigma zurückstehen, verlieren wir uns schnell in Rechtfertigungen. Dann ist das kein Defizit, sondern ein Feature, weil das andere Paradigma es einfach nicht bringt.

Doch das ist Quatsch. Die Frage nach dem richtigen, wichtigen, seligmachenden Paradigma ist die falsche Frage. Nicht das eine oder das andere Paradigma ist seligmachend, sondern die Vielfalt. Pluralismus statt Monokultur.

Ich will eklektisch programmieren, d.h. mich aus einem Bauchladen bedienen. Was mir taugt, wird benutzt. Fertig.

imageDas mag Lernaufwand für mich bedeuten. Ok, dann wende ich den eben auf. So wie ich es gerade mit F# tue und in einem Buch dokumentiere: F# lernen Kata für Kata. (Damit mache ich es Ihnen dann vielleicht ein wenig leichter, wenn Sie sich auch für die eklektische Programmierung entscheiden.)

Lernaufwand zur Ermöglichung von Eklektizismus ist Aufwand. Aber Rechtfertigungen für das eine oder andere Paradigma und Workarounds, wo es eben nicht optimal passt, Sie jedoch darauf festgenagelt sind… das ist auch Aufwand. Und zwar kein unbeträchtlicher.

Klar, C# bietet schon einiges in Richtung FP. Aber eine wirklich hybride Sprache ist C# noch nicht und wird es auch nicht. F# hingegen wurde mit dieser Absicht entworfen.

Für mich ist 2014 das Jahr, in dem ich meine eigenen Entwicklungen auf F# umstellen werde. Damit kann ich eklektisch arbeiten, bleibe dem .NET-Universum aber verbunden.

Wer mit Java arbeitet, der hat ähnliche Möglichkeiten. Scala und Clojure scheinen mir auch den hybriden Ansatz zu verfolgen. Für meinen Geschmack ist das JVM-Universum jedoch zu weit weg. Außerdem hat mir Scala einen Grandiositätsanspruch, der mich ermüdet. Und Clojure ist mir syntaktisch dann doch im Moment zu anders.

Wie gesagt, am Ende geht es auch nicht um einzelne Sprachen, sondern um Paradigmen. Wenn ich mich über Softwareentwurf unterhalten will, dann interessiert mich die konkrete Syntax nicht sonderlich. Wichtig ist vielmehr, dass mein Gegenüber Paradigmen und Konzepte zur Verfügung hat.

Soviel zu meinem Vorsatz für 2014: Eklektische Programmierung mit F#.

Und was ist Ihr Vorsatz?

PS: Achso, dynamische Programmierung (DP) will ich übrigens auch :-) Von der steckt in C# etwas drin; F# ist in der Hinsicht schwachbrüstiger. Derzeit ist mir jedoch mehr FP-Power wichtiger. Mit etwas weniger DP kann ich leben. Oder ich werde noch eklektischer: Ich wechsle nicht nur das Paradigma in einer Sprache, ich wechsle gleich zwischen den Sprachen. Da C# und F# auf der CLR/BCL laufen, muss ich mich nicht mal zwischen ihnen entscheiden.

Endnoten

[1] Ich ahne es, irgendwer wird fragen, was denn “volle Power” für die beiden Paradigmen ist. Und darüber lässt sich womöglich trefflich streiten. Aber ich denke, es gibt da einen gewissen Konsens. Zu OOP gehören Interfaces, Polymorphie, Kapselung von veränderbarem Zustand, einfache Vererbung. Zu FP gehören Funktionen als Werte & höhere Funktionen, tail recursion, unveränderbare Werte/Datenstrukturen, pattern matching.

Mittwoch, 1. Januar 2014

Unordnung muss sein

imageNeulich habe ich mit meiner Freundin geheimwerkert. Sie wollte ihr Wohnzimmer mit einigen Fotos in selbstgebastelten Bilderrahmen anreichern. Holzprofile zuschneiden und zusammensetzen zu Rahmen, war eine Sache. Eine andere, die Bilderleiste im Wohnzimmer anzubringen, an der die Rahmen aufgehängt werden können. (Eine Bilderleiste statt Nägeln in der Wand für jeden Rahmen sollte es sein, damit die Rahmen flexibler gehängt werden können.)

Bei der Montage der Bilderleiste habe ich dann eine Erkenntnis gehabt:

Unordnung ist bei Veränderungen nicht zu vermeiden.

Wer Rahmen bastelt, eine Bilderleiste anbringt, einen Weihnachtsbaum herrichtet, ja, sogar wer aufräumt, erzeugt Unordnung. Das ist nicht zu vermeiden. Auch wenn am Ende die Entropie niedriger sein soll, wird sie zunächst erhöht.

Hier das Wohnzimmer während der Arbeit an den Bilderleisten in seiner ganzen Unordnungspracht:

image

Die Sitzbank ist bis aufs Holz abgeräumt, der Wohnzimmertisch ein Werkzeuglager, der Sessel beiseitegeschoben und mit Krimskrams beladen, Staubsauger und Bohrmaschine lungern in der Gegend herum… Nein, das ist nicht die übliche niedrig-entropische Gemütlichkeit.

Am Ende jedoch, wenn die Veränderungen an der Wand abgeschlossen sind, kommt alles wieder an seinen Platz. Dann herrscht wieder Ordnung. (Dass die Bilderrahmen in unterschiedlicher Höhe und Orientierung hängen, gehört zu dieser Ordnung ;-)

image

Ohne die zwischenzeitliche Unordnung wäre die Veränderung nicht umsetzbar gewesen. Oder der Aufwand wäre viel, viel höher ausgefallen. Ich denke, da werden Sie mir zustimmen.

Wer einen ordentlichen Zustand in einen anderen, “erweiterten” ordentlichen Zustand überführen will, der erzeugt auf dem Weg dahin Unordnung.

Vorher hat das Wohnzimmer gewisse funktionale und nicht-funktionale Anforderungen erfüllt. Jetzt erfüllt es neue nicht-funktionale Anforderungen. Vorher war es ordentlich, jetzt ist es wieder ordentlich. Alles wunderbar.

Nur bei Quellcode oder anderen Artefakten der Softwareentwicklung soll das anders sein?

Merkwürdig, oder?

Was Unordnung bei Quellcode genau ist, sei mal dahingestellt. Aber dass es Unordnung geben kann, nein, geben muss, sollte außer Zweifel stehen. Auch für einen Laien.

Und genauso sollte außer Zweifel stehen, dass eine Veränderung an Quellcode zu Unordnung führen muss. Zwangsläufig. Immer.

Zumindest halte ich das für absolut einsichtig unter der Voraussetzung, dass Quellcode nach erfolgreichem Abschluss von Veränderungen, ordentlich zurückgelassen wird. Es geht also so mit dem Quellcode:

Anforderungen A+B werden erfüllt –> Veränderungen für C anbringen –> Anforderungen A+B+C werden erfüllt

In Bezug auf die Ordnung sieht das so aus:

Ordnung –> Unordnung –> Ordnung

Wer hat also je überhaupt annehmen können, dass es ohne Clean Code, ohne Refactoring geht? Das war und ist widersinnig. So funktioniert die Veränderung von etwas Ordentlichem nicht.

Wenn professionelle Arbeit in etwas Ordentlichem resultiert – vom Klempner über den Arzt bis zum Softwareentwickler –, dann darf und muss zwischendurch im Verlauf der Arbeit Unordnung entstehen. Und die wird am Ende aufgeräumt. So ist das immer.

image

Und jetzt nochmal die Frage: Wer glaubt, dass bei der Veränderung von Quellcode zur Erfüllung neuer Anforderungen (oder auch zum Bug Fixing) ohne Unordnung abgehen kann?

Aus meiner Sicht sind das viele Entwickler. Und es sind noch mehr nicht-Entwickler. Der Glaube ist so weit verbreitet, dass Refactoring immer noch einer besonderen Begründung bedarf. Wie oft habe ich gehört, “Für Clean Code haben wir keine Zeit. Wenn uns jemand dabei sieht, wie wir ein Refactoring durchführen, dann haben wir Erklärungsnot.”

Aber das ist Quatsch. Nach dem Bilderleisteneinsatz im Wohnzimmer ist mir das nochmal ganz deutlich geworden.

  1. Professionelle Arbeit hinterlässt ein System in einem ordentlichen Zustand.
  2. Veränderungen an einem ordentlichen System führen zwangsläufig zu Unordnung. Die sollte man gar nicht erst vermeiden wollen.
  3. Um nach Veränderungen wieder ein ordentliches System zu haben, muss aufgeräumt werden.

Unordnung herstellen, um effizient Veränderungen vornehmen zu können – hier: Tisch verrücken, Polster von der Sitzbank nehmen, Werkzeuge bereitlegen – und Ordnung nach Abschluss der Veränderungen wieder herstellen, sind die Klammern professioneller Arbeit.

Ich glaube sogar, dass wir während der Veränderung unseres Quellcodes noch zuwenig Unordnung zulassen. Wir meinen, es ginge ohne. Wir versuchen, mit Überziehern an den Schuhen auf Sitzbankpolstern vorsichtig herumzutreten. Gebohrt wird nicht, denn das macht ja Dreck. Besser nur vorsichtig kleben. Und langsam arbeiten, damit nichts zerbrechliches umgeworfen wird.

Wir versuchen also, Strukturen zu verändern, ohne sie temporär zu “verstören”. Das ist gut gemeint – aber an der Realität effizienter Veränderungsarbeit vorbei, glaube ich.

Nicht nur ist es ganz normal, nach Veränderungsarbeit Ordnung herzustellen; Stichwort Refactoring. Es ist auch ganz normal, vor (!) Veränderungsarbeit Unordnung herzustellen, wenn das einer effizienteren Veränderung dient.

Also, haben Sie kein schlechtes Gewissen, wenn Sie für eine neue Anforderung mal Unordnung erzeugen. Haben Sie auch kein schlechtes Gewissen, hinterher immer aufzuräumen. Das ist normal, unvermeidbar, professionell. Widersetzen Sie sich Anweisungen, die das Gegenteil verlangen. Zur professionellen Arbeit gehört Ordnung im Ergebnis – genauso wie zwischenzeitliche Unordnung.