Flexibilisieren wider die Angst

Jedes Jahr im Juni habe ich Angst. Dann droht nämlich der Besuch des Heizungsablesers. Kalorimeta kündigt sich durch Aushang im Hausflur an – und ich verfalle in Furcht und Zittern.



Nein, ich zittere nicht, weil ich eine Heizkostennachzahlung fürchte. Und ich habe auch keine Angst davor, dass Manipulationen an den Heizkostenverteilern auffliegen würden. Alles ist in Ordnung damit.

Grund für meine Angst ist mein Schreibtisch:



Der steht nämlich vor der Heizung. Und an der Heizung ist der abzulesende Heizkostenverteiler angebracht. Der muss dem Ableser zugänglich gemacht werden. Der will ja nicht unter meinen Schreibtisch krabbeln. Wenn er das in jeder Wohnung machen würde… dann wäre ja sein Rücken bald hinüber. Es als kleines Sportprogramm zu verstehen, sozusagen kostenloses Arbeitsyoga… nein, dem Gedanken war er in den bisherigen Jahren nicht aufgeschlossen gegenüber. Er hat schaut auch immer so grimmig, der Ableser. Gut gelaunt habe ich ihn noch nie gesehen. Kein Wunder, er arbeitet im Akkord. Immer ist er in Hetze. Manchmal ist er mir ein Rätsel, wie er das immer noch aushält. Alle Jahre ist es derselbe Techniker; Anfang 60 ist er bestimmt. Und immer Schweiß auf der Stirn.

Und so droht jedes Jahr, dass ich für den guten Mann meinen Schreibtisch abrücken muss von der Heizung. Davor habe ich Angst. Denn der Schreibtisch ist – wie soll ich sagen? – nicht sehr mobil. Die Beine fallen leicht ab, es ist einiger Kleinkram drauf, drumherum laufen Kabel, die es zu entwirren gälte, dann das Sofa abziehen, den Drucker wegräumen… Es wäre ein großer Aufwand für die 15 Sekunden Ablesezeit. Diesen Aufwand möchte ich nicht treiben. Also habe ich Angst davor, dass mich der Ableser zwingt…

Bisher jedoch – oh, Wunder! – ist dieser Kelch an mir vorüber gegangen. Irgendwie habe ich es in den vergangenen Jahren geschafft, diesen grimmigen Gehetzten zu bewegen, unter meinen Tisch zu krabbeln. Hinterher stand mir dann auch der Schweiß auf der Stirn. Puh… Das war knapp. Wieder ein Jahr Ruhe mit dem Schreibtisch. Ich musste seine Fragilität nicht anrühren.
Jedes Jahr hat es geklappt. Vielleicht hätte es auch dieses Jahr geklappt. Doch diesmal waren die Umstände anders. Ohne ins Detail gehen zu wollen sah ich mich in diesem Jahr gezwungen, den Schreibtisch abzurücken. Schnell noch bevor ich aus dem Haus musste. Ein Stellvertreter für den Einlass des Ablesers war organisiert.

Und da ist es dann passiert. Der Schreibtisch brach zusammen. Alle Vorsicht hatte nichts genützt. Meine Angst über die Jahre war absolut begründet gewesen. Was so lange still gestanden hatte, war in 3 Sekunden am Boden. So – ein – Mist! Mist, Mist, Mist! Argghhh…

Um nun aber doch etwas Positives aus dem Malheur zu ziehen, habe ich darüber reflektiert. Dieser Blogartikel ist das Ergebnis. Denn es gibt etwas (für mich) zu lernen.

Neulich hatte ich ja schon über die Angst geschrieben, in der Entwickler oft leben. Sie haben Angst vor neuen Anforderungen oder dem Releasetermin. Unüberschaubar, was dadurch an Aufwand entstehen könnte… Der Code ist fragil, die Schritte zum Herstellen einer auslieferbaren Version undurchsichtig. “Ohje, hoffentlich will keiner etwas von uns…” So herrscht Furcht und Zittern in den Entwicklungsteams, immer wieder, mal mehr, mal weniger.
Und nun habe ich am eigenen Leib gemerkt, wie das ist. Und wie es dazu kommt. Ich habe bei der Einrichtung meiner Wohnung schlicht die Anforderung nicht bedacht, dass der Heizkostenverteiler einmal im Jahr zugänglich gemacht werden muss. Und da das ein lästiger Anlass ist, will ich dafür keinen großen Aufwand treiben müssen. Also sollte es möglichst einfach sein, den Zugang zu gewähren.

De facto habe ich das Mobiliar nun aber so verteilt, dass das nicht möglich ist. Ich habe es mir selbst schwer gemacht. Also muss ich Angst leiden. Jedes Jahr wieder. Immer bin ich überrascht, wenn die Ankündigung im Hausflur hängt. “Jo, is dän scho Ablestag?” Jahr für Jahr widersetze ich mich der klar erkennbaren und so plötzlich wie Weihnachten auftretenden Realität der Ablesung Jahr für Jahr habe ich Angst vor dem strengen Ableser; werde ich ihn wieder rumkriegen, unter den Tisch zu krabbeln?

Und alles nur, weil ich nichts daran tun will, die Schreibtischsituation zu flexibilisieren. Oder die Einrichtung insgesamt so zu ändern, dass der Zugang kein Problem ist. Herumlavieren und Angst haben scheint einfacher.

Aber das ist doch auch Mist. Die Konsequenz habe ich heute kassiert. Gesparten Flexibilisierungsaufwand habe ich jetzt teuer gespart. Chaos beseitigen, Schreibtisch aufbauen – was nur mit Hilfe möglich war – und alles wieder herrichten haben einigen Aufwand gemacht. Und das natürlich zu einem Zeitpunkt, da es mir gar nicht in den Kram gepasst hat.
Das will ich mir nun eine Lehre sein lassen. Angst ist ein Indikator. Da heißt es, nicht zurückzucken, sondern die Ursache aus der Welt schaffen. Zwei Möglichkeiten sehe ich:

1. Begrüßung mit einem kleinen Geschenk für seine Mühe. Seine Situation anerkennen, um Verständnis bitten für die eigene und honorieren, dass er sich auf eine Sonderbehandlung einlässt. Damit würde ich mir die Angstfreiheit platt erkaufen. Ich habe wenig Zweifel, dass das funktionieren würde. Wieviel wäre ich bereit auszugeben?
2. Ich räume ein für alle Mal mit dem Schreibtisch auf. Ich mache ihn mobiler, flexibler. Dazu könnte ich ihn fester zusammenfügen, damit er leichter zu bewegen ist. Und ich könnte drumherum und obendrauf aufräumen. Zeug, das herumfliegt, in Kästen packen, die ich schnell wegräumen kann. Die Kabel am Boden entwirren und fixieren, damit sie nicht umeinanderfliegen.

Option 2 wäre wohl die konsequente, saubere Lösung – die auch im Verlauf der nächsten 12 Monate zu erreichen wäre. Der Break-even wäre in 1-2 Jahren bestimmt erreicht. Eventuelle Investitionen sind fix – Geschenke hingegen würden solange fließen müssen, wie ich dort wohnen bleibe. Dito die Angst. Sie wäre weiterhin mein alljährlicher Gast, wenn ich nichts tue.
Also, auf geht´s! Flexibilisieren wider die Angst!

Der Accountability Partner als Produktivitätskatalysator

Wer kennt das nicht: Im Laufe eines Tages, eines Jahres oder Lebens nimmt man sich immer wieder vor, Handlungs -, Verhaltens -, oder Arbeitsweisen zu ändern, loszulassen und neu zu lernen. Und fast ebenso häufig müssen sich die meisten von uns eingestehen, die eigenen Vorsätze nicht umgesetzt zu haben. Das frustriert, jedes Mal aufs Neue.

Im Privatleben betrifft dieses Phänomen die berühmten guten Vorsätze, die alle Jahre wieder zum Jahreswechsel Hochkonjunktur haben und meist Ende Januar schon wieder im Sande verlaufen sind: “Ich fange endlich mit einem Sportprogramm an!” oder “Schluss mit dem Rauchen im neuen Jahr!”
Im Berufsleben berichten von diesem Erleben immer wieder Selbständige und Angestellte gleichermaßen:
Kundentermine vor Ort oder Deadlines, die direkt mit einem Kundenprojekt und also mit der Kernkompetenz des Freiberuflers oder Angestellten zu tun haben, stellen in der Regel kein Problem dar.

Aber neben den Arbeiten, die man für Kunden oder Kollegen oder den Chef zu erledigen hat, gibt es zahlreiche Tätigkeiten im Job, die man für sich erledigen oder auch in Angriff nehmen möchte. Aufgaben, die man sich selbst vorgenommen hat, ohne dass es eine im Außen begründete Notwendigkeit oder einen Termin dafür gibt.

Bei Selbständigen betrifft das häufig das Thema Akquise. Dazu können Social Media Aktivitäten oder auch Nachfasstelefonate gehören. Für viele Freiberufler ist auch das Thema Buchhaltung oder Büroorganisation im Allgemeinen ein rotes Tuch.

Doch selbst wenn es für all diese Themen keinen direkten dringenden Termin gibt, werden Sie früher (Buchhaltung) oder später (Akquise) zu einem schwerwiegenden Problem, wenn man sich ihnen nicht widmet. Bis das Problem akut wird, kommt erschwerend hinzu, dass es viele Betroffene permanent  belastet. Am Feierabend oder am Wochenende kreist im Kopf „Ich wollte, müsste doch eigentlich…..“ und von Tag zu Tag wird der Angang schwerer.

Für Angestellte ist in diesem Bereich ein häufiger Vorsatz z.B.: ein klärendes Gespräch mit Chef oder Kollegen führen, sich fachlich weiterbilden, endlich „Nein sagen” lernen oder mindestens einmal die Woche pünktlich nach Hause zu gehen. Viele Angestellte wissen oder ahnen auch, dass sie ihr persönliches Zeitmanagement verbessern möchten, haben bereits Bücher gelesen und Seminare besucht, schaffen es aber im hektischen Alltag nicht einmal, täglich für fünf oder zehn Minuten zu reflektieren – obwohl das eine Grundvoraussetzung ist, um überhaupt irgendeinen Veränderungsprozess anzustoßen.

Dieses beständige, immer wieder nicht Einhalten der eigenen Vorsätze macht auf Dauer keine gute Laune, ist dem Selbstbewusstsein nicht förderlich und kann im schlimmsten Falle, egal ob im Berufs- oder Privatleben, das Auftreten von physischen und psychischen Krankheiten beschleunigen.
Wie kann man diesen Teufelskreis der sich wiederholenden persönlichen Niederlagen durchbrechen?

Es gibt aus meiner Sicht ein sehr einfaches und erstaunlicherweise so wenig genutztes Rezept. Und zugegeben, ich bin auch erst spät darauf gekommen, inspiriert von einem Beitrag auf der Konferenz der Professional Organizer in Amerika.

Die Lösung heißt: Accountability-Partner

Viele kennen aus der Personalentwicklung das Mentoring oder oder aus Kultur und Marketing das Sponsoring. Eine Accountability Partnerschaft ist dagegen meist eine Unterstützung auf Augenhöhe. Viele Menschen sagen von sich, dass sie anderen Menschen bei bestimmten Dingen gut helfen können und genau in den gleichen Dingen mit sich selbst nicht gut umgehen. Wenn sich also zwei Menschen zusammentun, die üblicherweise geneigt sind anderen besser zu helfen als sich selbst, ist das die perfekte Ergänzung und sehr gewinnbringend für beide Partner. Accountability-Partner unterstützen sich wechselseitig.

Accountability Partner kann ein Freund, ein Kollege, Kooperationspartner oder auch eine Person sein, die Sie in einem Café oder auf einer Konferenz kennengelernt haben. Es reicht, dass Sie festgestellt haben, dass Sie beide (oder auch mehrere Personen) Dinge, die Sie tun oder erreichen wollen, immer wieder vor sich her schieben – und den Wunsch haben, das nochmal mit Unterstützung anzugehen. Die Personen, die persönlichen Vorsätze, Ziele und die Branche in der die Beteiligten arbeiten, können sehr verschieden sein. Wichtig ist, dass alle Beteiligten ein Verständnis dafür haben, sich gegenseitig zu helfen.

Das heißt konkret, ein Accountability Partner schildert dem anderen, was er erreichen möchte, wie und in welcher Zeit. Es wird verabredet, welche Hilfestellung einander guttut.

Auch das kann sehr verschieden ausgestaltet sein. Accountability Partner können sich zu täglichen Telefonaten, Chats, wöchentlichen oder monatlichen Telefonaten oder Treffen verabreden. Manch eine Accountability Partnerschaft erstreckt sich dank moderner Kommunikationsmittel über Kontinente, ohne dass sich die Partner regelmäßig oder jemals (wieder) sehen.

Ich habe zum Beispiel mit meinem Kollegen und Freund Ralf Westphal für meine Accountability-Partnerschaft verabredet, dass ich einmal die Woche bloggen und auf den entsprechenden Social Media Plattformen auf meine Artikel aufmerksam mache. Kein Kunde, kein Kollege, kein Finanzamt erwartet - schon gar nicht zu einem bestimmten Zeitpunkt - einen Artikel von mir. Aber mein Accountability Partner Ralf fragt danach, er „zieht“ sozusagen an mir. Das wirkt.
Ich bekomme die meisten Kunden für meine Dienstleistungen als Personal Organizer und Organisationsberaterin über das Internet, ja konkret, die Menschen sagen mir, dass Sie mich gegoogelt hätten. Meine Homepage ist also mein Hauptakquisetool. Mal abgesehen davon, dass mir das Weitergeben von hilfreichen Informationen Spaß macht, ist es also auch betriebswirtschaftlich meine „heilige Pflicht“, meine Homepage zu pflegen und aktuell zu halten. Zu bloggen macht mir Spaß, aber ich brauche lange für einen Artikel. Ich habe viele Themen und Ideen im Kopf, die anderen Leuten aus dem Organisationssumpf helfen könnten, aber ich schiebe das Schreiben oft vor mir her.

Mit Ralf chatte oder telefoniere ich deshalb immer kurz am Sonntag, ob es bei dem Wochenplan bleibt. Wir kontakten uns Mitte der Woche noch einmal, ob alles im Fluss ist und freuen uns am nächsten Sonntag gemeinsam über das Erreichte.

Wir beschäftigen uns beide auf verschieden Weise und in verschiedenen Branchen mit Produktivität und Unternehmensorganisation. Das ist natürlich ein Glücksfall, da wir uns auch thematisch befruchten. Ich hatte aber in einer persönlichen Angelegenheit, dem Abgewöhnen einer Verhaltensweise, auch schon eine Accountability Partnerin. Außer dem gemeinsamen Interesse die vereinbarten Ziele zu erreichen, hatten wir dort keine Gemeinsamkeiten. Es hat dennoch sehr gut funktioniert.

Meinem Accountability Partner fällt das Schreiben sehr leicht, er hat sich daher zwei Blogartikel mit den entsprechenden Social Media Aktivitäten für jede Woche vorgenommen. Daneben hat er sich für jeden Freitag ein halbes Stündchen Buchhaltung in sein Programm geschrieben. An diese Aufgaben erinnere ich ihn – und wenn er vom “Plansoll” abzuweichen droht, überlegen wir gemeinsam, wie er wieder auf Kurs kommen kann.

Seit ich Ralf als Accountability-Partner habe, klappts mit dem Bloggen. Sich mit jemanden, der zwar andere Themen, aber ähnlich gelagerte Probleme hat, darüber auszutauschen, spornt an und macht Freude. Inzwischen habe ich immer am Mittwoch schon meine selbst gestellten Aufgaben erledigt. Und das Ergebnis meiner Vorsätze kann ich auch noch ohne großen Aufwand in Zahlen sehen. Google Analytics machts möglich. Ich bin überzeugt, in einigen Wochen wird das wöchentliche Bloggen eine Routine sein und ich kann mit Ralf den nächsten Vorsatz angehen.

Gute Gründe für einen Accountability Partner

1. Jemand der wöchentlich auf positive Weise an die eigenen Vorsätze erinnert, sorgt auf einfache Weise für die extra Portion Motivation und damit Produktivität. Ein Accountability Partner hilft Ihnen, sich zu fokussieren und die eigenen Ziele zu erreichen.

2. Es beflügelt, wenn sich jemand regelmäßig für Ihre Ergebnisse interessiert und allein schon die Handlung würdigt - Mütter zählen bei solchen Vorhaben nicht☺ Manches Mal muss man ja scheinbar Banales einüben oder loslassen, das anderen Menschen ganz leicht fällt und die einem deswegen keine Anerkennung schenken. Und wir brauchen Anerkennung, insbesondere um die scheinbar schwierigen Dinge bewältigen zu können.

3. Wenn man einen privaten oder geschäftlichen Erfolg erzielt hat, ganz gleich ob bahnbrechend oder winzig, der Accountability Partner freut sich mit.

4. Es macht Spaß, Accountability Partner für jemand anderen zu sein. Mit eigenen Ideen, oder auch nur Nachverfolgungsanrufen-  oder Treffen die Entwicklung und Fortschritt bei einem anderen Menschen zu begleiten, macht große Freude.

5. Manchmal hat man eine Idee fürs Business, weiß aber nicht genau, ob sie tatsächlich die richtige ist und denkt sich in eine Sackgasse. Und man ahnt, dieses nur „in der eigenen Suppe schwimmen“ führt nicht zu einem richtigen Ergebnis. Die eigenen Ideen aus einer anderen Perspektive zu betrachten, wäre schön. Ein Accountability Partner wird gern ehrliches Feedback geben.

6. Wenn Sie sich einmal überrumpelt fühlen von der täglichen Hektik und gar nicht mehr wissen, wo anfangen, dann bringt ein Accountability Partner Sie zurück auf den Boden der Tatsachen. Er hilft den Kopf zu heben und den ersten Schritt aus dem Hamsterrad zu tun.

Machen Sie nun den ersten Schritt und suchen Sie sich einen Accountability-Partner oder schildern Sie uns hier Ihre Erfahrungen. Es gibt bestimmt das eine oder andere, das Sie verändern möchten und bei dem Sie ein bisschen “Zug” gebrauchen können.

Die Gastbloggerin

Andrea Kaden ist Professional Organizer und Inhaberin von
Zeitgewinn Hamburg (Twitter: @Zeitgewinn). Ihre Leidenschaft ist das Organisieren und ständige Optimieren von Arbeitsabläufen im Office. Dabei ist Ihr das Entwickeln von neuen Organisationskonzepten- und strukturen fürs Büro ebenso wichtig wie das unkomplizierte “Zupacken” vor Ort. In Ihren Workshops lieg es ihr getreu den Kaizenprinzipien am Herzen, die Mitarbeiter und ihre Ideen einzubinden und zur aktiven Beteiligung am kontinuierlichen Verbesserungsprozess zu motivieren. Neben Ihrer Tätigkeit in großen und kleinen Unternehmen hält Andrea Kaden Vorträge und Workshops zum Thema „Papierloses Büro“.

IronMQ – Simple Warteschlangen in den Wolken

Wie können Sie Anwendungsteile kommunizieren lassen, wenn sie allemal über Netzwerke verteilt sind. Klar, irgendwie geht das mit WCF und Azure… Aber warum so kompliziert?

Stefan Lieser und ich verbringen gerade einige Tage in unserem jährlichen Clean Code Advisors Retreat, um das vergangene Jahr zu reflektieren und das nächste zu skizzieren. Neben viel Zeit zum Reden und Denken darf da aber natürlich auch die Programmierung nicht zu kurz kommen. Also haben wir uns eine Application Kata ausgedacht: AppZwitschern. Dabei geht es darum, Tweets mit einem Desktop (oder Mobile) Client zu erfassen und erst zu einem späteren Zeitpunkt zu versenden. Selbstverständlich muss der Client dafür nicht offen gehalten werden. Die terminierte Versendung übernimmt ein Server.

Das ist eine schöne Aufgabe, in der wir die neue Flow Runtime NPantaRhei einsetzen. Macht Spaß, funktioniert gut. Darüber hinaus kommen einige Technologien zum Einsatz, z.B. Twitter, bit.ly, NCron und auch eine Kommunikationstechnologie. Die Clients müssen ja dem Server die Tweets zur späteren Versendung schicken.

Zuerst haben wir dafür Amazon SQS benutzt. Das ist Cloud Queue-Service. Der funktioniert. Unsere verteilte App zwitschert damit verlässlich und skalierbar. Alle Clients schreiben in dieselbe SQS Queue. Und beliebig viele Server-Instanzen verarbeiten die Versandaufträge. Perfektes scale-out.

Aber Amazon SQS hat einen recht umständlichen API. Und interessanterweise sichert SQS nicht zu, die Nachrichten in einer Warteschlange in der Reihenfolge abzuliefern (dequeue), in welcher sie eingestellt wurden (enqueue). Das ist zwar für unser Szenario nicht so wichtig, dennoch irgendwie merkwürdig. Lohnt sich da wirklich eine nähere Beschäftigung mit diesem Service?

Auch wenn wir für AppZwitschern nicht mehr Leistung brauchen, habe ich dann aber mal geschaut, ob es Alternativen gibt. Und tatsächlich, die gibt es. Hängengeblieben bin ich ganz schnell bei IronMQ von iron.io.

Attraktiv war deren Anspruch an Einfachheit:

• Einfache Anmeldung ohne Kreditkartenangabe, da 250.000 Nachrichten pro Monat ohnehin frei sind. Sie wollen es Interessenten also leicht machen, IronMQ auszuprobieren.
• Einfacher API auf für .NET. Der ist als Quelle bei github zu finden: iron_mq_dotnet. Unter downloads findet sich allerdings auch eine binäre Version.

Und IronMQ bietet, was SQS nicht hat: echte FIFO-Semantik.

Also habe ich alternativ zu unseren SQS-Operationen für die AppZwitschern-Flows welche für IronMQ aufgesetzt. Das war in 20 Minuten gemacht. Hier unser IronMQ-Adapter, der simples Enqueue und Dequeue so anbietet, das es leicht bei der Flow Runtime zu registrieren ist:

public class IronMQOperations
{
    private readonly Client _client;
    private readonly Queue _queue;
 
    public IronMQOperations(string queueName, string projectId, string token)
    {
        _client = new Client(projectId, token);
        _queue = _client.queue(queueName);
    }
 
 
    public void Enqueue(string data)
    {
        _queue.push(data);
    }
 
 
    public void Dequeue(Action<string> onDataReceived)
    {
        do
        {
            var msg = _queue.get();
            if (msg == null) break;
 
            onDataReceived(msg.Body);
 
            _queue.deleteMessage(msg);
        } while (true);
 
        onDataReceived(null);
    }
}

Ich würde sagen, einfacher gehts kaum. Mit den paar Zeilen ist eine verlässliche Kommunikation via Cloud möglich. Die braucht ihre Zeit; Performance wie mit TCP im lokalen Netz ist da nicht zu erwarten. Aber das spielt für unser Szenario und viele andere keine Rolle. Es geht darum, serverseitig skalieren zu können.

Der SQS-Adapter hat knapp doppelt soviele LOC – und bietet eben nicht das, was man von einer Queue erwartet.

Nun bin ich gespannt auf die .NET Bindings für die anderen iron.io Dienste: den Key-Value-Store (Cache) und serverseitige Prozesse (Worker). Einstweilen habe ich in meinem Köcher einen no-brainer für die Verteilung von Arbeitspaketen.

PS: Der Support bei iron.io ist gut. Ich habe ein paar Fragen gehabt und den angebotenen Live Chat benutzt. Da war zu jeder Tageszeit jemand zu erreichen, der entweder Auskunft geben konnte oder dafür gesorgt hat, dass mir später geholfen wurde. I like that.

SMARTe Nutzenpakete

Was ist eigentlich das Ergebnis einer Anforderungsanalyse? Sind das User Stories, Use Cases oder Features? Was sollte auf dem “Aufgabenkärtchen” eines Teams als Aufgabe stehen?
Heute habe ich dazu eine “Formel” für mich gefunden: Anforderungsanalyse soll SMARTe Nutzenpakete liefern. SMART ist dabei dem Projektmanagement entlehnt.
Jedes Anforderungspaket ist entweder funktional oder nicht-funktional nützlich für einen Stakeholder und ist…

• Specific/Spezifisch: Es ist definiert, welcher Input in welchen Output unter welchen Bedingungen überführt wird. Es liegen also klare Akazeptanzkriterien vor.
• Measurable/Messbar: Die Überprüfung der Akzeptanzkriterien kann automatisch erfolgen oder wird für den Stakeholder möglichst einfach gemacht (Stichwort Prüfstand).
• Attainable/Machbar: Die Kompetenz zur Umsetzung ist beim Stakeholder und beim Entwicklungsteam vorhanden. Das betrifft Verständnis wie Fähigkeiten und Technologien.
• Resourced/Zugewiesen: Es ist klar, wer das Paket haben will und abnimmt. Der steht in den Startlöchern und zieht an der Umsetzung. Es ist klar, wer das Paket umsetzt. Und es ist klar, wer für Klärungen unterwegs ansprechbar ist.
• Timely/Terminierbar: Die Umsetzung ist überschaubar (besser wenige Stunden als wenige Tage). Der Fertigstellungstermin liegt in nicht allzu ferner Zukunft (besser wenige Tage als wenige Wochen).

Natürlich können nicht alle Anforderungen sofort SMART formuliert werden. Dahin kommt man nur über die Zeit. Zuerst wird wohl die Eigenschaft —R- hergestellt, dann –AR-, dann vielleicht S-AR-, dann SMAR-, schließlich SMART.
Das dauert etwas. Das braucht Dialog mit den Stakeholdern. In jedem Fall sollte die Entwicklung erst beginnen, wenn die Nutzenpakete eben so klein sind, dass sie SMART formuliert vorliegen.

Angst essen Entwickler auf 2

Woher kommt denn die Angst, die viele Entwicklerherzen bestimmt? Meine Vermutung, es gibt dafür zwei Gründe:

1. Angst ist ein Kontrollinstrument. Wer Bedenken äußert und Unsicherheitsszenarien ausmalt, der erlangt Bedeutung und damit Macht. In einer Welt, in der Softwareentwicklung oft noch als lästiges Anhängsel gesehen wird und man mit Unkenntnis in IT-Dingen auf Partys und im Feuilleton kokettieren kann, da schrumpft auf der anderen Seite schnell mal das Selbstwertgefühl – und will kompensiert werden. Angstbasiertes Bedenkenträgertum ist da ein probates Mittel.
2. Wem der vorgenannte Grund zu psychologisch-schwammig ist, kann hoffentlich zumindest mit diesem zweiten etwas anfangen: Die ängstlichen Bedenken sind Ausdruck einer noch tieferliegenden Angst. Und das ist die Angst, Code später nur noch schwer verändern zu können. Der Gedanke dahinter: “Wenn ich heute etwas nicht berücksichtige, dann habe ich morgen oder übermorgen große Probleme, neue Erkenntnisse in den Code einzubringen.” Spätere Codeanpassungen können zu Regressionen führen, Codeveränderungen können schlicht viel, viel, viel aufwändiger sein, als es gleich “richtig” zu machen.

Der zweite Grund ist für mich der gravierendere. Denn dahinter steckt ein Bild von Code, das mir essenziell anti-agil scheint.

Oberste Priorität hat für mich daher jedes Prinzip und jede Praktik, um diese Angst zu reduzieren. Eine gute Abdeckung mit automatisierten Tests hilft. Ein Versionsverwaltungssystem hilft. Ein automatischer Buildprozess hilft. Sie wirken angstlösend. Regressionen werden zumindest schnell erkannt, wenn nicht gar verhindert.
Für die Flexibilisierung von Code müssen wir aber noch mehr tun. Die Kosten für Änderungen dürfen nicht weiter exponenziell steigen. Aber auch einen linearen Anstieg empfinde ich als noch zu schwachen Trost. Warum wird es mit der Zeit nicht immer leichter und leichter, Änderungen in Software einzubringen? Wenn wir Software als Wissenspool ansehen, dann wächst der doch über die Zeit. Und mit mehr wissen, sollten Probleme in der Zukunft leichter zu lösen sein.

Dieser kühnen Vision stehen aber natürlich alte, feste Glaubenssätze entgegen. Aus denen speist sich auch die Angst. Da Angst jedoch ein ganz unschönes Gefühl ist, finde ich es natürlich, nach Wegen zu suchen, die Angst zu überwinden. Auch und gerade, wenn wir dafür über die langen Schatten heimeliger Glaubenssätze springen müssen.
Welche Glaubenssätze halten uns also davon ab, Software in anderer als der heutigen Weise zu entwerfen und zu codieren? Was können wir anders machen, um keine Angst mehr davor zu haben, Veränderungen auf einen beliebigen Zeitpunkt in der Zukunft zu verschieben? Wie kommen wir weg von dem Satz, “Ja, wenn Sie uns das vor einem halben Jahr gesagt hätten, dann hätten wir das ganz leicht einbauen können. Jetzt ist das sehr, sehr schwierig.” Der ist nämlich nicht nur demotivierend für Kunden wie Entwickler, sondern steht in ständigem Konflikt zur Realität der Anforderungskenntnis. Kunden wissen nun mal sowenig darüber, was sie morgen oder übermorgen vielleicht haben wollen. Und sie können das, was sie ungefähr wissen, nur schlecht formulieren. Also müssen wir ohnehin mit ständigen Veränderungen fertig werden. Besser, wir verlieren endgültig die Angst davor. Stattdessen sollten wir jeden Änderungswunsch willkommen heißen. Denn er zeigt uns, dass unsere Software gewollt wird. Wer aufhört, Änderungen zu wünschen, der hört sehr wahrscheinlich auf, unsere Software zu nutzen.

Angst essen Entwickler auf 1

Mir scheinen in der Branche zwei Modi vorzuherrschen, in denen entwickelt wird:

Modus #1, Sorglosigkeit: Es wird Code geschrieben, als gäbe es kein Morgen. Raushauen, was das Zeug hält. Gummi auf die Straße bringen. Den Coderevolver schneller ziehen als der eigene Schatten. Wichtig ist, dass der, der grad am lautesten schreit, möglichst schnell zufriedengestellt wird. Ob das dann eine Qualität hat, die Anwendern Freude macht, ist eine zweite Frage. Darüber macht man sich keine Sorgen. Es wird in den Tag hinein entwickelt. Kurzfristiger Erfolg ist wichtig. Langfristiger Erfolg wird als selbstverständlich angenommen oder ist irgendwie gar kein Thema.

Modus #2, Angst: Bevor Code geschrieben wird, werden die Implikationen aller Ramifikationen jeder Änderung länglich gewälzt. Es gibt immer viel zu bedenken. Da will zum Beispiel sorgfältig geprüft werden, was eine Veränderung für Auswirkungen auf die Sicherheit des Systems hat. Und ganz wichtig: Ist der gewählte Ansatz nicht doch zu speziell? Könnte er nicht erweitert und verallgemeinert werden, um dermaleinst auch noch unbekannte Anforderungen in der Zukunft eventuell leichter abzudecken? Und wie ist es mit Sonderfällen? Finden die schon genügend Berücksichtigung?

Beide Modi führen in die Lähmung.

Sorglosigkeit erzeugt Lähmung in naher oder mittlerer Zukunft. Denn dann ist der Code durch die sorglose Anhäufung unwartbar geworden. Für methodisches Vorgehen, Strukturplanung, Bemühen um Evolvierbarkeit war ja nie Zeit.

Angst erzeugt Lähmung in der Gegenwart. Man kommt vor lauter Überlegungen zu Unwahrscheinlichem und Unbekanntem nicht zum Wesentlichen, der Produktion von Code, der jetzt schon etwas nützt. Ultimativer Nutzen möglichst ohne Lücke in der Zukunft ist wichtiger.

Die sorglose Programmierung scheint in den letzten Jahren allerdings im Rückgang begriffen. Zum Glück. Der Diskurs über Softwarequalität im Allgemeinen und Testmethodiken und –tools im Speziellen hat etwas bewirkt.

Die angstgehemmte Programmierung hingegen ist immer noch weit verbreitet. Sie zeigt sich im Kleinen, wenn an jeder Ecke try-catch-Blöcke oder Code Contracts geschrieben werden. Und sie zeigt sich im Großen, wenn aus Anforderungen Dinge herausgelesen werden, die dort nicht stehen. Oder Anforderungen zwar als nicht explizit beschrieben erkannt, aber dennoch felsenfest ab-so-lut sicher vorhergesehen werden. Zeuge der Vorhersage ist dann die Erfahrung. Und verräterisch ist die Formulierung “Aber was, wenn XYZ so oder so wäre?”

Woher kommt nur diese Angst? Warum ist sie so unausrottbar?

SEACON 2012 - Vortrag zu agilen Softwarestrukturen

Heute habe ich auf der SEACON 2012 Flow-Design vorgestellt, ohne es so zu nennen :-) Mein Ansatz war prinzipieller: Für mich ist das, was wofür Flow-Design steht, ein Ergebnis konsequenter Anwendung des Single Responsibility Principle. Flow Design trennt die Verantwortlichkeiten Integration und Operation.

Operation: Hier spielt die Logik-Musik. Hier kommen 3GL-Kontrollstrukturen und Ausdrücke zum Einsatz. Das Ergebnis sind Codeeinheiten, die mit Unit Tests solide abgedeckt sein sollen. Um diese Codeeinheiten überschaubar und leicht testbar zu machen, sind sie unabhängig von einander. Deshalb werden sie über Datenflüsse zu Größerem verbunden.

Integration: Hier werden die Operationen zu Größerem verbunden. Integratoren enthalten keine Kontrollstrukturen oder Ausdrücke. Sie sind frei von solchen Logikkonstrukten. Ihre einzige Aufgabe ist es, Operationen und andere Integratoren zu integrieren. Das geschieht auf beliebig vielen (Abstraktions)Ebenen.

Weil Operationen nicht von einander und am besten auch von keinem gemeinsamen Zustand abhängen sollen, setzen sie auf Datenfluss zur Kommunikation. Weil es um Datenfluss geht, sind Operationen und die daraus entstehenden Integrale eher Aktionen oder Prozess(schritte), denn Akteure. Es geht um Verben statt Substantive. Und weil das so ist, können die entstehenden Hierarchien unmittelbar ausdrücken, wie Code die Funktionalität für Features der Anforderungen herstellt.

Eine Softwarestruktur, die diese Trennung lebt, ist deshalb bestens geeignet, agiles Denken im Code widerzuspiegeln.

Mein Credo:

Process over Data

Wenn wir agil Vorgehen, sollten wir das datenorientierte Denken der bisherigen üblichen Objektorientierung zugunsten eines prozessorientierten Denkens aufgeben. Damit tragen wir auch dem alten Verständnis von Software Rechnung, dass sie als EVA begreift: Eingabe – Verarbeitung – Ausgabe.

Softwarestrukturen für agiles Vorgehen on Prezi

Wer nun mehr über diesen Ansatz erfahren möchte, der kann in den Flow-Design Ressourcen bei den Clean Code Advisors stöbern.

Oder in der dotnetpro meine Artikel verfolgen.

Oder hier meinen Ausflug ins Single Responsibility Principle mitmachen.

Oder nicht nur dieses Blog verfolgen, sondern auch mein englisches Blog lesen. Ich werde mich bemühen, dort mehr zu schreiben, um das Konzept international zur Diskussion zu stellen. Es bewegt sich ja gerade recht viel dabei: Flow-Design wird “entzaubert” durch eine Gründung in fundamentalen Prinzipien. Und Flow-Designs ausführbar zu machen, wird durch die Flow Runtime NPantaRhei noch einfacher.