ScrumTisch – Wo hört Fehlerkultur auf und fängt Schlamperei an?

Wir bei cosee entwickeln Software. Dabei passieren immer wieder kleine und große Fehler. Und jedes Mal stellt sich die Frage: War das vermeidbar? Haben wir hier einfach nur geschlampt? Andererseits hilft es nicht, jede Entscheidung endlos zu planen und abzusichern. Denn Fehler helfen uns, wichtige Lektionen zu lernen. Wie aber stellen wir das Lernen sicher? Konstantin gibt Beispiele, mit welchen Techniken er und das cosee-Team versuchen, aus Fehlern zu lernen.

Transcript

1. Wo hört Fehlerkultur auf und fängt Schlamperei an? Konstantin Diener | cosee GmbH konstantin.diener@cosee.biz | @onkelkodi u
2. KONSTANTIN DIENER CTO und Gründer von cosee
3. Backend Mobile Frontend DevOps Agile Coach
4. Warum sind Fehler auf einmal cool?
5. „Wenn wir nur genügend drüber nachdenken, können wir alle Fehler im Vorhinein ausschließen …!“
6. Werner Vogels, Amazon „Everything fails all the time“
7. https://blog.github.com/2018-10-30-oct21-post-incident-analysis/
8. 43 sec Verbindungsausfall …
9. … über 24 h Teilausfälle
10. Facebook „Done is better than perfect.“
12. Jeff Patton, User Story Mapping, https://jpattonassociates.com/
13. Fehler sind schon länger cool.
14. Nicht: Schuldige bestrafen
15. Der „Schuldige“ war der Meinung …
16. • ... das, was als Folge seiner Handlung eingetreten ist, nicht möglich sei. • ... oder das, was passiert ist, nichts mit seinen Aktionen zu tun hat • ... oder die Erreichung des gemeinsamen Ziels jede Art von Risiko wert ist.
17. Abschreckung verringert Sicherheit
18. psychologische Sicherheit
19. Blameless Culture
20. https://www.shutterstock.com/de/g/maxym
22. Was bedeutet das?
23. Fehler #1: User Facing Bug
27. Lösung: automatisierte Tests
29. Tests nicht ausgeführt!
31. abgelaufenes SSL-Zertifikat
32. Fehler #2: brandneues Team
38. Nicht alle Fehler selbst machen!
39. https://www.owasp.org/index.php/Top_10-2017_Top_10
40. Werkzeuge
41. • Retrospektiven • Tests • Checklisten
42. Blameless Postmortems
43. https://blog.github.com/2018-10-30-oct21-post-incident-analysis/
44. • User-visible downtime or degradation beyond a certain threshold • Data loss of any kind • On-call engineer intervention (release rollback, rerouting of traffic, etc.) • A resolution time above some threshold • A monitoring failure (which usually implies manual incident discovery)
45. Backend Mobile Frontend DevOps Agile Coach > https://cosee.jobs