Mean Time to Feedback

• 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

"Validate every step"—Überprüfe jeden Schritt. Wir brauchen in der agilen Softwareentwicklung überall schnelles und gutes Feedback. Die Zeit, bis wir brauchbares Feedback zu unserer Arbeit bekommen—die "Mean Time to Feedback"— ist entscheidend. Und darüber möchte ich in diesem Teil der Serie "Quick Glance At: Agile Engineering" mehr erzählen, während es letztes Mal um Geschwindigkeit an sich ging.

Ich habe zu jedem der Teile vorgedruckte Notizblockseiten vorbereitet.

Dort findest du Informationen zum aktuellen Teil, genug Platz für deine Notizen und auch, um Fragen zu beantworten. Fragen wie z.B. diese:
Welche Arten von Feedback in der Softwareentwicklung fallen dir ein?
Wo findest du bei deiner aktuellen Arbeit Feedbackzyklen?
Schreibe die Antworten in deinen Notizen auf.

Feedback und Iteration

Agile Arbeitsweise ist iterativ und inkrementell. Iterativ bedeutet, kurz gesagt, dass wir immer wieder dieselben Phasen durchlaufen und dieselben Tätigkeiten durchführen. Inkrementell bedeutet, dass wir nach jeder Iteration ein weiter verfeinertes Ergebnis liefern, das auf dem vorigen Ergebnis aufbaut. Mehr dazu dann in späteren Teilen, wo ich erkläre, was das konkret für verschiedene Aspekte der Softwareentwicklung und Engineering-Praktiken bedeutet.

Welche Iterationen gibt es?

In Schaubildern zu Scrum findet man zum Beispiel zwei Zyklen: Die tägliche Iteration und den größeren Iterationszyklus der Sprints. Aber es gibt noch mehr Iterationen, die wir im Agile Engineering finden können; Robert C. Martin hat zum Beispiel über "The Cycles of TDD" geschrieben.

Aber warum arbeiten wir iterativ und inkrementell?

Dafür gibt es zwei große Gründe und beide habe ich im vorigen Teil der Serie erklärt:

1. Wir wollen früher einen Return für unsere Investitionen generieren.
2. Wir wollen früher Feedback bekommen um schneller reagieren zu können.

Granularität von Entscheidungen

Wir treffen Entscheidungen auf verschiedenen Ebenen, z.B.:

• Wie soll ich diese eine Variable benennen?
• Sollen wir den Verkaufsprozess für verschiedene Märkte flexibel konfigurierbar machen?

Die zweite Entscheidung ist groß. Wirklich groß. Sie hat massive Auswirkungen auf die Kundenzufriedenheit, die Softwarearchitektur und den Betrieb. Die Umsetzung wird lange dauern und Budgets und Ressourcen verschlingen, die an anderer Stelle nicht zur Verfügung stehen. Solche strategischen Entscheidungen wird man auch nur sehr selten treffen. Und wir, aus dem Engineering, müssen bereit sein, bei solchen Entscheidungen zu unterstützen.

Die erste Entscheidung sieht dagegen unbedeutend aus. Solche Entscheidungen treffen wir mehrmals pro Stunde und oft denken wir gar nicht richtig darüber nach. Aber trotzdem ist sie wichtig, wenn auch auf eine andere Weise: Sie trägt zur Lesbarkeit und Verständlichkeit des Codes—also zum Softwaredesign—bei. Oft gibt es dazu auch gar kein Feedback oder erst sehr spät, im Code Review; Und auch nur dann, wenn der Name wirklich schlecht war.

Und für beide Entscheidungen können wir uns überlegen, wie wir schneller an besseres Feedback kommen können. Dafür haben wir Techniken im Agile Engineering. Bei der ersten Entscheidung könnte die Lösung für schnelleres Feedback z.B. Pair Programming sein, bei der zweiten Spikes und Continuous Delivery.

Weitere Arten von Feedback

Aber das sind nicht die einzigen Schritte, die wir validieren sollten und für die wir Feedback benötigen.

Arbeiten wir gerade an den richtigen Problemen? und implementieren wir unsere Software so, dass die Lösungen für die Benutzer brauchbar sind?

Zwei wichtige Fragen, die wir uns sehr oft stellen. Deshalb werden sie auch in allen agilen Vorgehensweisen adressiert: Wir implementieren iterativ und inkrementell, präsentieren ständig unsere Ergebnisse, liefern lauffähige Software sofort aus und berücksichtigen das Feedback immer gleich. Also, eigentlich sollte es so laufen, aber in Wirklichkeit gibt es meistens Richtlinien, Zielvorgaben, Konflikte und andere Kräfte im Unternehmen, die uns dann doch daran hindern, genau so zu arbeiten.

Pausiere hier mal kurz und notiere in deinen Unterlagen:
Wie schnell bekommt ihr Feedback zu euren implementierten Features?
Was hindert euch daran, es schneller zu bekommen?
Was hindert euch daran, euer Vorgehen anhand des Feedbacks sofort zu ändern?

Und dann gibt es noch andere Schritte und Entscheidungen, die wir validieren müssen: Softwarearchitektur- und Design, Testdesign, Arten von Tests, welche Tests wir automatisieren, ob ein Deployment funktioniert hat, etc. Welche Weiteren fallen dir noch ein?

Schnelleres Feedback

Im vorigen Teil der Serie ging es darum, dass schnelleres Feedback dieses Feedback wertvoller macht. Dass wir nur durch häufigere Lieferung Zeit, Resourcen und Geld sparen können—auch, wenn wir dadurch natürlich kleinere "Portionen" implementieren und somit in einem gewissen Zeitraum gleich viel "Umfang" liefern.

Wie können wir in jedem Schritt besseres Feedback schneller bekommen?

Viele Vorgehensweisen im Agile Engineering helfen uns an dieser Stelle. Wenn wir also diskutieren wollen, ob Test-Driven Development oder Pair Programming Zeitverschwendung sind oder auch wertvoll sein können, müssen wir genau diesen Aspekt mitberücksichtigen.

Und wir sollten auch selbst kreativ sein und überlegen, wie wir unsere Mean Time to Feedback verbessern können. Wenn ihr nach Scrum arbeitet, wären z.B. das Refinement Meeting, das Sprint Planning und die Retrospektive gute Zeitpunkte dafür.

Fazit

"Validate every step"—Überprüfe jeden Schritt. Dieser Punkt aus der "Agile Doctrin", die ich in einem früheren Teil der Serie vorgestellt habe, hilft uns bei der agilen Softwareentwicklung:

• funktionierende Software zu liefern
• mit unseren Kunden und Benutzern zusammenzuarbeiten
• auf Veränderungen zu reagieren

Dafür brauchen wir so frühzeitig wie möglich gutes Feedback. Schnelleres Feedback hilft uns auch, Zeit, Kosten und Ressourcen zu sparen.

Und viele Praktiken und Vorgehensweisen in der agilen Softwareentwicklung sind genau darauf ausgelegt, schneller Feedback zu bekommen und dann auch die Möglichkeit zu haben, dieses Feedback sofort zu berücksichtigen.

Heute habe ich erklärt, warum wir die mittlere Zeit, bis wir gutes Feedback bekommen, optimieren sollten. Im nächsten Teil der Serie geht es um "doing things right", also gut darin zu sein, Software zu entwickeln und "doing the right thing", also an den richtigen Problemen zu arbeiten. Und es geht um die Balance der beiden Themen.

Am Ende nimm dir noch einmal kurz Zeit, um in deinen Notizen Folgendes zu beantworten:
Was könnte dein Team in den nächsten 1-2 Wochen tun, um bei einem Schritt schneller oder besseres Feedback zu bekommen?

Weitere Informationen

The Cycles of TDD Agile Manifesto