Machbare Veränderungen - Daneben statt rein

Das Brownfield ist überall. Teams ersticken in Support, strategische Entwicklung findet nur zufällig statt, Kunden warten lange auf zugesagte Änderungen, das Backlog enthält Tausende Einträge aus mehreren Jahren. Alles schon gesehen. Und nicht nur einmal.

Wenn dann irgendwann das Schmerzempfinden des Teams diese Situation als wenig nachhaltig signalisiert, ist guter Rat teuer.

Kann umfangreiches Refactoring aber nicht die Situation retten? Kaum. Denn wo ist der Kunde – intern oder extern –, der es aushält, dass über diese Refactoring-Maßnahmen lange kein äußerlich sichtbarer Nutzen produziert wird.

Oder vielleicht neu schreiben? Ja! Das wäre cool. Macht auch mehr Spaß, als am alten Code rumzumokeln. VB6 geht auch beim schönsten Refactoring nicht weg. Am besten während der Neuentwicklung das Brownfield mit dem kleinstmöglichen Aufwand am Leben halten. Und irgendwann wir umgeschaltet auf das strahlende Neue. Kaum. Woher sollen denn die Ressourcen kommen, die das Neue zügig vorantreiben, wenn am Alten auch noch gebastelt werden soll? Und wie ist es mit einem Termin für die Neuentwicklung?

Möglichst schnell? Dann ist es noch schwieriger mit den Ressourcen. Vor allem haben Entwickler, die Jahre lang im Korsett eines Brownfields gearbeitet haben, wenig Übung darin, ein Greenfield zu bestellen, so dass daraus nicht bald wieder ein neues Brownfield wird.

Oder darf es ruhig dauern, bis die Neuentwicklung fertig ist? Es soll ja auch was richtig Gutes rauskommen? Dann fehlt die Motivation zu häufigem Feedback. Dann ist das Risiko groß, sich in Forschung und Frameworks zu verlieren. Eine never ending story…

Nein, ich halte beide Wege inzwischen für falsch. Aus dem Brownfield kommt man durch keinen Refactoring-Gewaltmarsch heraus und auch nicht durch den großen Wurf einer kompletten Neuentwicklung.

Die Lösung liegt vielmehr darin, an das Bestehende anzubauen. Wie oben in dem Bild. Weder wurde die Villa entkernt, noch wurde sie abgerissen, um etwas Neues zu schaffen. Vielmehr wurde sie in Ihrem Wert erhalten und um etwas Neues erweitert. Das Neue ergänzt das Alte. Das Neue ersetzt in Teilen das Alte. Vielleicht doppelt es das Alte übergangsweise auch, um es schließlich abzulösen?

Ja, so sehe ich das bei der Softwareentwicklung auch.

Das Brownfield muss nicht refaktorisiert werden, um mit ihm und in ihm weitere Jahre erfolgreich zu sein. Vielmehr ist im Brownfield ein Teil zu identifizieren, der freigestellt werden kann. Nur dieser Teil wird dann neu entwickelt. Das ist überschaubar. Während der Neuentwicklung, ist die alte Version der Funktionalität im Brownfield erhalten. Aber irgendwann wird sie dort abgeklemmt, um von der Neuenentwicklung übenommen zu werden.

Die Neuentwicklung kann mit dem Brownfield über eine gemeinsame Datenbank verbunden sein. Aber darüber sollte man gut nachdenken. Besser ist es, hier wird die Chance genutzt, um auch darin aufzuräumen. Also eine neue Datenbank aufsetzen und mit der bisherigen Synchronisieren.

Nur so geht es, glaube ich. Masterpläne, die alles auf einmal richten, sei es mit Refactoring oder kompletter Neuentwicklung, sind Geldgräber. Es kommt nichts raus. Oder es dauert zu lange, als dass es die Kunden zufriedener machen würde.

Besser ist es, Sie stellen “agile Schnellbote” neben Ihren “behäbigen Schlachtschiffen”. So können Sie schrittweise Ihr Brownfield aushöhlen. Und irgendwann gibt es nur noch einen Schwarm von “Schnellboten”, die unkompliziert separat evolvierbar sind.

So funktioniert das auch mit Städten. Die werden nicht platt gemacht – außer in Kriegen. Sondern die wachsen und verändern sich Haus für Haus. Der “Schwarm an Häusern” teilt sich natürlich Infrastruktur. Das können die vielen “Software-Schnellbote” auch. Ansonsten sind sie jedoch unabhängig. Jedes für sich kann verändert oder abgerissen werden. Kein Masterplan ist nötig. Kein “Wenn wir mal Zeit haben…”. Deshalb: Strukturieren Sie Ihre Software genauso. Versuchen Sie weniger, darin etwas großartig zu verändern. Stattdessen stellen Sie lieber die Neuerung daneben – und lösen Sie auch so Altes durch Neues ab.

Was andere schon richtig machen - Reviews

Das ist Galina Knoll. Sie ist Hausdame im Hansa Apart Hotel in Regensburg [1]. Von ihr können wir als Softwareentwickler etwas lernen.

Als Hausdame ist eine Ihrer Aufgaben, die Reinigung der Zimmer zu überprüfen. Sie hat einen Plan, welche Zimmer zu reinigen sind – das hängt ja davon ab, wann welche Gäste abreisen. Den Plan spricht Sie mit den Zimmermädchen ab, die die Zimmer herrichten. Und am Ende überprüft Sie, ob die Zimmer den gewünschten Zustand haben. Manche müssen prick für einen neuen Gast sein; andere müssen “nur” für eine weitere Nacht desselben Gastes wieder frisch sein.

Natürlich geht bei Dutzenden oder gar Hunderten Zimmern immer etwas schief. Eine Hausdame ist deshalb dafür zuständig, Qualitätsmängel einer Behebung zuzuführen. Manches muss nochmal vom Zimmermädchen nachgebessert werden. Für anderes ist der Hausmeister zu informieren.

In die Sprache der Softwareentwicklung übersetzt bedeutet das: Galina Knoll ist für den Review der Arbeitsergebnisse zuständig.

Hotels haben schon lange gelernt, dass die “Aufräumarbeiten” der Zimmermädchen nicht allein genügen, um die Qualität herzustellen, die der gute Ruf eines Hotels für seinen Erhalt braucht. Es kommt zu sehr darauf an, dass in den Zimmern alles stimmt, als dass man sich dort Nachlässigkeiten erlauben dürfte. “In Produktion gehen” Zimmer also nur nach einem Review durch die Hausdame.

Und wie ist es bei der Softwareentwicklung? Kommt es da nicht für den guten Ruf des Entwicklungsteams bzw. des Softwarehauses darauf an, dass die Qualität des Codes stimmt? Ich meine, schon. Er ist das Aushängeschild – auch visuell/haptisch durch die Usability, aber auch durch seine Stabilität. Fehler jeder Art turnen den Nutzer genauso ab, wie den Hotelgast die Fußnägelreste der Vorgängers in der Dusche oder Spinnweben über dem Bett.

Warum hat dann aber die Softwarebranche noch nicht dasselbe gelernt wie die Hotelbranche? Warum sind Reviews nicht etabliert in jedem Team? Warum lässt die eine Branche Zimmermädchen bei vergleichsweise einfachen arbeiten nicht ohne Endkontrolle – und die andere Branche überlässt die Hersteller ungleich komplizierterer Ergebnisse “ihr Zeug” einfach an den Kunden geben?

Es ist nicht zu verstehen. Und bitte: Man mögen mir den Einwurf “Keine Zeit!” ersparen. Den könnte die Hotelbranche auch vorbringen. Es wäre doch alles einfacher/billiger, wenn die Reinigung schneller ginge weil ohne Review. Trotzdem verzichtet man nicht auf die visuelle und persönliche Kontrolle. Der Grund: Man hat verstanden, dass schlechte Qualität früher oder später den Geldfluss verringert. Entweder direkt, weil weniger Gäste buchen – dann muss man die Preise senken und dann weiter an Kosten Sparen. Eine Negativspirale setzt ein, die niemanden zufrieden macht. Oder indirekt, weil Aufwand durch Nachbesserung entsteht, wenn Gäste sich beschweren. Der zieht wertvolle Kräfte zur Unzeit von Wichtigerem ab.

Ich würde also sagen: Wir können etwas von der Hotelbranche lernen. Und das nächste Mal, wenn Sie in einem Hotel sind, freuen Sie sich bewusst über die Abwesenheit von Mängeln. Alles ist sauber und frisch.

Wäre das nicht auch wünschenswert für die Software, die Sie ausliefern?

Mein Dank gilt Galina Knoll und ihren Kolleginnen und Kollegen in den vielen Hotels, in denen ich jährlich einige Zeit verbringe.

[1] Im Hansa Apart Hotel bin ich gerade für ein paar Tage während eines Kundentermins. Da ist mir Galina Knoll morgens mit ihrem Notizblock und dem großem Schlüsselbund aufgefallen. Und es ist mir bewusst geworden, was wir von ihrer Rolle lernen können.

Flow Runtime Meets Event-Based Components

Dass die Flow Runtime ein Ersatz für Event-Based Components sein soll, hat nicht jedem Freund des Flow-Design geschmeckt. Nicht alle sind deshalb mit fliegenden Fahnen zu NPantaRhei übergelaufen.
Ok, ok, kann ich verstehen. Aber jetzt ist Schluss :-) Jetzt gehen Event-Based Components (EBC) nämlich auch mit der Flow Runtime. EBC werden von der Runtime einfach in Operationen “übersetzt”. Und das geht so:

class Rechenwerk
{
    public void Teilen(Tuple<int,int> input)
    {
        if (input.Item2 == 0)
            DivisionDurchNull(input);
        else
            Resultat(input.Item1/input.Item2);
    }
 
    public event Action<int> Resultat;
    public event Action<Tuple<int,int>> DivisionDurchNull;
}

Eine Instanz EBC-Klasse wird dann einfach bei der Konfiguration reingereicht:

var config = new FlowRuntimeConfiguration()
        …
        .AddEventBasedComponent("rechenwerk", new Rechenwerk());

Die Runtime analysiert die Klasse und bietet dann alle Methoden mit der Signatur

• Action
• Action<T>

als Input-Port an. Der Methodenname ist der Portname. In diesem Fall wäre es nur Teilen.

Alle öffentlichen Events mit ebensolcher Signatur erkennt die Runtime als Output-Ports. Der Event-Name ist der Portname.

Im Flow müssen dann die Ports explizit angegeben werden.

var config = new FlowRuntimeConfiguration()
                .AddStreamsFrom(@"
                                 /
                                 .in, rechenwerk.teilen                                                rechenwerk.resultat, .result
                                 rechenwerk.divisionDurchNull, .error
                                 ")…

Bei Func/Action-Operationen gibt es keine Portnamen, weil sie durch den Verwendungsort der Operationen automatisch unterschieden werden kann zwischen Input und Output. EBC sind also ausführlicher. Aber das ist ja auch Sinn der Aktion. Auf EBC werden Sie zurückgreifen, wenn Ihre Operationen mehrere Input- und/oder Output-Ports haben.

Ich hoffe, damit ist es nun für alle attraktiv, sich mit der Flow Runtime zu beschäftigen. Selbst wer ganz auf EBC eingeschossen ist, kann jetzt davon profitieren, dass Flows für die Runtime mit einem Visualizer definiert und sogar aus Assemblies wieder ausgelesen werden können. Oder er kann ganz einfach die Verarbeitung in einer EBC-Instanz in den Hintergrund legen. Oder sie kann Exceptions in einer EBC-Instanz mit einer Causality abfangen – selbst wenn es auf einem Hintergrund-Thread gekracht hat.

Enjoy EBC at the next level!

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.