Technisches Schulden Szenario #3: Ich interessiere mich nicht für das Produkt.
Das Entwicklerteam arbeitet zu schnell und es werden ständig bestehende Funktionalitäten gebrochen. Du nimmst wahr, dass es die Entwickler nicht wirklich interessiert. Was würdest Du dagegen tun? Und wie verhinderst Du die daraus resultierenden technischen Schulden?
Das nächste Szenario wie technische Schulden aufgebaut werden, dreht sich um technische Qualität sowie die Motivation langfristig an einem Software Produkt zu arbeiten.
Dies ist der dritte Artikel, der sich damit befasst wie technische Schulden aufgebaut werden. Wenn Du den ersten und zweiten Artikel lesen möchtest, klicke auf die nachfolgenden Links. 👇
Patrick Roos
Patrick Roos
Inhalt
Szenario
👨🦱 Entwickler 1: Ich habe Dir einen Pull Request für die User Story X zugewiesen. Kannst Du diesen kurz anschauen?
🧑 Entwickler 2: Wow - Du bist ja schnell. Ja, ich werde den Pull-Request bald anschauen.
🧑 Entwickler 2 schaut den Pull-Request an.
🧑 Entwickler 2: Okey, hmm...ich sehe einige Probleme:
- Wieso hast Du die Tests von Feature Y auskommentiert?
- Zusätzlich gibt es einige Redundanzen...
- ...und die Implementierung sieht nicht gerade sauber aus. Es gibt da einige Code-Smells, die zu korrigieren sind.
👨🦱 Entwickler 1: OK, ich sehe deine Punkte. Aber kannst Du den Pull-Request trotzdem approven? Ich werde deine Punkte sicherlich später fixen.
👨 Developer 2: Einverstanden - ich werde es approven. Lass uns das später fixen.
👨🦱 Entwickler 1 mergt den Code von User Story X.
Hintergrund info: Die offenen Punkte wurden nie mehr gefixt.
Was ist das Problem?
Auf das oben beschriebene Szenario gibt es zwei unterschiedliche Sichten:
- Fehlende Techniken und unterstützendes Tooling um technische Exzellenz zu fördern resp. diese offenen Punkte sichtbar zu machen.
- Kein Interesse und langfristige Motivation am Produkt, d.h. keine langfristige Sichtweise auf die eigene Arbeit.
Speziell im zweiten Problem "keine Interesse und langfristige Motivation" sehe ich sehr grosses, oftmals noch nicht erkanntes Potential. Wenn Du lediglich bei einer Firma arbeitest um deine Arbeitszeit abzusitzen und den Lohn zu erhalten, dann wirst Du automatisch in deinem täglichen Arbeitsleben Abkürzungen nehmen. Ohne intrinische Motivation gibt es keine richtige Product Ownership. Ohne richtige Product Ownership, wird es nie technische Excellenz geben.
Jedes technische, methodische oder organisatorische Framework, egal wie gut dieses ist, wird wertlos sein, wenn die eigene Motivation fehlt und kein langfristiges Interesse am Produkt und an der Firma vorhanden ist.
Wie kannst Du dieses Problem adressieren?
Entlang von diesen beiden oben identifizierten Aspekten, werde ich versuchen zwei unterschiedliche Ansätze aufzeigen, um dieses Problem zu adressieren. Einen technischen sowie einen organisatorischen Ansatz:
- Wie kann man technisch sicherstellen, dass solche Abkürzungen verhindert werden oder zumindest früh erkannt werden können?
- Wie kann man die Motivation und ein langfristiges Interesse am Produkt und an der Firma fördern?
Wie kann man technisch sicherstellen, dass solche Abkürzungen verhindert werden oder zumindest früh erkannt werden können?
Zuerst gehe ich davon auss, dass im Unternehmen bereits eine Versionskontrolle existiert sowie entsprechende CI-/CD pipelines aufgebaut sind. Falls nicht, dann wäre es Zeit diese aufzubauen 😄
Automatisierte Quality Gates helfen schlechte technische Qualität sichtbar zu machen und gänzlich zu verhindern
Für das obengenannte Szenario ist es zuerst von Vorteil diese Abkürzungen sichtbar zu machen. Wenn man diese sichtbar macht, kann die Bereinigung davon motivierend wirken. Neben der Sichtbarkeit sollte man gemeinsam Qualitäts-Metriken definieren sowie diese automatisch durch die Build-Pipeline validieren lassen. Es soll kein Code, der die definierten technischen Qualitätsziele nicht erfüllt, in die Produktion gelangen.
Es gibt verschiedene Metriken, die im obigen Szenario relevant sind:
- Test Coverage: Im Szenario wird durch das Auskommentieren von bereits geschriebenen Tests die Testabdeckung reduziert. Die Möglichkeit besteht, dass die Funktionsweise von anderen Funktionalitäten dadurch gebrochen wird.
- Code Smells: Code Smells resultieren aus "unsauberem" Code bei welchem man z.B. Best Practices missachtet. Code Smells sind i.d.R. keine Bugs, aber sie zeigen mögliche Schwachstellen im Design auf und können natürlich langfristig die Entwicklungsgeschwindigkeit schmählern sowie das Risiko von neuen Bugs steigern.
- Code Duplications: Code Duplications sind oftmals das Resultat von "copy-past-programmierung", wo eine funktionierend Code-Sektion einfach kopiert wird - weil sie eben bereits an einem anderen Ort funktioniert hat. Dies führt jedoch zu Redundanzen und weniger wartbarem Code.
- Security Vulnerabilities: Unachtsamkeit in der Programmierung sowie keine Beachtung von Versionen beim Einsatz von 3rd Party Libraries kann in verschiedene Sicherheitsschwachstellen resultieren.
Die obengenannten Probleme können mit diesen wenigen Qualitätsmetriken adressiert werden. Vor allem mit einer grossen Code-Basis ist es unmöglich die obengenanten Themen lediglich mit einem Code-Review abfedern zu können. Daher soll das Prüfen dieser Metriken ein wesentlicher Teil in der Build-Pipeline darstellen.
Die folgende Abbildung zeigt, wie man einen Trunk-Branch schützen kann durch einen automatisierten technischen Qualitätscheck. D.h. sobald der technische Qualitätscheck fehlschlägt, kann niemand in den Ziel-Branch mergen. Mit jedem Commit wird der Qualitätscheck ausgeführt und ein Qualitätsreport generiert.
Es gibt eine grosse Auswahl moderner CI-/CD Tools, um diese technische Qualitätsprüfung abzubilden. Diese Tools kann man auf eine einfache Art und Weise in die Build- und Deployment Pipeline integrieren und damit sinkende Test-Coverage, resultierende Code Smells, auftretende Code Duplikationen oder neue Security Vulnerabilities in der Codebasis frühzeitig erkennen.
Die folgenden Tools stellen einen Auszug aus aktuell eingesetzten Cloud-Tools dar, mit welchen automatisierte technische Qualitätsüberprüfungen umgesetzt werden können:
- Sonarcloud: Statische Code-Analyse
- jFrog Artifactory & Xray: Dependency Management, Vulnerability und Lizenz Checks von 3rd party Abhängigkeiten
- Snyk Code: Static application security testing
- Bitbucket Cloud / Bitbucket Pipelines: Git mit einem integrierten managed build system (hier gibt es auch perfekte Alternativen mit GitHub und GitLab)
Mögliche Probleme mit technischen Qualitätsreports
Jeder von diesen aufgeführten Tools generiert seine eigenen Qualitätreports.
Es kann vorkommen, dass solche Reports missinterpretiert werden. Ein mögliches Szenario ist auch, dass Personen ohne technischen Hintergrund diese Reports sehen wollen und entsprechend interpretieren.
Ein prominentes Beispiel hier ist die Testabdeckung: "Hey, eure Testabdeckung ist zu niedrig. Erhöht diese - sofort!"
Oftmals ist solchen Personen nicht bekannt, dass es auch technische Qualität im Testcode gibt. Beispielsweise können nutzlose oder nicht aussagekräftige Tests geschrieben werden, welche den Coverage Report verfälschen und somit die technische Qualität überhaupt nicht steigern - sondern eher vermindern.
Idealerweise werden solche Reports im Team intepretiert und daraus die entsprechenden Action Points zu definiert. Bevor man diese Tools jedoch einsetzt empfiehlt es sich, das Ziel sowie die, für das Team relevanten Metriken gemeinsam zu definieren.
Wie kann man die Motivation und ein langfristiges Interesse am Produkt und an der Firma fördern?
1. Produkt-Teams anstatt Projekt-Teams
Oftmals leidet die Produktentwicklung in Unternehmen an einem verankerten projektorientierten Mindset. Oftmals erlebt man, dass Projekte gemacht werden, um neue Produkte zu erstellen oder diese zu modernisieren.
Oftmals ist jedoch der Projektansatz in vielen Fällen hindernd für eine nachhaltige Produktentwicklung. Warum?
- Ein Projekt hat ein Start- und Enddatum, einen mehr oder weniger fixierten Scope sowie ein fixiertes Budget.
- Ein Produkt hat kein bekanntes Enddatum, der Scope ist flexibel resp. ist Endbenutzer getrieben und benötigt kontinuierliches Investment. Zusätzlich hat das Produkt zum Ziel, der Unternehmung und ihren Mitarbeitern eine nachhaltige finanzielle Sicherheit zu ermöglichen.
Wie der Unterschied zwischen Projekt und Produkt, haben auch die Rolle Projekt Manager und Produkt Owner teilweise wiedersprüchliche Zielsetzungen:
- Ein Projekt Manager will die Projektziele zeitgemäss, mit dem anfänglich definierten Scopes sowie innerhalb des Projektbudgets erreichen. Damit versucht er die Bedürfnisse der Projekt Stakeholder zu adressieren.
- Ein Product Owner will dass sein Produkt die Bedürfnisse der Endbenutzer resp. der Kunden adressiert. Er will dass die Kunden weiterhin bereit sind, für den vom Produkt erfahrenen Wert zu bezahlen.
Wenn ein Unternehmen nach Produkten organisiert ist, ermöglicht sie den Mitarbeitern eine Perspektive sowie die Möglichkeit für eine langfristige Beziehung zu einem Produkt resp. dessen Produkt Team herstellen zu können.
Ich bin überzeugt, dass durch verankerte Produktteams die langfristigen Perspektive von einem Mitarbeiter gefördert und dabei die intrinsische Motivation gesteigert werden kann. Dadurch kann ebenfalls auch der implizite Aufbau von technischen Schulden reduziert werden.
Ein empfehlenswerter Post ist auch "Product Over Projects auf martinfowler.com 👇
2. Autonomie durch Kompetenz und Verantwortung
Nur die Organisation nach Produktteams wird nicht alles lösen. Es ist vielmehr die Frage welche Kompetenzen und Verantwortung die Produktteams haben.
Um die Autonomie von Produktteams zu ermöglichen sind folgende grundlegenden Kompetenzen und Verantwortungen minimal notwendig:
- Es ist dem Team erlaubt jederzeit mit dem Endbenutzer zu kommunizieren und interagieren, um kontinuierliches Feedback zum Produkt zu erhalten.
- Es ist dem Team ebenfalls erlaubt, jederzeit mit dem zahlenden Kunden die Priorität von den nächsten Vorhaben zu diskutieren.
- Der Product Owner hat die Kompetenz das Backlog entlang von den Kundenbedürfnissen zu priorisieren.
- Das Team kann den Releasezyklus von seinem Software Produkt selbst bestimme .
- Das Team muss sicherstellen, dass die Bedürfnisse der Endbenutzer mit dem Software Produkt getroffen werden.
- Das Team muss sicherstellen, dass der zahlende Kunde nicht abspringt aufgrund fehlender Funktionalität oder Unzufriedenheit in Bezug auf den Mehrwert was ihm das Produkt bringt.
Ich bin überzeugt, dass Autonomie, schnelle und direkte Kundenfeedback Zyklen sowie die integrierte Entscheidungskompetenz einen grossen Impakt auf die Motivation von Teammitglieder in einem Produktteam haben kann.
3. Extra: Durch Anteile internes Unternehmertum fördern
Ein Software-Entwickler macht täglich hunderte von Mikro-Entscheidungen. Jeder von diesen Entscheidungen hat einen kleinen Impact auf den "Business-Erfolg" von einem Unternehmen. Oftmals sind sich das die Entwickler nicht bewusst - denn dieses Bewusstsein wird oftmals auch nicht gefördert.
Wenn wir das Beispiel von oben analysieren:
Wenn der Entwickler temporär die automatisierten Tests von einem Feature X auskommentiert, risikiert der Entwickler und natürlich auch der Reviewer, dass das Feature nach dem Merge nicht mehr funktioniert. Wenn ein fehlerbehaftetes Feature in Produktion geht und z.B. dem Endbenutzer damit sein fachliches Problem temporär nicht mehr durch das Produkt gelöst wird, riskiert man, dass dieser abspringt. Dieser Absprung hätte einen direkten Impact auf die Wirtschaftlichkeit des Unternehmens. Überspitzt interpretiert: Die Entwickler risikieren - wohl unbewusst - einen negativen Impact auf die Wirtschaftlichkeit des gesamten Unternehmens durch diese "Mikro-"Entscheidung.
Um ein wirtschaftliches Handeln sowie die langfristige Perspektive zu fördern, würde ich als Arbeitgeber seinen Mitarbeiter Anteile an der Unternehmung anbieten. Wenn ein Mitarbeiter dieses Angebot ablehnt, sollte man ihn fragen wieso. Ich bin überzeugt, dass wenn dieser ehrlich ist, interessante Gründe hervor kommen, welche das Unternehmen nur weiterbringen können.
Um gute Product Engineers anzusprechen und nachhaltig mit dem Unternehmen zu verbinden, genügte es heute nicht mehr lediglich eine "coole" Kultur, einen Kickertisch und einen Kühlschrank voller Bier zu haben.
Nur mit langfristig wirksamen Incentives kann die Motivation und damit das reale Interesse am Software Produkt sowie an der Unternehmen gefördert werden.
Fazit
Wenn das Entwicklerteam zu schnell unterwegs ist und dabei konstant bestehende Funktionalitäten bricht, ist das ein Indikator für die folgenden Probleme:
- Fehlende technische Excellenz
- Fehlendes Interesse und fehlende Motivation
Um das erste Problem zu adressieren hilft es grundlgende Techniken wie Continuous Integration and Continuous Delivery mit eingebauten automatischen technischen Quality Checks einzuführen.
Um das zweite Problem zu adressieren, hilft es autonome Produktteams zu bilden und dabei den Product Engineers Anteile anzubieten um wirtschaftliches Denken und eine langfristige Beziehung zum Software Produkt und schlussendlich zum Unternehmen zu fördern.
Comments ()