Beiträge

SPF-Consulting AG - Insights - Komplexität

Komplexität – Code hat keinen Wert

Komplexität – Code hat keinen Wert – wenn es niemanden gibt, der ihn versteht.

Komplexität in Softwareprojekten ist unausweichlich und seit jeher ein immer grösser werdendes Problem. Doch warum ist die Komplexität ein solches Problem und was gibt es für Ideen damit umzugehen?

SPF-Consulting AG - Insights - Komplexität

Wenn wir uns den Prozess des Programmierens vorstellen, denken wir verständlicher Weise direkt an den Akt des Codeschreibens selbst. Während dies einen Grossteil der Arbeit ausmacht, so ist dies jedoch bei weitem nicht das ganze Bild. Bevor Code geschrieben wird, entsteht unvermeidbar ein mal mehr, mal weniger klares mentales Modell von Requirements, Constraints, Abläufen und Fallstricken im Kopf des Programmierers existieren, welches ihm ermöglicht den entsprechend bestmöglichen Code zu schreiben.

Ein Problem mit diesem mentalen Modell ist jedoch häufig das es zum Grossteil lediglich in den Köpfen der Programmierer selbst lebt und sich dort weiterentwickelt. Wenn diese Programmierer dann das Projekt verlassen, kann das oft zu Problemen führen. Knowhow geht verloren, technische Visionen verblassen, geheime Handgriffe, die die Maschinerie am Laufen lassen geraten in Vergessenheit. Neue Programmierer, die in das Projekt dazustossen, müssen möglichst viel von diesem mentalen Modell aufnehmen und verstehen. Tun sie das nicht oder nur teilweise, oftmals ein Folge von suboptimalen Know-How Transfer, besteht die Gefahr das neu geschriebener Code nicht in die bestehende Code Base passt und zu Qualitäts- und Wartungsproblemen führt.

Abhilfen dafür existieren selbstverständlich, allem voran eine gute Dokumentation, ob im Code selbst oder anderweitig, sowie eine ausgebaute Testsuite. Eine «Silver Bullet» ist hier aber schwer zu finden. Dokumentation entsteht oft after the fact, kann lückenhaft sein oder nicht mehr aktuell. Tests helfen das Vertrauen in die Funktionalität und Qualität des geschriebenen Codes zu erhalten, sind aber ebenso Teil des Codes und somit auch des mentalen Modells. Sprich man kann die Tests nicht verstehen wenn man nicht das Modell hinter dem Programm verstanden hat.

Eine bereits erprobte Idee wäre es also, den Programmierungsprozess auf der Artefakt-Ebene nicht zu unterteilen in Dokumentation und Requirements auf der einen Seite und Code auf der anderen Seite, sondern diese beiden Aspekte direkt miteinander zu verheiraten. Hierbei gibt es schon eine ganze Reihe an Ideen und Versuchen dies zu realisieren. Generell dreht sich der Ansatz aber oft um die Definition einer gemeinsamen Sprache zur Beschreibung des Modells. Nicht selten ist diese Sprache dann Teil des Codes selbst. Bestehender Code wird damit erweitert um Contracts und Constraints des Modells selbst nicht nur zu dokumentieren, sondern auch direkt vom z.B. Compiler verifizieren und validieren zu lassen.

Ein Nachteil dieser eher codebasierten Lösungen ist jedoch die damit zusammenhängende Komplexität. Das Lernen und korrekte Anwenden dieser neuen Modell-Sprache erfordert Zeit und ein hohes Mass an Konzentration. So entstandene Artefakte sind schwierig bis unmöglich für Unwissende zu verstehen und zu erweitern. Auf der Suche nach einem Weg der Komplexität Herr zu werden hat man so noch mehr Komplexität geschaffen. In gewissen Kontexten kann dies funktionieren, in vielen anderen kann es aber auch katastrophal scheitern.

Eine natürliche Schlussfolgerung daraus ist natürlich, nicht eine text-basierte Sprache zu verwenden, sondern sich möglichst and Bildsprachen zu orientieren. Auch hier gibt es bereits einige Versuche, oftmals schiessen diese Lösungen aber etwas über das Ziel hinaus und zu viel des auszuführenden Codes wird generiert. Dies macht es zum einen wieder umso komplexer, je mehr man mit der Bildsprache ausdrücken will, als auch macht es die Arbeit der Programmierer wiederrum nicht unwesentlich anstrengender. Mit zu viel generierten Code auf Dauer interfacen zu müssen macht den Entwicklungsprozess auf mehrere Arten unangenehm und langsam.

Was wäre also, wenn man aus den Fehlern der vorhergegangenen Lösungen lernt und einen neuen Vorstoss wagt. Somit keine neue Sprache schaffen, dessen Grammatik und Syntax erst aufwendig einstudiert werden muss, sondern auf simple und bekannte Graphiken wie UML setzten. Anstatt No-Code-mässig versuchen, den gesamten Programmierprozess zu abstrahieren, lieber auf kleine und contract-basierte Generierungen setzten, mit denen ein Entwickler dann simpel interagieren kann. Mit wenig Aufwand könnte hier einiges geschaffen werden, lediglich versuchen müsste man es.

Autor

Felix Isensee

Felix Isensee, Software Developer

E-Mail: felix.isensee@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/fisensee/

 

 

SPF Consulting AG - Insights - Portrait unseres neuen Mitarbeiters Alexander Zaforek

10+1 Frage an unseren neuen Mitarbeiter Alexander Zaforek

Interview mit unserem neuen Mitarbeiter Alexander Zaforek bei der SPF Consulting AG

 

Willkommen bei der SPF Consulting AG, Alex. Wir freuen uns dich als neuen Mitarbeiter bei der SPF zu begrüssen. Danke, dass Du Dir Zeit für das Gespräch genommen hast.

SPF Consulting AG - Insights - Portrait unseres neuen Mitarbeiters Alexander Zaforek

Kannst Du kurz etwas zu Deiner Person sagen? Du hattest ja eine recht interessante Kindheit.

Ja, ich wurde in den USA geboren und bin dann rund um die Welt in acht verschiedenen Ländern aufgewachsen. Nach meinem Baccalauréat in Literatur und Philosophie an der Académie de Strasbourg, bin ich mit 19 nach Wien. Dort habe ich Biologie und Fotografie studiert, gefolgt von einer Ausbildung zum Systemischen Trainer.

Das klingt sehr spannend, Du hast ein sehr breit gestreutes Interessensgebiet. Was war denn Dein Berufswunsch als Kind?

Das ist eine gute Frage. Ich hatte nie einen speziellen Berufswunsch, ich fand so vieles unterschiedliches interessant. Allein der Gedanke, mich auf einen einzigen Beruf festlegen zu müssen… Als Teenager war mein Traumberuf Expeditionsleiter. Passt zu dem, was ich gerade mache (lacht).

Und was machst Du gerade? Wir sitzen ja mitten in der Schweiz und nicht im Amazonas oder auf dem Kilimanjaro?

Ich arbeite als Agile Coach und Scrum Master. Einige würden es vielleicht als Kindergärtner für Erwachsene bezeichnen, da bleibe ich lieber beim Expeditionsleiter. Die Rolle des Scrum Masters beinhaltet ja viel mehr als nur das Team nach aussen zu schützen und stetig für frischen Kaffee zu sorgen. Man hat ganz viele Hüte auf, die man konstant wechseln muss.

Welche sind das?

Einmal bin ich Trainer, dann Mentor, dann wieder Polizist, Administrator oder Seelsorger. Manchmal auch Feuerwehrmann, wobei ich lieber von Brandschützer spreche, denn der verhindert, dass es überhaupt anfängt zu brennen. Dann gibt es noch den Hut des Coaches, des Leaders oder zB. des Intendanten, der das Ganze überschaut, steuernd eingreift und den Stakeholdern ein Ensemble und eine Performance präsentiert, zu der sie gerne wieder zurückkommen.

Was interessiert Dich als Mitarbeiter an dieser doch sehr umfangreichen Rolle?

Als Coach interessiert mich vorrangig die Kollaboration und der Austausch zwischen Menschen. Vor allem auf psychologischer Ebene, wie Gefühle das Handeln beeinflussen und vice versa. Es ist auch immer wieder schön zu sehen, wie sich die Dynamiken im Team entwickeln, ein Zusammengehörigkeitsgefühl entsteht und sich eine intrinsische Motivation bildet, voranzukommen.

Gerne sitze ich auch nur als stiller Beobachter in Meetings, sehe mir die Menschen und ihre Körpersprache an und analysiere, wie sich die Situation entwickelt, wie jeder einzelnen reagiert und sich verhält. Auf Wunsch mache ich danach eine Auflösungsrunde. Dies hilft dem Team und den einzelnen Mitgliedern sich selbst zu reflektieren und den Moment bewusster zu erleben. Hierzu passen auch die Workshops zu Teamentwicklung und Feedback geben und nehmen, die wir anbieten.

Ich habe letztens versucht, meiner Coiffeuse zu erklären, was ich beruflich mache. Sie hat es dann folgendermassen zusammengefasst: Ich helfe Menschen dabei, schöner zu Arbeiten. Das fand ich inspirierend.

In der Arbeit mit Menschen hilft Dir sicher auch Deine internationale Erfahrung?

Ja, definitiv! Ich habe schon als Kind sehr unterschiedliche Kulturen kennen gelernt und schnell gemerkt, dass zwischenmenschlicher Respekt das Wichtigste ist.
Es ist egal mit wem man im Austausch ist, Menschen haben immer dieselben psychologischen Grundbedürfnisse, egal aus welcher Kultur sie stammen. Mit dem Reiss Motivation Profil lassen sich auch in heterogenen Gruppen die menschlichen Motivatoren der einzelnen Teammitglieder herausfinden.

Kulturell bedingt, gibt es natürlich verschiedene Verhaltensweisen. Dennoch, auf menschlicher Ebene ist es immer gleich.

Ein Beispiel dazu aus der Agilen Transformation: Jede Firma denkt, dass ihre Probleme einzigartig sind und niemand sonst diese hat und versteht. Tatsächlich stecken aber immer dieselben krankenden Grundlagen dahinter: Fehlende Struktur, Klarheit, nicht etablierte Praktiken und keine gelebte Kultur. Wobei Kultur am schwierigsten und langwierigsten zu etablieren ist, da diese von innen entstehen muss. Dies kann jedoch gezielt gefördert und getriggert werden.

Wann hattest Du Deine ersten Erfahrungen mit der Agilität?

Ich bezeichne mich gerne als Agile Native. Durch meinen späten Einstieg in die IT, hatte ich kaum Berührungspunkte mit behäbigen Wasserfallprojekten. Mein erster Job nach dem Studium war Abteilungsleiter für den weltweiten Kundendienst bei einem österreichischen Kameraproduzenten. Dort habe ich eine Lean-Agile Kultur vorgelebt, ohne überhaupt zu wissen, dass es so heisst.

Wir haben aus Überzeugung so gearbeitet und nannten es «Hausverstand». Wir hatten priorisierte To-Do Listen mit WIP-Limits. Ich habe, neben abteilungsübergreifenden Feedback-Loops, diverse Projekte initiiert, um Waste zu reduzieren und die Effizienz der Prozesse zu steigern. Mit den bebilderten FAQs waren wir auch sehr effektiv unterwegs und konnten die Flut an Emails stark reduzieren. Scrum habe ich 2013 kennen gelernt, als ich als Trainer in die IT gewechselt bin.

Was treibt Dich in der Rolle des Agile Coaches an?

Am meisten Spass macht mir das Mentoring. Wenn ich Menschen etwas vermitteln und zeigen kann, sie begleite und bekräftige, dies selbst umzusetzen. Wenn ich miterlebe, wie jemand in seine neue Rolle hineinwächst und aufblüht, anfängt selbstständig zu agieren, dann macht mich das glücklich.

Manchmal setze ich Denkanstösse, in dem ich gezielt hinterfrage und schaue dann zu, wie einzelne Teammitglieder langsam anfangen, Initiative zu ergreifen, die Scheu davor ablegen, eigene Ideen vorzubringen und sich diese Energie dann auf das gesamte Team überträgt.

Einmal habe ich ein Team aufgebaut, nach ein paar Monaten kannten und vertrauten wir uns gegenseitig. Ich hielt dem Team den Rücken frei, im Gegenzug stärkten sie mir den Rücken und ich konnte mich blind auf sie verlassen. Nach einiger Zeit waren wir dann immer drei Schritte voraus, was zur Folge hatte, dass wir regelmässig als erste auf neue Impediments stiessen und diese meldeten.

Wenn wir kamen, hiess es nur noch «die schon wieder», also wechselten wir unseren Teamnamen auf The Black Sheep Das wirkte wie ein Booster auf das Team und erfüllte uns mit Stolz: Jetzt erst recht! Die anderen Teamleads wollten unser Geheimnis wissen, waren aber so tief im Micromanagement verloren, dass sie gar nicht verstanden, was Psychologische Sicherheit bedeutet und wie sie gefördert werden kann. Ein Team folgt Respekt, nicht Macht.

Man kann Menschen nicht willentlich motivieren. Man kann nur vorleben und durch das eigene Handeln andere inspirieren, es gleich zu tun. Bestenfalls entsteht daraus zuerst ein extrinsisch motiviertes Verhalten und nur durch stetiges Wiederholen eventuell eine intrinsische Motivation.

Die Angst vor dem, als Bedrohung wahrgenommenen, unbekannten Neuen muss zuerst abgelegt werden. Das verursacht viel Stress, da wir psychologisch so programmiert sind, dass wir nicht das machen, was wir wirklich wollen, sondern das, was uns am wenigsten Angst bereitet. Das ist ein längerer Prozess, denn im Hintergrund ist alles hormonell gesteuert. Im Coaching gibt es Techniken und Methoden, die den Oxytocin Gehalt steigern und dadurch Vertrauen und Motivation fördern, dennoch geht das nicht von heute auf Morgen.

Mich fasziniert dieses Zusammenspiel von Physiologie, Psychologie, Ethologie und das Wissen um die Mechanismen dahinter. Wir sind alles Individuen und haben unterschiedliche Treiber, deshalb kann man nicht sagen «ab morgen sind wir alle agil».

Wenn ich Angst habe, stelle ich mir vor ich hätte Superkräfte. Welche Superpower hättest Du gerne?

Schweben oder Fliegen! Ich betrachte die Dinge gerne mit Abstand, um das System im Gesamten zu verstehen. Zusammenhänge und Abhängigkeiten sieht man nur mit Abstand zum Objekt.

Oft braucht es einen Schritt zurück, um nicht Teil des Systems zu werden. Man muss den Blick bewusst wieder auf das Ganze richten, um sich nicht in den Details zu verlieren. Zu oft sehe ich Entwickler, Produkt Owner, Teammitglieder den Fokus auf das Relevante verlieren, weil sie in viel zu grossen Stories vertieft sind und durch die schiere Anzahl an Tasks und Entscheidungen überfordert sind. Ich habe schon PO und BAs gesehen, die regelrecht gelähmt waren, im Angesicht der Herkulesaufgabe.

Das Team machte sich Gedanken über Spezifikationen, die frühestens in zwei Jahren zu Tragen kommen und deren zu Grunde liegendes Produkt es noch nicht einmal gab, geschweige denn, dem Kunden überhaupt unterbreitet wurden. Die Stories gingen faktisch über mehrere Jahre. Dies war den Beteiligten gar nicht bewusst, da sie einfach zu tief in den Details verloren waren.

Deshalb: Schritt zurück, neu fokussieren und nur die Dinge in Angriff nehmen, welche tatsächlich unmittelbaren Wert für den End User liefern.
Ich sage bewusst nicht «Kunde», denn dieser muss nicht gleich dem End User sein. Die Grossmutter, welche dem Enkel ein Spielzeug kauft, hat wahrscheinlich eine andere Vorstellung von dem Produkt und sucht dieses nach anderen Gesichtspunkten aus, welche oft sogar konträr zu denen des Enkelsohnes sind.

Wieso hast Du Dich für SPF entschieden?

Ich durfte bereits vor einigen Jahren als Agile Coach zusammen mit Stefan Meier arbeiten. Wir haben die Transformation einer grossen Schweizer Bank zusammen begleitet.

Bereits damals ist mir aufgefallen, dass die Menschlichkeit einen zentralen Stellenwert in der SPF hat.

Die internen Gespräche haben oft eine psychologische Komponente. Gerade in unserer Agilen Gilde sind die Kollegen sehr selbstreflektiert und besitzen ein sehr gutes zwischenmenschliches Gespür. Wir sprechen offen über Gefühle, Verhalten, mögliche Treiber, Auslöser von Irritationen und analysieren Situation gemeinsam. Ich schätze es sehr, ein Gegenüber zu haben, mit dem man so tief in diese Materie eintauchen und sich gegenseitig beraten kann.

Es ist fast surreal, endlich in einer Consulting Firma angekommen zu sein, welche so stark Wert auf die Empfindungen der Menschen (Mitarbeiter wie auch Kunden) legt und diese ehrlich und bewusst reflektiert.

Sämi (Anm.d.R. Firmengründer) hat mal gesagt, die SPF sei eine «Ansammlung freier Radikale», das ist mir hängengeblieben und macht mich stolz als Mitarbeiter ein Teil davon zu sein.

Abgesehen davon, bin ich einfach von der Professionalität und den Services überzeugt. Der Mix aus Delivery, Consulting, Schulungen (zB. Kommunikation, Visual Facilitation), Workshops im Bereich Teamentwicklung, Agile Health Check passt genau zu meinen Qualifikationen und Interessen.

Zum Abschluss was ist Dein persönliches Mission Statement in einem Satz?

Jeden Menschen so zu nehmen, wie er ist und ihn zu unterstützen zum Besten seiner selbst zu werden.

Kontaktinformationen

 

SPF Consulting AG - Danilo Biella - Agile & Quality Professional

Danilo Biella, Agile & Quality Professional

E-Mail: danilo.biella@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/danilo-biella

 

SPF Consulting AG - Insights - Portrait unseres neuen Mitarbeiters Alexander Zaforek

Alexander Zaforek, Agile & Quality Professional

E-Mail: alexander.zaforek@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/alexzaforek/

SPF Consulting AG - Insights - Teaching the Mob to students

Teaching the Mob to students

Teaching the Mob to students?

When Bernhard Wagner – acting teacher at ZHAW and teaching the ways of programming to students of electric engineering – asked me whether I could imagine using the Mob Programming & Test Driven Development approach to programming in a didactic setting and if I’d be willing repeat my workshop on “The MOB & TDD” for his class, I was pleasantly surprised and replied “There is nothing I’d rather do”.

SPF Consulting AG - Insights - Teaching the Mob to students

Is it just about collaboration?

His concern was that individuals would be left behind unnoticed so he would not be able to help them catching up. Putting in place any kind of swarming culture would be beneficial to avoid this problem. And of course, the mob the merrier. Less knowledgeable people and introverts can profit from the team effort by developing their own skills.

But the advantage for the pros and extroverts is very valuable, too, not only for the team as such. Teaming up properly leaves space for the driving forces to learn about new ideas in areas from which fellows think they have nothing left to learn about. This is not only true for study groups. Applying these principles in professional teams is the easiest and most effective way to literally foster every single agile value.

But does it make a good case?

Suddenly a doubt rushed through my mind: Isn’t everybody already saying that ensemble programming only works in academic examples? How is this going to help? But nothing of that happened. Au contraire. The not-yet professionals came up with the same arguments as team leads normally do, but much quicker, how that would not work out out in the field as everyone would think that you lose capacity by working in groups. They were quickly to be proven wrong and be convinced. It is left to the inclined reader to look up the facts from other articles, where these overly simplistic arithmetical arguments are proven incorrect.

At the end of the day

Since the class was too large, we had to split into two groups and do the exercise twice. When the first group left the room and the second came in, one of the entering students said: “You erased the fatalistic look of indifference from their faces, what did you do?!?”. Guilty as charged.

After all was over, I asked for collecting feedback and in the end we got only positive if not effusive reactions.

What is the lesson?

After 2 generations of computer science in schools we’re still trying to teach if-else, while, algorithms and patterns, instead of putting quality driven work and collaboration first. We need to change that if we want to improve culture.

 

Contact Information

 

Danilo Biella, Agile & Quality Professional

Email: danilo.biella@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/danilo-biella/