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()

Kennzeichnungspflicht für Social Bots

Breaking News: Die Bundesregierung erwägt Kennzeichnungspflicht für Social Bots

Social Media Bots sollen sich zu erkennen geben und mitteilen, dass sie keine echten Menschen sind, sondern Automaten, die nur Meinungen multiplizieren. Sie sollen gekennzeichnet werden, damit Leser unterscheiden können, ob das eine Diskussion zwischen Menschen ist oder nur - meistens gegen Geld - Meinungen beeinflusst werden sollen. Das kennt man schon von Werbung, die gekennzeichnet werden muss, damit man sie von redaktionellem Inhalt unterscheiden kann.

Das ist sehr sinnvoll und richtig.

Und weil das so sinnvoll und richtig ist, wurde das schon mal vorgeschlagen. Vor ziemlich genau 10 Jahren: Bot Tagging.

Da hat sich schon mal jemand Gedanken darüber gemacht dass man Menschen (Chatter) in Chatsystemen nicht hinters Licht führen sollte indem man Bots programmiert, die sich als Benutzer ausgeben.

Es gibt Bots, die Werbung machen, Bots die unterhalten und heutzutage sogar Bots, die lügen und Fake-News verbreiten. Letztlich ist politische Beeinflussung durch Bots auch nur politische Werbung in einer besonders ansprechenden vertrauenswürdigen und damit hinterhältigen Form.

Da es so viele verschiedene Bot-Arten gibt, sollte es ein Kennzeichnungssystem geben, das mehr aussagt, als Bot JA/NEIN. Man will wissen
- ob der Bot kommerzielle Werbung macht oder politische,
- ob er der Unterhaltung dient oder eine Servicefunktion erfüllt,
- ob er jugendfrei ist oder - allgemeiner ausgedrückt: die Kennzeichnung braucht auch eine Altersfreigabe.

Schön wäre auch die Angabe eines Themas. Dafür bräuchte man eine Ontologie. Die müsste man sich nicht selbst ausdenken. Der Verweis auf ein bestehendes Verzeichnissystem würde reichen, z.B. Wikikedia-Begriffe als Vokabular oder etwas hierarchisches, wie das (leider eingestellte Open Directory Project oder hier).

Das alles steht in der "Virtual Presence Technical Note 5: Bot Tagging", weil wir bei Weblin das schon damals gesehen haben.

_happy_tagging()

CSV im US Format im Excel öffnen (Komma statt Semikolon) - Systemsprache kurzfristig umstellen

tl;dr: Systemsprache kurzfristig umstellen. Powershell: "Set-Culture en-US" und zurück: "Set-Culture de-DE"

Man bekommt immer wieder mal CSV-Dateien im US-Format. Die enthalten Komma statt Semikolon als Trennzeichen. Ein deutsches Excel will das nicht anständig öffnen.

Was tun?

Man kann:

• das CSV als Textdatei öffnen und "," durch ";" ersetzen (viel Spaß mit "," in den Daten)
• das CSV in .txt umbenennen und im Excel importieren und dabei as Komma als Trennzeichen angeben

Oder: man stellt einfach kurz die Systemsprache um durch ein Powershell Kommando (Commandlet). 

So geht's:

• Powershell öffnen
• PS C:\> Get-Culture (liefert: de-DE)
• PS C:\> Set-Culture en-US
• CSV öffnen durch Doppelklick
• PS C:\> Set-Culture de-DE
• Powershell schließen (oder offen lassen, braucht man immer mal)

Voila, englisches (US) CSV importiert.

(Wenn man es jetzt als CVS speichert, hat man ein englisches CSV in ein deutsches konvertiert).

Kleine Verbesserung (vorherige Einstellung transparent wiederherstellen):

• PS C:\> $c=Get-Culture; Set-Culture en-US
• CSV öffnen/bearbeiten
• PS C:\> Set-Culture $c

Oder man legt sich diese 2 auf das Desktop:

1. Dateiname: EN.bat
   Inhalt: powershell.exe -Command "Set-Culture en-US"
2. Dateiname: DE.bat
   Inhalt: powershell.exe -Command "Set-Culture de-DE"

_happy_converting()

CSS Customize Visual Studio Online Task Board - Remove Columns And Make it Denser

I use Visual Studio Online task board a lot for Scrum projects. But I do not like how much screen space it takes primarily because of lots of empty space.

So, I remove the empty space:

• I do not need the "To be tested" and "Testing" columns.
• The cards could be smaller with less margins and paddings

That's it.

I use Tampermonkey to inject CSS into the page.

Just install the Tampermonkey Chrome/Firefox extension and use this script:

Before/After:

More info, less white (grey) space.

_happy_tampering()

PS: Once you have Tampermonkey you will see lots of opportunities to change the layout of web sites. You don't have to live with it. You can change it.

For example: a script which make visual studio build colors more pronounced to counter my red-green-color weakness:

JsonPath

Any time a piece of my software receives a JSON message it must dive into the JSON and extract parameters. Sometimes the JSON is deeply nested and parameters are buried inside arrays of objects of arrays.

I want to access these parameters quickly without dissecting the JSON by looping and if-ing through the layers. In other words: I want single line expressions to dive into JSON and extract values.

You can call it XPath for JSON, but in a language integrated and compiled way, which is much faster, than XPath and supported by Intellisense (autocomplete).

GitHub project: https://github.com/wolfspelz/JsonPath
NuGet package: https://www.nuget.org/packages/JsonPath

Example: extract the 42 from:

var data = "[ '1st', '2nd', { 'aString': 'Hello World', 'aNumber': 42 } ]"

... parse it:

var json = new Node(data);

... extract it:

int fourtytwo = json[2]["aNumber"];

Invalid keys do not throw exceptions. They return 0 (zero), "" (empty string), or empty list:

int zero = json[1000]["noNumber"];

Of course, you can foreach a dictionary (aka JS object):

foreach (var pair in json[2]) {}

And iterate over a list (aka JS array):

for (int i = 0; i < json.Count; i++) {
    string value = json[i];
}

You can even LINQ it:

json[2].Where(pair => pair.Key == "aNumber").First().Value

and:

(from x in json[2] where x.Key == "aNumber" select x.Value).First()

Now get me the 50 from this JSON:

var data = "[ { 
        aInt: 41, 
        bLong: 42000000000, 
        cBool: true, 
        dString: '43', 
        eFloat: 3.14159265358979323 
    }, { 
        fInt: 44, 
        gLong: 45000000000, 
        hString: "46"
    }, { 
        iList: [ 
            { jInt: 47, kString: '48' }, 
            { lInt: 49, mString: '50' }
        ], 
    }
]";

I can do it in a single line, no foreach no if:

var fifty = json[2]["iList"][1]["mString"];

Other people had the same idea years ago: http://goessner.net/articles/JsonPath/. But there does not seem to be a C#/.NET implementation yet. So here it is: GitHub, nuget.

_happy_jsoning()

Scrum Gantt als Google Docs Sheet

Im letzten Post zum "Scrum Gantt-Chart" habe ich beschrieben was, warum und wie man aus Scrum-Daten ein Scrum-Gantt als Reporting-Tool erzeugt. Die Scrum-Planung ist weiterhin im Scrum-Backlog, aber das Management (allgemein: die Stakeholder) freut sich sicher über eine Roadmap im Gantt-Stil.

=> Implementierung das Gantt-Charts als Google Docs Sheet <=

Empfehlung:

• Sheet kopieren: GoogleDocs => Datei => Kopie erstellen...
• Das eigene Backlog im Eingabebereich auf der linken Seite einfügen
• Datum "BaseDate" und "Today" anpassen
• Zeilen und Spalten im Formelbereich an das eigene Backlog anpassen
• Jede Woche eine neue Version machen und den Stakeholdern veröffentlichen

Wenn die Spalten des eigenen Backlogs kompatibel sind, ist das eine Sache von 2 Minuten

==> Google Sheet

_happy_sheeting(:-)

First GIF Movie Ever Was a Star Trek clip

This is the first GIF-Movie ever shown on the World Wide Web in a web browser.

In 1995, I convinced the browser company Netscape to support GIF animations. It appeared in Netscape Navigator 2.0 as a hidden feature. The big marketing features where Javascript, Frames and Server-Push. But it also had animated GIF.

To test it, I needed a long GIF-stream. 1 MB was considered big and long at the time. And I thought it needs some style and not just a boring test image with test data. So, I extracted frames from a short QuickTime Star Trek movie and created the first GIF movie for the Web.

Then we used the feature to create the first Web Live Video Stream ever. It showed a model railway setup at University of Ulm, Germany.

First Live Video at a time where "live cam" meant "please reload the page to fetch a new image".

The live GIF feed was also used to implement the first live chat when "chat feed" meant "please reload the page to get new lines".

That's many firsts. Going where no one has gone before is my hobby. That movie fit.

_happy_going_where_noone_has_gone_before()