Kapitel 01 - Teil 04: Doing things right vs. Doing the right thing

Wie gut verstehen wir die Bedürfnisse unserer Benutzer - und wie gut sind wir darin, diese in Aufgaben für die Softwareentwicklung zu zerlegen?
 Wie lange brauchen wir, bis wir solche Aufgaben lösen - durch Software, die in Produktion läuft, die diese Bedürfnisse erfüllt, funktioniert und fehlerfrei ist?

Die Antwort auf die erste Frage gibt uns Hinweise darauf, wie sehr wir an den richtigen Problemen arbeiten - "Doing the right things". Die zweite Frage zeigt uns, wie gut wir darin sind, diese Probleme zu lösen - "Doing things right".

Blog-Post und Transkript: https://quickglance.at/01_warum_agile_engineering/04_doing_things_right_vs_doing_the_right_thing/
Notizbuchseite: https://quickglance.at//notizen/01_warum_agile_engineering/01_04_doing_things_right_vs_doing_the_right_thing.pdf

Gottfried Szing, Verification vs. Validation: https://www.linkedin.com/posts/gottfriedszing_businessananlysis-testing-developer-activity-7167963342425313281-xond/

Email-Kurs: https://quickglance.at/email/
Consulting / Coaching / Training: https://www.devteams.at/
Mastodon: https://social.devteams.at/@dtanzer
Bluesky: https://bsky.app/profile/dtanzer.bsky.social

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Wie gut verstehen wir die Bedürfnisse unserer Benutzer und wie gut sind wir darin, diese in Aufgaben für die Softwareentwicklung zu zerlegen? Wie lange brauchen wir, bis wir solche Aufgaben lösen, durch Software, die in Produktion läuft, die diese Bedürfnisse erfüllt, funktioniert und fehlerfrei ist? Die Antwort auf die erste Frage gibt uns Hinweise darauf, wie sehr wir an den richtigen Problemen arbeiten. Doing the right things. Die zweite Frage zeigt uns, wie gut wir darin sind, diese Probleme zu lösen. Doing things right. In diesem Teil der Serie Quick Glance at Agile Engineering werde ich diese beiden Fragen näher beleuchten. Letztes Mal habe ich gezeigt, warum wir unsere Mean Time to Feedback optimieren sollten. Mein Name ist David Tanzer und ich helfe seit fast zwei Jahrzehnten Entwicklungsteams dabei, bessere Software in höherer Qualität schneller zu liefern. Bevor es losgeht, schreib bitte in deinen Notizen deine Antworten auf diese beiden Fragen. Am besten lädst du dir die aktuelle Notizblockseite als PDF herunter und druckst sie doppelseitig aus. Den Download-Link dafür und alle weiteren Links findest du in der Videobeschreibung. Auf dieser Notizbuchseite findest du auch Informationen zum aktuellen Teil, vorher gedruckte Fragen und genug Platz für deine Notizen. Die Einstiegsfrage zu Doing Things Right war, wie lange brauchen wir, bis wir Aufgaben lösen durch Software, die in Produktion läuft, diese Aufgaben erfüllt, funktioniert und fehlerfrei ist? Doing Things Redeutet unter anderem, auf hohe interne und externe Qualität unserer Software zu achten, das Design der Software ständig an die aktuellen Anforderungen anzupassen, auch wenn sich diese aktuellen Anforderungen laufend ändern, ein gemeinsames Verständnis der Funktionen und Implementierung der Software aufzubauen, sodass jeder an jedem Teil des Codes arbeiten kann, fehlerhaften Code zu vermeiden oder frühzeitig zu erkennen. Und schlechten Code, der uns bei der Umsetzung von Features behindert, zu verbessern. Doing things right ist eine Dimension effektiver Arbeit. Und in dieser Dimension können wir uns durch die Praktiken und Vorgehensweisen des Agile Engineering verbessern. Zum Thema Doing the Right Thing habe ich am Anfang gefragt, wie gut verstehen wir die Bedürfnisse unserer Benutzer und wie gut sind wir darin, diese in Aufgaben für die Softwareentwicklung zu zerlegen. Bei Doing the Right Thing geht es darum, die Softwareentwicklung besser an den Bedürfnissen der Benutzer und des Businesses zu orientieren. Wenn wir an Themen mit höherer Priorität arbeiten und wir dringendere Probleme lösen, liefern wir mehr Gegenwert in der gleichen Zeit. Doing Things R ist eine zweite Dimension effektiver Arbeit. Je besser wir beides beherrschen, umso besser können wir die Bedürfnisse unserer BenutzerInnen schnell und kostengünstig erfüllen. Wenn deine Organisation oder dein Team mit Doing Things Ring the Right Thing Schwierigkeiten hat, dann ist es nicht alleine. Kein Team, das ich bisher unterstützen durfte, machte alles immer richtig. Alle hatten auch Probleme, und zwar bei beiden Themen. Doing the right thing, die Lieferung von Software ist nicht immer hundertprozentig auf das Business ausgerichtet. Es werden Features geliefert, die so nicht oder im Moment nicht benötigt werden. Oder die Prioritäten passen nicht zusammen. Und bei Doing Things Right, Features brauchen sehr lange, weil das Design der Software nicht zu den aktuellen Anforderungen passt. Außerdem werden immer wieder Fehler gefunden, die unsere Pläne durchkreuzen. Dadurch haben wir keine Zeit für Engineering-Praktiken, die uns langfristig schneller machen könnten, wie zum Beispiel Refactoring. Oft gibt es auch noch weitere Hindernisse, die es uns schwer machen, Verbesserungen in beiden Bereichen zu erzielen. Diese Hindernisse verstecken sich in der Organisationsstruktur des Unternehmens und in Prozessen und Policies. Sie werden verursacht durch Budgets und Bonuszahlungen, einem mittleren Management, dessen Ziele der Agilität dem Unternehmen entgegenstehen und von vielen anderen Faktoren. Bevor ich darüber spreche, wie man sich verbessern kann, notiere bitte die Antworten auf folgende Fragen. Wie lange sind bei euch durchschnittlich Arbeitspakete im Backlog? Und wie lange ist das älteste Arbeitspaket bereits im Backlog? Wie oft müsst ihr Features ändern, die ihr bereits abgeschlossen hattet, weil die User doch etwas anderes wollten? Und wie viel Zeit verbringt ihr damit, an Dingen zu arbeiten, die bereits abgeschlossen sind? Also zum Beispiel Fehlerbehebungen, Änderungswünsche oder Behebung von schlechtem Code? Quick Glance at Agile Engineering gibt es übrigens auch als E-Mail-Kurs. Du bekommst jeden Tag ein 5- bis 10-minütiges Video und den dazugehörigen Text per E-Mail für die Teile, die bereits existieren. Danach bekommst du die Videos und Texte zugesendet, sobald ich sie veröffentliche. Den Link zum E-Mail-Kurs findest du auch in der Videobeschreibung und ich würde mich freuen, dich dort begrüßen zu dürfen. Doing things right und doing the right thing sind zwei Dimensionen effektiver Arbeit. Aber ist es egal, in welcher Dimension wir zuerst in Verbesserungen investieren? Grundsätzlich würde es erstmal mehr bringen, wenn wir besser darin würden, an den richtigen Problemen zu arbeiten, also ins in Doing the right thing zu verbessern. Wenn wir mit derselben Geschwindigkeit Aufgaben mit höherer Priorität abarbeiten, liefern wir mehr Wert in der gleichen Zeit. Wenn wir andererseits sehr effizient an den falschen Problemen arbeiten, bringt uns die höhere Geschwindigkeit nicht viel. Nur, wie erfahren wir eigentlich, ob wir an den richtigen Themen arbeiten? Mit Sicherheit können wir es nur durch Feedback wissen. Also indem wir etwas ausliefern, um dann zu beobachten, ob es den erwarteten Gegenwert bringt. Und dieses Feedback können wir schneller und öfter bekommen, wenn wir uns in Doing Things Right verbessern, wenn wir kleinere Lieferungen in höherer Qualität schneller bis in die Produktionsumgebung bringen. Zuerst die Ausrichtung der Softwareentwicklung am Business zu verbessern, also doing the right thing, und erst danach an der Effizienz zu arbeiten, doing things right, mag auf den ersten Blick lukrativer klingen. Aber es ist schwieriger, da wir nicht schnell genug das Feedback bekommen, das wir dafür bräuchten. Und wenn wir nicht an den völlig falschen Themen arbeiten, bringt uns eine Effizienzsteigerung auch eine Verbesserung bei der Effektivität. Die beiden Dimensionen sind nicht komplett unabhängig. Sie beeinflussen sich gegenseitig. So kann eine Verbesserung unserer Engineering-Praktiken auch helfen, bei der Ausrichtung der Software an den Bedürfnissen unserer Benutzer besser zu werden. Und die Verbesserungen im Agile Engineering können wir als Entwicklungsteam meistens alleine einleiten, ohne dass wir die Erlaubnis oder Unterstützung vom Rest der Organisation dafür benötigen. Bevor ich zum Fazit komme, lass doch ein Like da und abonniere den Kanal, damit du keines der nächsten Videos verpasst. Und wenn du Fragen hast oder mit etwas, das ich gesagt habe, nicht einverstanden bist, schreib es mir in die Kommentare oder schreib mir auf Mastodon oder Blue Sky. Peter Drucker hat einmal gesagt, there is nothing quite so useless as doing with great efficiency something that should not be done at all. Also würde es mehr bringen, zuerst sicherstellen, dass wir an den richtigen Problemen in der richtigen Reihenfolge arbeiten und erst dann unsere Effizienz zu steigern. Aber das ist meistens der schwierigere Weg. Wenn wir zuerst unsere Arbeitsweise verbessern, also schneller nach einer Idee ein vorzeigbares Produkt liefern, hohe Qualität liefern und wenig Rework verursachen, ein gemeinsames Verständnis und gute Wissensverteilung aufbauen, dann bekommen wir mehr Vertrauen und besseres Feedback. Das hilft uns, die Probleme unserer Benutzer besser zu verstehen und an den richtigen Lösungen zur richtigen Zeit zu arbeiten. Wenn wir zuerst das Engineering in den Griff bekommen, fällt es uns danach leichter, die Softwareentwicklung besser an den Bedürfnissen der BenutzerInnen und des Business zu orientieren. Heute ging es um die richtige Balance zwischen doing things right und doing the right thing. Im nächsten Teil der Serie, agil, das funktioniert doch gar nicht, gehe ich auf Vorbehalte und Gegenargumente zur agilen Softwareentwicklung und Verbesserungen im Engineering ein. Zum Schluss schreib bitte noch ein paar Ideen auf, wie du und dein Team sich in beiden Bereichen verbessern können.