A Coders Take on BREXIT: The Lupus Solution

Usually I avoid politics and that's what I also do in this post. No opinion, I am actually 50:50 anyway. I am enjoying the show. This is purely technical.

In short: EU article 50 is a timer. It can be cancelled and restarted any time. Just like the programming timers we know. So, the solution is exactly what we do in programming: cancel and restart.

On 4 December 2018, the responsible Advocate General to the ECJ published his preliminary opinion that "a country could unilaterally cancel its withdrawal from the EU should it wish to do so, by simple notice, prior to actual departure".

Meaning, that the UK can cancel Brexit any time. But the UK can also restart Brexit at any time again. There are no time limits, no grace periods, no rate limiting on article 50 cancelling and triggering.

That makes the solution obvious: send two letters to the EU back to back.

• the first with the cancellation of the article 50 process,
• the second with a new trigger of article 50. 

(In practice you would play it safe and leave one day between cancel and reset.)

The result would be (almost) the same as the already planned 2 year  transition period. The March 2019 date is only the legal departure date. for all practical purposes, the UK leaves 2 years later after the transition period (December 2020). Let's get rid of the transition period and call it a second article 50 process, another two years. Practical separation would then be March 2021, only 3 months later than already planned.

Just make a law in parliament to cancel article 50 AND trigger it immediately again. 

Gives you time for a referendum or a general election or just a good transition period. Anything you want. Gives you time and changes nothing. The move just gets rid of the threatening no-deal timer.

Bonus: an extension of article 50 requires the agreement of all EU members. But the cancel/restart-move can be done by the UK alone.

Bonus Bonus: 2 years transition is what the Brits wanted, but the EU wanted a clean end of year date. So they settled for 21 months. A simple timer reset makes that 24 months again. Owned!

The ECJ handed this solution to the UK. They know what they do. This was not an accident. They mean it. That's the way out. Just do what every programmer does with timers: reset.

_happy_resetting()

PS: it's clearly an exploit and a bit shady. But it's legal. The contract is not meant to be used this way. But many contracts are "stretched". What happened to "no bailout" in the Euro zone? Giving Greece money to be (maybe) payed back in 50 years, is a stretch. What happened to the "prohibition of monetary financing"? Ah, yes, The ECB buys government bonds not directly from he governments, but from the "secondary markets". The ECB so much that the "intermediate" banks are actually straw men, being paid to circumvent Article 123. Another stretch. So, contracts are stretched, if deemed necessary. All we have, unfortunately, is the written word. The written words allow it AND it's necessary.

PPS: If people ever wanted to make exploit proof contracts and laws, then they could ask the gaming industry for advice. They have thousands of specialists who make a living by preventing the exploitation of coded rules. If computer games as an example are too low for you, then ask IT security experts or turn to academics in the field of game theory, the study of mathematical models of strategic interaction between rational decision-makers.

PPPS: In the long run: if you can do it twice, then think n+1. We can do this every other year. Maybe the UK and EU get used to it. Gives the UK a feeling of independence. And that's what it's all about, anyway. Every two years, UK activates article 50 and cancels it two years later. In practice: every other year, Brussels receives a briefcase with 2 letters from London. Could be a nice tradition in the long run. A typically British exception from EU rules.

Agile mit Super Powers

Superboys: Edict-Abhilekh on Pixabay

tl;dr Scrum Rollen superpowern: Es gibt viel zu tun. Deshalb muss man Fähigkeiten zusammenlegen: Scrum-Master coacht auch agile Technologien, Product Owner macht UX-Design, Visual-Designer kann Frontend-Programmierung, Entwicklungsleiter ist Technik-Coach für Product Owner.

In der realen Welt haben wir mehr Rollen, als die bekannten Scrum-Rollen: Scrum Master, Product Owner und Entwicklerin.

Außerdem gibt's da noch:

• Tester, die Test-Ingenieure sein sollten, nicht Durchklicker, sondern Integration-Test-Entwickler und Test-System Managerinnen,  
• Admins, früher Operator, jetzt Devops, also Devs mit Leidenschaft für Betrieb, 
• Systemarchitektinnen, die sich oft aus den Entwicklern rekrutieren und auf jeden Fall aktiv in den Entwicklungsteam sein sollten, vielleicht organisiert in Communities of Practice, aka Chapters, 
• UX-Designer, ständig ein bisschen gebraucht, denn bei jedem Feature mit Business-Value für Benutzerinnen ist UX wichtig, 
• Visual-Designer, soll ja auch gut aussehen, oft zwischen mehreren Teams geteilt oder sogar extern bei einer Agentur oder beim Auftraggeber. Burst-artige Arbeitslast und deshalb immer in der Gefahr, die Entwicklung aufzuhalten. 
• Produkt Managerin, die auch gewillt ist mit dem Agile-Team ins Eingemachte zu gehen und zusammen was umzusetzen. Phantastisch, wenn sie nicht aufhört bei Marktpotential/Marktbeobachtung und Anforderungen, sondern selbst die User Stories scheibt. 
• Marketing, Vertrieb, Controlling, Management… sind auch nötig, damit was geht, schon klar.

Von den Entwicklerinnen verlangt man heute viele Fähigkeiten:

• Frontend und Backend, jeweils mit ihren aktuellen (und schnell wechselnden) Frameworks, 
• Unit Tests ohne Zeit-Overhead während des Codings "einfließen" zu lassen, 
• Integration-Tests und GUI-Tests aufzusetzen und up-to date zu halten während sich UX Workflows ändern, 
• Beherrschung von Continuous Integration/Deployment Systemen, 
• Container und Orchestrierung, 
• Virtuose Bedienung von Code Repositories für Quellcode, Pakete, Container (Stichworte: GitFlow, nuget/PEAR, Dockerhub). Nicht nur benutzen, sondern auch bereitstellen, intern und extern. 
• Code Reviews und Refactoring
• Code-Metriken
• Kenntnis und Benutzung von Monitoring-Systemen für Alarm, Dashboard und KPIs, 
• Clean Code, Design Patterns, Entwicklungsumgebungen und deren Extensions, 
• Security (in Code, Libraries aus Repos?, Operating), 
• Reliability-Engineering, 
• Skalierung (Up and Out)
• Konfiguration der APIs und GUIs diverser Cloud-Anbieter und Meta-Cloud-Services, 

usw.

Unter den Entwicklern gibt es Spezialisten für das alles. Aber nehmen wir ein Team von 7, (UX-) Designer, Tester, Admin (ähm, Devops), Frontendler, Backenderin. Eigentlich sollen alle alles können, aber nicht jede, die Microservices containerisiert ist gleichzeitig ein CSS3-Wizard. Dann wird es langsam eng mit den oben genannten Spezialfertigkeiten. Coden sollen sie ja auch noch. 

Warum machen wir das alles?

Damit Features entstehen. Features, die User glücklich machen. Features entstehen durch Coding. Ohne Coding keine Features. Viel Coding - viele Features, wenn sonst alles stimmt.

Fragt man in der Retro "was hat dich in diesem Sprint vom Coden abgehalten?" - typische Antwort: "Meetings", aber auch immer öfter "Infrastruktur" und vor allem: Infrastruktur aneignen, neu lernen und verstehen. 

Ganz viel dieser Infrastruktur macht uns agil bzw. ist nötig für agile Arbeitsweise über Scrum/Kanban hinaus:  Continuous-*, Container, Cloud, Clean Code, Frameworks, Repositories…

Die Infrastruktur hat gemeinsam: Sie ist aufwändig für jede einzeln zu lernen, aber notwendig, und wenn erstmal gelernt, dann völlig OK. Aber bis dahin dauert es.

Man kann das nicht alles den Entwicklern aufbürden, deshalb verteilen wir das:

Superpower #1: Agile-Coach mit agiler Technologie

Es könnte/sollte/müsste die Aufgabe des Scrum-Masters sein, agile Technologien in das Team zu tragen, so wie auch agile Arbeitsweisen in das Team getragen werden. Natürlich soll die Scrum-Masterin nicht dauerhaft den Build-Server betreuen (obwohl sie das kann, wenn sie mehrere Hüte aufhaben will/kann/soll). Es geht darum, dass der Agile-Coach das Wissen in das Team trägt, damit nicht immer wieder wertvolle Entwicklerzeit darauf verwendet wird, zu lernen, wie man einen KPI-gesteuerten Continuous Deploment Prozess konfiguriert. Und wenn wir schon dabei sind: Es ist auch die Aufgabe des Agile-Coaches, die Beschäftigung mit Clean-Code und Design-Patterns zu stimulieren, vielleicht sogar selbst zu schulen, zumindest aber die Seniors dazu zu bringen, dass sie ihr Wissen teilen. Aber dazu muss man wissen, was es zu teilen gibt. Sorry, liebe SMs aus dem Persönlichkeitscoaching, eine agil-technische Scrum Masterin macht das Team nicht nur glücklicher, sondern auch schneller, viel schneller. Und mit "schnell" kommt dann auch "glücklich": Superpowered Scrum-Master.

Superpower #2: Product Owner mit UX-Design

Bei allen Features mit Business-Value für Endbenutzer ist UX wichtig. Coding ist dafür da, dass die Funktion funktioniert. Aber "glücklich" werden Benutzer durch gutes UX-Design, nicht nur schöne GUIs, sondern vor allem gute Workflows. Ein Product Owner gießt die Stakeholder-Anforderungen in User Stories. Bei fast jeder Story ist UX-Design nötig, zumindest Grundkenntnisse, besser umfassende. Eine gute UX-Designerin kann lernen, wie man User Stories schreibt und vielleicht sogar wie man mit Stakeholdern redet. Aber ob ein Product Owner UX lernt? UX-Design ist ein Beruf und gottgleiches User-Story Schreiben eine Berufung. Erst die klassische Ausbildung: gute Anwendungen entwerfen, dann die agile Spezialfähigkeit: User Stories und Kommunikation: Superpowered Product Owner.

...und weil wir schon dabei sind. Das wäre auch toll:

Superpower #3: Visual-Designer mit Frontend-Programmierung

Wenn die Visual-Designerin gut ist, wird die Anwendung schön. Wenn sie das, was designed wurde, auch umsetzen kann, ist es toll für alle. Denn dann muss sie das Design nicht an den Entwickler übergeben. Es gibt keine Rückfragen, keine Verzögerung, keinen Mind-Bruch. Sie kann beim Design gleich die technischen Randbedingungen berücksichtigen. Keiner muss der CSS-Sklave für die Designerin sein. Die Arbeitslast ist viel ausgeglichener, so dass man kann sich eine ganze Designerin exklusiv pro Team leisten jund nicht mehr UX-Designer zwischen Teams teilen muss: Superpowered Designer.

Superpower #4: Entwicklungsleiter mit Technik-Coach für Product Owner

Viele Product Owner kommen nicht aus dem technischen Bereich. Das ist gut so, um die Entwicklung mit dem Produktmanagement zu verzahnen. Auf der anderen Seite ist es von Vorteil, wenn die User Stories so geschrieben werden, dass sie 1. in die Gesamtarchitektur passen und 2. die Entwickler verstehen und machen, was gemeint war. Für beide Fälle ist es gut, wenn jemand aus der Technik den Product Owner bei der Formulierung der User Stories berät. Eigentlich sind die Entwicklerinnen die technischen Berater des Product Owners. Aber das kostet Entwicklerzeit, oft von allen. Deshalb bürden wir das lieber der Entwicklungsleiterin auf. Die Entwicklungsleiterin kennt die Gesamtarchitektur, die IT-Strategie und sie versteht wie Entwickler denken. Sie schreibt nicht die Stories um. Nur der PO schreibt User Stories. Aber eine Entwicklungsleiterin kann durch Fragen den Product Owner dazu bringen, die Stories so zu schreiben, dass die Entwickler die Stories verstehen und dass sie in das Gesamtkonzept passen. Eine Stunde pro Woche und Team reicht, um die technische Qualität der User Stories deutlich zu verbessern. Die Entwicklungsleiterin kann so wissen was passiert und gleichzeitig etwas steuern. Die Stunde pro Woche mit dem PO ist das effizienteste Steuerungswerkzeug der agilen Entwicklungsleiterin, ohne den agilen Prozess zu verletzen. 

Heute sind viel mehr Fertigkeiten nötig. Man muss Fähigkeiten zusammenlegen. Nicht nur bei den Entwicklern, denn die sollen entwickeln. Alle müssen mehr machen und mehr können als bisher. 

Niemand hat gesagt, dass Superkräfte einfach sind.

#SuperPoweredAgile

_happy_powering()