Doing things right vs. Doing the right things

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

• 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.

Bevor es losgeht, schreibe bitte in deinen Notizen deine Antworten auf diese beiden Fragen auf. Am besten lädst du dir die aktuelle Notizbuchseite als PDF herunter und druckst sie doppelseitig aus.

Dort findest du auch Informationen zum aktuellen Teil, vorgedruckte Fragen und auch genug Platz für deine Notizen.

Doing things right

Die Einstiegsfrage zu "doing things right" war: Wie lange brauchen wir, bis wir Aufgaben lösen—durch Software, die in Produktion läuft, die diese erfüllt, funktioniert und fehlerfrei ist?

"Doing things right" bedeutet 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 laufend ändern
• ein gemeinsames Verständnis der Funktionen und Implementierung der Software aufzubauen, so dass jeder an jedem Teil des Codes arbeiten kann
• fehlerhaften Code zu vermeiden oder frühzeitig zu erkennen
• 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 das Agile Engineering verbessern.

Doing the right thing

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 Business 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 right" ist eine zweite Dimension effektiver Arbeit. Je besser wir beides beherrschen, umso besser können wir die Bedürfnisse unserer Benutzer schnell und kostengünstig erfüllen.

Hindernisse

Wenn deine Organisation oder dein Team mit "doing things right" oder "doing the right thing" Schwierigkeiten hat, 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 100%ig 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.
• "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 z.B. 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 im 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 uns durchschnittlich Arbeitspakete im Backlog? Wie lange ist das älteste Arbeitspaket bereits im Backlog?
• Wie oft müssen wir Features ändern, die wir bereits abgeschlossen hatten, weil unsere User doch etwas anderes wollen?
• Wieviel unserer Zeit verbringen wir damit, an Dingen zu arbeiten, die bereits abgeschlossen sind (Fehlerbehebung, Änderungswünsche, Behebung von schlechtem Code, ...)?

Wie erreichen wir beides?

"Doing things right" und "doing the right thing" sind zwei Dimensionen effektiver Arbeit. Aber ist es damit egal, in welcher Dimension wir zuerst in Verbesserungen investieren?

Grundsätzlich würde es erst mal mehr bringen, wenn wir besser darin würden, an den richtigen Probleme zu arbeiten, also uns in "doing the right thing" zu verbessern. Wenn wir mit der selben Geschwindigkeit Aufgaben mit höherer Priorität abarbeiten, liefern wir mehr Wert in der gleichen Zeit. Wenn wir andererseits sehr effizient die falschen Probleme lösen, bringt uns die höhere Geschwindigkeit nicht viel.

Nur, wie erfahren wir, 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 ("doing the right thing") und erst danach an der Effizienz zu arbeiten ("doing things right") mag lukrativer klingen. Aber es ist schwieriger, da wir nicht schnell genug das Feedback bekommen, das wir dafür brauchen. Und wenn wir nicht an den völlig falschen Themen arbeiten, bringt uns auch eine Effizienzsteigerung 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 uns auch helfen, bei der Ausrichtung der Softwareentwicklung an den Bedürfnissen unserer Benutzer besser zu werden. Und die Verbesserung 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.

Fazit

Peter Drucker hat einmal gesagt:

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”

-- Peter Drucker

Also würde es mehr bringen, zuerst sicherzustellen, dass wir an den richtigen Problemen in der richtigen Reihenfolge arbeiten und erst dann unsere Effizienz zu steigern. Aber das ist oft der schwierigere Weg.

Wenn wir zuerst unsere Arbeitsweise verbessern,

• schneller nach einer ersten Idee ein vorzeigbares Produkt liefern,
• hohe Qualität liefern und wenig Re-Work verursachen,
• ein gemeinsames Verständnis und gute Wissensverteilung aufbauen,

bekommen wir mehr Vertrauen und bessers Feedback. Das hilft uns die Probleme unserer Benutzer besser zu verstehen und an den richten 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 Benutzer 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 dieser Serie, "Agil—Das funktioniert do gar nicht", gehe ich auf Vorbehalte und Gegenargumente zu agiler 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...

Weitere Informationen

• Aktuelle Notizbuchseite als PDF
• Gottfried Szing, Verification vs. Validation