Politische Führung mit Boots On The Ground

Ich habe gerade dieses Video mit Bezug auf den BREXIT gesehen:

Eine sehr interessante Aussage war, dass der Redner, der sich als weltoffen und inklusiv versteht, in den Gegenden die für den Austritt waren, gerade mal 4 Tage seines Lebens verbracht hat.

Ich glaube, dass dies nicht nur auf ihn zutrifft sondern womöglich auf den Großteil der Meinungsführer in der Bundespolitik und den überregionalen Medien.

Der Mangel an Präsenz in und damit auch Verständnis für die Bedürfnisse der nicht ganz so attraktiven Gegenden lässt Raum für die Gruppen welche einfache Lösungen versprechen um persönlichen Einfluss zu erlangen. Diesen Gruppen ist es egal ob die vorgeschlagenen Lösungen überhaupt funktionieren können oder die Situation der Regionen sogar verschlechtern würden.

Interessanterweise ist dies womöglich sogar den Wählern egal, denn was sie eigentlich nur wollen ist „den da Oben einen Denkzettel verpassen“. Wenn Bürger in solchen vergessenen Regionen sich nicht vertreten und verstanden fühlen und deshalb solche Denkzettel wie den BREXIT verteilen, dann sollte die Politik darüber nachdenken neue Wege zu gehen.

Hier ein radikaler Vorschlag: Das Bundeskabinett trifft sich jeden Monat einmal außerhalb Berlins in den Räumen eines Kreistags und verbringt 3-5 Tage in dieser Gegend. Z.B. einen Monat in Schwerin, dann in Bad Kreuznach, Pirna, Mettmann usw.

Das ganze könnte dann jeder Minister in dieser Zeit verbinden mit einer offenen Fragestunde/Podiumsdiskussion zu einem aktuellen Thema oder der ein oder andere Minister könnte eine Kreistags bzw. Stadtratssitzung besuchen.

Klar ist, dass dies alles primär symbolischen Character hat. Jedoch sollte dadurch ein disconnect der Politik von der Stimmung an der Basis zumindest etwas unwahrscheinlicher werden.

Ganz nebenbei entspricht das auch einem Prinzip aus Machiavellis „Der Fürst“: Wenn du eine aufständige Provinz befrieden willst, verlege deine Hauptstadt dort hin.

Agiles Schätzen mit Storypoints – Agile Estimating with Story Points

English Version below

Agiles Schätzen mit Storypoints

Komplexität, Aufwand, Zeit – was soll mit den Storypoints eigentlich geschätzt werden?

Wenn alle Userstories von ein und derselben Person bearbeitet werden würden, dann sollte am Ende gelten: Je größer die geschätzten Storypoints, desto länger hat es gedauert (Investierte Arbeitszeit = Aufwand).

Nun arbeiten wir aber im Team und wir alle wissen, dass es unterschiedliche Arbeitsgeschwindigkeiten gibt. Deshalb schätzen wir ja nicht in Zeit sondern Storypoints. Und Storypoints funktionieren immer im Vergleich mit anderen Aufgaben (relatives Schätzen), also „größer, kleiner, gleich“. Deshalb stellt euch folgende Frage beim Schätzen:

„Wenn ich die Story allein lösen müsste und ich alle Tools benutzen dürfte die im Team zur Verfügung stehen, würde ich dann länger, kürzer oder gleichlang für diese Story brauchen als für die andere Story?“

Jetzt kommt sofort der Einwand „Aber ich kann ja gar nicht alle Tools bedienen, bzw. mir fehlt Vorgehens-/Fachwissen etc.“ Das stimmt. Aber das fehlt euch bei allen Stories gleichermaßen und kürzt sich weg. Um „größer, kleiner, gleich“ abschätzen zu können reicht es also die Teammitglieder zu befragen, welche tatsächlich Ahnung von den anderen Aufgaben haben. Wenn die sagen „weniger als bei der anderen Story“, dann gilt das für euch bezüglich dieses Aufgabenteils wahrscheinlich auch.

Abschließend noch ein Wort zu Unwägbarkeiten und Risiko. Schneller darf die Bearbeitung immer gehen. Probleme gibt es eher dann, wenn wir Risiken unterschätzen. Deshalb überlegt euch, wie der realistische Worst-Case aussehen könnte und wie aufwändig dieser im Vergleich zur Vergleichsstory ausfällt.

Agile Estimating with Story Points

Complexity, effort, time – what do we estimate when we use story points?

If all user stories are estimated and implemented by the very same person, than the rule should apply: The higher the story points, the more time had been invested (effort).

But we work in teams and as we know, we all have different working speeds. This is the reason why we use story points instead of time estimates. And story points work always in relation to other stories (relative estimation), means „smaller, same or bigger as the other story“. Thus, next time when you estimate ask yourself this question:

„If I had to implement this story all by myself, but I could use all the tools that are available to my team, would it take longer, shorter or as long as the reference story?“

But immediately you will say „But I can not use those tools“ or „I lack the process/domain knowledge etc.“. True – BUT this is true for all stories and therefore (because we estimate by comparing stories) cancels out of the estimation. To estimate „smaller, same or bigger“ you only need to ask those team members who know how to use the tools or have the knowledge. If they say „its less than the other story“ than this holds true if you would do the job.

One final word regarding risk or beeing unsure. It is always good to finish stuff faster. Problems arise (for the PO) if we under estimate tasks. Thus if you feel unsure, it is a good idea to think about the realistic worst case scenario and compare that with the reference story.

 

Vortrag zu Responsive Design by Kent Beck

Ich schaue gerade Kent Becks Vortrag zu Responsive Design an und versuche hier mal meine Gedanken zu den Thema nieder zu schreiben. Hier der Link:

http://www.infoq.com/presentations/responsive-design

Die Seite sieht etwas unübersichtlich aus. Nicht sofort zu erkennen war, dass das Video links nicht alles ist, sondern rechts daneben die Vortragsfolien parallel zum Video umschalten. Also nicht einfach (wie gewohnt) das Video in den Vollbildmodus schalten.

Retrospektive mit Karteikarten

Das sollte man auf Arbeit mal unseren Vordenkern vorschlagen. Hier wendete Kent das „Continuos Improvement“ Pattern auf sich selbst an. Wer macht das eigentlich sonst noch. Häufig wird herzlich gestritten, eine Lösung gefunden und schnell wieder an die Arbeit gegangen. Aber zu dokumentieren warum gestritten/um eine Lösung gerungen wurde und wie und warum das Ergebnis ist wie es ist, das passiert sehr selten. Wahrscheinlich einer der Gründe wieso Kent Beck ein so gefragter Entwickler ist. Er macht nicht nur, sondern er denkt auch darüber nach wieso er es so macht.

Designprinzipien

Kent erwähnt Designprinzipien als Leitfaden für die Entwicklung eines Softwaresystems. Ich kann das nur bestätigen und merke leider immer wieder, dass genau diese bei der Arbeit zwar allen bekannt sind, jedoch häufig nicht dokumentiert werden. Wenn dann Jahre später die ursprünglichen Programmierer weg sind und andere an dem System arbeiten (und andere Prinzipien anwenden) entsteht schnell schlecht wartbarer Code, da Entscheidungen nicht konsistent weiter geführt werden.

Problemlösungs- / Refactoringstrategien

Leap – Sprung

So wie ich Kent verstehe ist der Leap der gefährlichste, jedoch auch schnellste Weg eine Änderung zu erreichen. Solange ich glaube(!) es schaffen zu können sollte ich den Leap versuchen. Sobald ich aber (unterwegs) unsicher werde und das System nicht mehr läuft, gehe ich zurück zum Startpunkt und versuche eine alternative Methode. Kent bringt als Beispiel eine Anwendung wo er sein Designprinzip „Streams statt Filenames“ verletzt hatte. Er wollte nun die Filenames durch Streams ersetzen. Da er 4-5 Klassen anpassen musste ging er davon aus, dass er das so hinbekommt, und wagte den Sprung (Leap). Als er merkte, dass es zu undurchsichtig wurde, änderte er alles wieder zurück und versuchte einen anderen Ansatz.
Interessant war, dass Kent Beck, Author von JUnit, hier zugegeben hat, dass auch bei ihm hin und wieder keine gute Testabdeckung vorkommt. Um überhaupt zu wissen, ob ein Leap erfolgreich war, braucht man Testabdeckung. „Refactoring nur unter Testcoverage“ sollte jedem als Prinzip bekannt sein.

Parallel – Redundanz

Bei Parallel wird ein „zweiter Weg“ ein Problem zu lösen neben den aktuellen (nicht mehr gewollten) gestellt.
Kent bringt wieder das Beispiel „Ersetzen von Filenames durch Streams“. Hier kann man sich vorstellen, dass solch eine Änderung an diversen Stellen in einem SW System schnell unübersichtlich wird.
Kent sagt nun, dass die Parallel-Entwicklung ein sichererer Weg ist. Das kann man so hinnehmen, ich frage mich aber „An welchem Ende des Systems sollte man mit der Umstellung auf Streams beginnen“?

Ich glaube das man vom Ende her beginnen sollte. Also dort wo aktuell die Filenames aufgelöst und die Inhalte gelesen werden, schreibt man eine zweite Methode, welche einen Stream benutzt und zieht die Business-Logik dahin um. Man weiß, dass die Logik funktioniert. Einzig neuer Punkt ist nun, dass Streams statt File-Operationen genutzt werden. Tritt ein Fehler auf weiß man genau, wo man suchen muss. Alle anderen Klassen arbeiten weiter mit Filenames und rufen auch an meiner Klasse die alte Methode mit Filename auf. Die Alte Methode ist aktuell quasi leer. Statt dessen schreibe ich nun dort den Code zum umwandeln eines Filenames in einen Stream hinein und rufe meine neue Methode. Nachdem das alles funktioniert gehe ich zur der Klasse welche meine alte Methode aufruft und schreibe dort eine alternative Methode mit Streams. Diese kann jedoch sofort die neue Methode nutzen. Damit ist die alte Methode an der ersten Klasse nun nutzlos geworden und kann entfernt werden. So gehe ich schritt für Schritt voran und stelle den Code um.

Stepping Stones – Zwischenschritte

Wirklich klar wird das Prinzip durch die Phrase „Wenn ich XYZ hätte, wäre das nicht so schwer“. In so einem Fall baut man sich ein XYZ und macht dann weiter. Notfalls stellt man das XYZ erstmal neben (Parallel) den restlichen Code.
Stepping Stones können leicht overdesigned werden. Also KISS anwenden.

Simplification

Kernidee hier ist: Auf welche primitive Form kann ich das Problem eindampfen? Wenn ich z.B. die Aufgabe habe einen Differentialgleichungs-Löser zu schreiben, der mit bis zu 20 unbekannten arbeiten kann, dann wäre es eine gute Idee mit einem zu beginnen wo keine unbekannte enthalten ist. Und dann einen mit einer Unbekannten. Und dann einen mit zwei. Und dann fällt dabei fast schon von alleine der mit n Unbekannten hinten ab.

Successions – Abfolgen

Die restlichen Folien werden sehr schnell abgehandelt. Von Interesse fand ich die Idee der Successions. Kent vermutet, dass es bei der Arbeit immer wieder Schritte gibt die man nach und nach durchführt um erfolgreich zu sein. Eine dieser Abfolgen ist das bei Simplification erwähnte Prinzip erst „Eine Lösung für 1 Element herzustellen und dieses dann auf mehrere Elemente zu erweitern“ (First One – Than Many). Kent vermutet, dass es noch weitere solcher allgemeinen Abfolgen gibt.

Schlussfolgerung

Ein Vortrag den man sich durchaus mal anschauen sollte.

Nebenberufliches – Als Händler bei Amazon verkaufen

Ich bin mal wieder geschäftlich aktiv geworden. In meinem letzten Beitrag habe ich beschrieben, wie ich Podcasts für mich entdeckt habe. Im Oktober habe ich, Urlaub sei Dank, Zeit gefunden, davon etwas in die Tat umzusetzen. Herausgekommen ist das hier:

Logo

Ich habe mich bei Amazon als Händler angemeldet und verkaufe nun Produkte dort. Damit ich am Ball bleibe und eventuell noch weitere Interessenten finde, habe ich auf FBAinGermany.com einen Blog eingerichtet, auf dem ich meine Fortschritte dokumentiere und über FBA und was funktioniert berichte. Über RSS-Abonenten würde ich mich freuen. Ich versuche wöchentlich meinen Fortschritt zu dokumentieren. Wer noch nie von FBA bzw. dem „Versand durch Amazon“ Modell gehört hat, kann zum Beispiel diesen Artikel über das FBA Geschäftsmodell lesen.

2015 – Rückblick auf das erste Halbjahr

Ich bin gerade wieder zu Hause eingetroffen und ich hab überlegt was dieses Jahr eigentlich alles bei mir so passiert ist. 2015 ist vollgepackt mit interessanten neuen Dingen und dabei ist gerade erst die Hälfte vorrüber.

Da ich seit Anfang letzten Jahres am Ende einer jeden Woche einen Einzeiler schreibe, was ich diese Woche gelernt oder gemacht habe um meinen persönlichen Zielen etwas näher zu kommen, kann ich recht gut nachvollziehen wann die entscheidenden Entdeckungen bei mir eintraten.

Das Jahr begann direkt mit einem besonderen Thema. In der zweiten Kalenderwoche hielt ich einen Vortrag an der TU Chemnitz zum Thema „Agile Softwareentwicklung in der Praxis“. Das Ganze hatte ich letztes Jahr noch eingefädelt und fasste meine Erfahrungen aus meinem letztjährigen Projekt zusammen.

Von Jahresbeginn an, habe ich einen Wettbewerb mit Phobeus von DelphiGL.com laufen, wer sich mehr bewegt/aktiver ist. Es geht dabei nicht zuletzt um das Thema abnehmen und Fitness. Ich kann mit stolz behaupten, dass ich bisher in jeder Woche des Jahres zumindest 500 Treppenstufen gegangen und/oder Sport gemacht habe.

Das erste Quartal war dann beruflich ziemlich interessant und fordernd. Ich habe als Transformation Manager zusammen mit meinem Projektmanager das größte Softwareprojekt bei unserem Kunden (öffentlicher Sektor) auf agile SW-Entwicklung umgestellt. Ich habe einen Meilensteinplan aufgestellt, Arbeitsprodukte definiert und mit einem kleinen Team von Teilzeitkräften des Kunden diesen Plan in die Tat umgesetzt. (Das ging natürlich nur durch die Mithilfe meines Projektmanagers der die Entscheidungsträger hin und wieder auch zum Entscheiden bringen muss.) Nicht nur lief die Transformation recht reibungslos ab, es wurde ganz nebenbei noch eine zweiwöchige Periode mit Schulungen und Workshops abgehalten, in der die Wissensträger aus dem Projekt die neuen Tools und Methoden aber auch Arbeitspraktiken und BestPractises vorgestellt haben. Während dieser Workshopwoche hielten wir beim Kunden das erste Code Retreat ab, bei dem ich merkte wie nützlich diese Form der Übung ist um neues zu lernen und um heraus zu finden auf welchem Level die Kollegen arbeiten.

In diesem Zeitraum habe ich das Buch „Clean Code“ von Robert C. Martin gelesen. Das traf sich gut, denn ein Mitarbeiter des Kunden beschäftigte sich mit dem selben Thema und war mindestens so wissensdurstig wie ich (das merkte man daran, dass wir uns gegenseitig ständig Videos/Vorträge empfahlen und die Woche darauf dann tatsächlich die Inhalte diskutierten). Ein großes Thema war natürlich Clean Code und Craftsmanship. Für mich jedoch auch Kanban (David J Anderson) und Lean (Don Reinertsen)

Dann kam die Zeit wo ich meinen Firmenwagen abgeben musste (Leasingende). Bis dahin war ich mit einem BMW 320d ed unterwegs. Das Auto war Klasse und ich habe ihn gern gefahren – insbesondere da ich ihn zu einer extrem niedrige Rate bekommen hatte (könnt ihr euch noch an die Automobilkriese 2009/2010 erinnern…?) Ich brauchte also einen neuen Untersatz der mich sicher und bequem jede Woche 600km nach Berlin und zurück bringt. Nach intensiven Excel-Rechnungen merkte ich, dass ich zu den Kosten eines neuen Firmenwagens auch ein ordentliches Langstreckenfahrzeug privat beschaffen kann. In Kalenderwoche 11 fuhr ich dann nach Mannheim und kaufte meinen gebrauchten Phaeton – was den ein oder anderen Kollegen im Projekt für Wochen in puren Unglauben verharren ließ.

Im zweiten Quartal war die Transformation beim Kunden durchgeführt und die praktische Arbeit fing an. Ich übernahm die Rolle des Scrummasters eines extrem introvertierten Teams und musste lernen, dass es nicht ausreicht, Menschen, die am selben Projekt arbeiten, zusammen in einen Raum zu bringen, damit diese miteinander reden. Da ich als Scrummaster selbst nicht mehr programmiere juckte es mir in den Fingern und ich versuchte mich in Android-App Entwicklung einzuarbeiten. Jedoch fehlte mir da die Ausdauer und das Thema ist nach 3 Wochen wieder eingeschlafen.
Nicht eingeschlafen ist ein Projekt, welches ich mit Marcel (dem Clean Code Kollegen) startete: Aus einem Vortrag/Workshop in den Workshopwochen entstand die „Java Community of Practise“ beim Kunden. Motivierte Entwickler welche interesse an Clean Code hatten trafen sich um zusammen ihr Können und Wissen zu vetiefen. Da wir keinen Zugriff auf Youtube vom Arbeitsplatz aus hatten, brachte ich Videos auf meinem Laptop mit, damit wir die in der Java CoP anschauen und diskutieren konnten. Passend dazu war meine Literatur zu dieser Zeit „The Pragmatic Programmer. From Journeyman to Master„.

Einige Kollegen spielten regelmäßig Beachvolleyball (zu der Zeit noch in der Halle. In Berlin gibts da wohl ein paar Möglichkeiten) und ich wurde dann mal mit eingeladen und so zumindest einmal pro Woche aktiv.

Ihr seht, dass ich echt einen vollen Terminkalender habe. Damit ich nicht komplett untergehe, habe ich mir eine Technik überlegt um mich mental auf den jeweils nächsten Arbeitstag vorzubereiten. Und zwar mache ich einen Tagesplan auf Papier (das sieht dann ungefähr genauso aus, wie das was Lotus Notes oder Outlook oder Lighning anzeigen würde) und trage in den freien Zeitslots Tätigkeiten ein, welche ich noch machen muss. Dadurch weiß ich am nächsten Morgen schon beim Frühstück, ob ich früher da sein muss, oder mir Zeit lassen kann, und ich kann ohne den Rechner hoch zu fahren, meinen Kalender einsehen, wenn ich direkt vom Auto in ein Meeting muss.

Das zentrale finanzielle Ziel für mich ist dieses Jahr der Aufbau von Assets (Frei nach Robert Kyosaki sind Assets all jene Dinge die schlussendlich Geld verdienen.) Da ich mich schon länger mit Immobilien beschäftige hatte ich am Beginn des zweiten Quartals zwei Zwangsversteigerungen im Auge, welche ich interessant fand. Ich organisierte durch Kollegen einen freien Finanzberater der die Finanzierung klärte, arbeitete mich wieder in die Abläufe und gepflogenheiten von Zwangsversteigerungen ein und musste dann feststellen, dass beim Versteigerungstermin auch Menschen aufschlagen die Objekte um jeden Preis haben wollen. Ich kam also nicht zum Zuge, hatte aber in der Zwischenzeit andere interessante Objekte im Internet entdeckt und nach zähem verhandeln ein gutes Angebot herausdestiliert. Das Immobilienthema beschäftigt mich seit her und ich hoffe in Q3 den Deal dicht zu machen.

Aber Investieren kann man auch in andere Dinge und in KW 21 strandete ich bei der Suche nach Vorträgen beim Thema Value Investing. Ich kam dann über den Google Talk zu Deep Value Investing bei „The Investor’s Podcast“ heraus. Und damit startete eine Episode ausgedehnten Lernens durch Podcasts (ich nutze die Android-App „Sticher“ dafür). Im Investor’s Podcast wurde dann Pat Flynn von „Smartpassiveincome.com“ interviewed. Er erwähnte wie er online Assets baut und sein Track-Record (siehe rechts oben auf seiner Seite) ist wirklich eindrucksvoll. Dreimal dürft ihr Raten womit der Kevin die nächsten Wochen verbracht hat. Ich war angefixt und vertiefte mich in SEO, Online-Marketing, Outsourcing und Nischen-Seiten. So kam ich dann auch zu meinem dritten Podcast: nichepursuits.com
Podcasts sind wirklich toll. Ich habe in den folgenden 5 Kalenderwochen extrem viel gelernt und bin mit Ideen konfrontiert worden, welche ich in meinem dirkten Umfeld nicht bekommen hätte. Alleine dafür sind Podcasts super. Mittlerweile habe ich auch den Tim Ferris Podcast aboniert – wer mich kennt weiß, dass ich jedem seine Bücher ans Herz lege.

Aus dem Buch „Think&Grow Rich“ (Ein Klassiker aus den 1930er Jahren) kannte ich das Konzept der „Mastermind-Gruppe„. Da ich bemerkte, dass viele erfolgreiche Web-Unternehmer solche Gruppen haben, wollte ich versuchen so etwas auch aufzubauen.

Zum Abschluss des zweiten Quartals kam dann noch ein Highlight. Ich war gerade in der Online-Asset/Passives Einkommen Phase und entschloss zum 4HWW-Meetup in Berlin zu gehen. Plötzlich war ich in dieser Umgebung wo alle Anderen über das selbe Thema nachdachten und man sich gegenseitig pusht um voran zu kommen. Da war ich definitiv nicht das letzte mal.

Soviel zum ersten Halbjahr 2015.

Nobody can guarantee security, you can only guarantee freedom.

Currently, only short after the attack on Charlie Hebdo, the people in power are discussing again, if they should revoke some of the freedom and rights of the people they rule. Why? To reestablish the feeling of security.

There are three aspects in this, that should all believers in a society of free and equal individuals alarm. I explain them below.

  1. You can not guarantee security, only freedom.
  2. There is no such thing like absolute security.
  3. The principle of separation of powers is under attack.

You can not guarantee security, because security is a „negative concept“, means it is defined by the absence of fear of one’s live, property and family. But you can not guarantee this anymore. Since the moment mankind invented distance weapons (like bow and arrow) or later biological weapons etc. you can never be sure that nobody can harm you. What a state can guarantee is prosecution! That no attacker shall get away without punishment. Collecting data of all people, instead of concrete suspicious people, is not a service but an attack on our culture.
Freedom, in the contrary, is an active service of the state. A state can guarantee the he will not act against somebody in a certain case, thus creating a freedom. States can only guarantee things, they do themselves, like not prosecuting a behavior.

There is no such thing like absolute security. There is only a „feeling of security“. Something bad could happen all the time, and everybody you ask will know this. But events, like terrorist attacks, are meant to destroy this feeling of security (this is what terror means!). If we give up freedoms and rights to reestablish the feeling of security, we gain no permanent salvation. The next attack will happen and destroy the feeling again, leaving us without the feeling and the rights.

The principle of separation of powers is under attack. Our rights and freedoms help guarantee separation of powers. There is a constant tension between those who execute powers, and those who control them. Our societies are build in a way to keep this tension alive with independent courts, executive powers that will execute laws also on legislative members, opposition parties that have insight in current legislation threads and a free press that informs the public about whats going one. Finally, and this is something all Germans should remind the world about, those separations and information have the goal to enable the public to stop malicious governments by revolting and resetting the system. But the same systems that are currently discussed to protect the state and the citizens from attackers/terrorists that hide among us, will serve as tools to stop uprisings, if politics are no longer in line with the needs of the people. So every time people vote „yes“ for surveillance, they reduce there chances of stopping out of control institutions. (Some say, the NSA is already exactly this …)