Am 27.10.2016 fand das sechste Treffen von agiLE und das erste nach dem Barcamp statt. Es war wie immer nett und zumindest für mich hilfreich – ich denke auch für die übrigen Teilnehmer.

Damit diejenigen, die nur im Geiste bei uns waren, einen Eindruck bekommen, nachfolgend mein streng subjektiver Bericht.

Ich habe an den jeweils ersten, berichteten Sessions teilgenommen. Die “Parallel-Sessions” berichte ich aus dem Zusammenfassungs-Vortrag der Gastgeber bzw. aus den Aufzeichnungen aus den Sessions.

Eröffnung – agile Willkommenskultur

Wir hatten auch schon in der Vergangenheit Kollegen, deren Muttersprache nicht Deutsch ist. Bisher haben wir es so gehalten, dass deutsch oder englisch gesprochen wurde – je nachdem wer sprach – will durcheinander. Default war aber Deutsch. Dieses Mal haben wir zwei neue Agilisten dabei gehabt, die darum gebeten haben, dass wir nach Möglichkeit ganz englisch sprechen. Klar doch – machen wir gern.

Den Blog-Beitrag halte ich dennoch auf Deutsch. Warum?

Zum einen, weil man schriftlich so viel Zeit in Lesen, Übersetzen, Nachschlagen stecken kann, wie man individuell braucht. Es läuft nichts weg.
Die meisten meiner Leser sind aber auf deutsch schneller.
Weiterhin, weil mir das Schreiben auf deutsch schneller von der Hand geht und ich möglichst wenig Zeit für diesen Beitrag aufwenden möchte.
Und der wichtigste Punkt: Herausforderung zum Lernen. So, wie ich Inhalte auf Englisch zum Anlass nehme, meine englischen Sprachfähigkeiten zu verbessern so will ich hiermit für die Kollegen den Anreiz schaffen, ihr Deutsch zu verbessern. Kann man in Deutschland immer mal brauchen … 😉
Oder wie ich meinem portugiesischen Kollegen Rafael einmal sagte, als er mir englisch antwortete: “der einzige Effekt, den das hat ist, dass mein Englisch besser wird – Dein Deutsch aber nicht. Was hat für Dich mehr wert?”

Sessionplanung – jetzt auf englisch

Nach einem kurzen Rückblick auf’s Barcamp haben wir also im üblichen Format die Themen gesammelt und durch Handmeldungen priorisiert. Ergebnis waren 2×2 Durchgänge. Mein Evergreen “Erfolg! Wie messt Ihr den und wie geht Ihr damit um?” kam mal wieder nicht zum Zug. Macht nichts, gab auch andere spannende Themen.

Erster Durchgang: fuck-up-Session

“What was in the fuck-up-session stays in the fuck-up-session”. Wer dazu mehr wissen will ist für die nächsten Male aufgerufen, selbst ein solches Thema anzubieten oder dran teilzunehmen, wenn es angeboten wird.

Parallel: Wie behandle ich Bugs und Fixes während des Sprints?

In Kürze zusammengefasst sind Bugs und Fixes Schulden in der Qualität – nicht in der Funktionalität.

Eine Story, die nicht “done” ist, ist dadurch nicht automatisch “buggy” und umgekehrt. Unfertige Stories werden in den nächsten Sprint übernommen und allokieren dort Umsetzungs-Ressourcen. Unfertig kann die Funktion selbst, aber auch die bis zuletzt nicht grünen Tests sein. “DoD gerissen” ist einfach nicht “done”.
Es kann sich natürlich auch herausstellen, dass ein Thema sich nach tieferer Durchdringung anders darstellt als zunächst angenommen oder durch eine andere Funktion obsolet wird. Dann wird die Story zurückgestellt oder ganz aus dem Backlog genommen. It depends …

Für echte Fehlerbeseitigung oder Implementations-Support (je nach Produkt und Umgebung) müssen Ressourcen bereitgestellt werden! Entweder anteilig für alle (bspw. 15% der Sprint-Kapa) oder es werden pro Sprint einzelne Personen für’s Fixing abgestellt (bspw. “Batman und Robin” bei Entwicklung mit DevOps). Die “Superhelden” wechseln aber bitte von Sprint zu Sprint.

Pause: meterweise Pizza

Unserem Gastgeber Rohde & Schwarz Cybersecurity (ehemals u.a. bekannt als “gateprotect”) gebührt wieder besonderer Dank.
Räumlichkeiten (“Weisheitszahn“), Getränke und Pizza in Gruppengröße. Schöne Gespräche. Wieder viel zu schnell vorbei.

Ich hatte leider mein Telefon im Büro vergessen – daher kein Bild. Vielleicht findet sich ja noch eines von einem anderen Teilnehmer.

Zweiter Durchgang: Scrum und Security-Produkte – das geht nicht!

Hagen hatte mit der steilen These gepitched, dass Scrum für Security-Produkte nicht geeignet sei. Sowohl nach der Transition von irgendwas zu agil nicht, weil ein ernsthaftes commitment auf legacy code nicht möglich sei – als auch weil “security” nicht als Sprintziel erreichbar sei.

Das war provokant und führte zu dem wohl beabsichtigten Ergebnis. In der Session fanden sich Diskutanten aus unterschiedlichen Segmenten wieder. Zumindest für mich war die Session wertvoll, weil sie Austausch und Bestätigung gab.

Zunächst haben wir das Problem herausgearbeitet. Dazu ist es hilfreich, englische Begriffe zu verwenden. “Sicherheit” ist auf Deutsch zu weitreichend. Im Englischen wird u.a. zwischen “safety”, “security” und je nach Kontext weiter nach “confidentiality”, “integrity” und “reliability”/”availability” unterschieden.

Wo ist der Unterschied?

“safety” ist eine Sicherheitsfunktion, die aktiv getestet werden kann. Automobil: Bremse, Beleuchtung, Crashtest.
“security” ist eine Sekundärfunktion, die nur negativ getestet werden kann. Beispiel: Türschloss.
Positiv-Test der Funktion wäre das Ergebnis, dass ein Schlüssel das Schloss dazu veranlasst eine Schließfunktion freizugeben. Erwartet wird aber auch (und sehr oft nicht angefordert, sondern diskret unterstellt), dass nur der passende Schlüssel die Schließfreigabe erzeugt und alle anderen Schlüssel abgelehnt werden.

Das führte uns zu der Frage wie man nun “security” im Sprint umsetzt. Wir kamen an den Punkt, dass es explizite Sicherheitsfunktionen geben kann (“Login”, “Zugriffsberechtigung erteilen”). Damit diese aber “secure” sind, dürfen die funktionalen Anforderungen (ich kann mich authentifizieren und werde dadurch autorisiert) nicht nur mit Positiv-Tests abgedeckt werden. Für die “Security” muss ein expliziter Mehraufwand als Negativ-Tests betrieben werden (bspw. “Penetration Tests”, “Vulnerability-Tests”, “Red-Teams“).

Wie vermarkte ich diesen “Mehraufwand für Security”?
Nach meiner Auffassung ist dieses Problem ein Kommunikationsdefizit. Indem stillschweigend “Sicherheit” unterstellt wird, kann auch kein Dialog über den Wert von Sicherheit entstehen. Sicherheit ist aktive Kommunikation!

Es müssen erwartbare Qualitäten ausdrücklich angesprochen und gegen nicht erfüllbare Ansprüche abgegrenzt werden.
“Jeder” erwartet, dass eine hochqualitative Software gegen “Script-Kiddies” geschützt ist.
Keiner kann aber ernsthaft erwarten, gegen zielgerichtete, willentliche Aktivitäten bestens ausgerüsteter Geheimdienste standhalten zu können. In der Mitte dieser zwei Pole findet das “Geschäft mit der Sicherheit” statt.
Und auf diesem Feld kann man Aufwände, die man betreibt durchaus erwähnen und aktiv vermarkten.
Entweder ist man bspw. gesetzlich gezwungen, bestimmte Tests durchzuführen (Beispiel: Zulassungsverfahren der Pharmabranche oder Medizintechnik). Oder man legt sich diese Verpflichtung selbst auf, weil man das als “PREMIUM-Anspruch” der eigenen Produkte versteht. Oder aber man kommuniziert den Mehraufwand als Produktqualität “weil Sie als Kunde es von einem Sicherheitsprodukt erwarten”.
“Security” verkauft (anders als “safety”) ein Gefühl. Das Gefühl von Vertrauen und “Geborgenheit” ist aber leider flüchtig. Es muss immer wieder neu geschaffen und darf nicht ernsthaft verletzt werden. Sonst stirbt das Gefühl und vielleicht die ganze Firma gleich mit.
Mal schauen, wie es mit Samsung und seinen Telefonen weitergeht …

Ergebnis: geht doch!

Muss man halt machen.
Negativ-Tests gehören als nfA bzw. contraints mit in die Story und die (automatisierten!) Negativ-Tests gehören mit in die DoD. Fertsch!

Parallel: Peter L. ein weiteres Mal mit “Is Scrum toxic?”

Peter hatte das Thema bereits auf dem Barcamp angeboten. Dort und auch hier habe ich mich für ein anderes Thema entschieden bzw. war selbst Gastgeber.

Rolf sagte zu Beginn, diese Punkte würden auch als “dark scrum” diskutiert.
“dark scrum” ist “meaning well – done wrong”. “It takes time to unlearn the old ways. It takes time to learn new habits, time to learn to trust the team.”
“Much of the fear will go away by itself, because leadership can see real results.”

Mit meinen Worten an anderer Stelle …

Und sonst noch?

Unser hashtag bei twitter ist #agiLeipzig.

Ich habe im Nachgang des Termins gelernt, dass neben Lars Vollmer noch andere Vorreiter der neuen Arbeitswelt mit “meinem” schwäbischen Maschinenbauer zu tun hatten. Die Welt ist so klein. Aber das ist eine andere Geschichte …

Bis zum nächsten Mal.
Noch nicht fix, aber geplant für Anfang Dezember, hoffentlich in einer location, die “open end” zulässt und passend zur besinnlichen Vorweihnachtszeit mit Spielen in geselliger Runde. Derzeit scheint es sich auf den 8. Dezember zu verdichten.