Deine Firma wird niemals Agil werden

Viele, vor allem große / ältere Firmen, führen Scrum oder SAFe ein - Trotzdem schaffen sie es nicht, wirklich agil zu werden. Hier erfahren Sie, warum...

Transcript

1. @iStock.com/diane39
2. Deine Firma Wird Niemals Agil Werden
3. @iStock.com/GlobalP
4. TL;DR Firmen haben Prozesse und Verhaltensregeln, die gewisse Arten von Veränderung verhindern. Veränderung ist schwierig
5. Hausaufgabe…
6. @iStock.com/GlobalP
7. Hausaufgabe…
8. Sie versuchen also, Agil zu werden… Hmmm…
9. @iStock.com/shotbydave
11. @iStock.com/TommL
12. @iStock.com/Paha_L
13. ABER
14. “True Business Agility” Benchmark: Lead time, um eine kleine Veränderung zu bewirken
15. Lead Time
16. Zeit von… @iStock.com/koun
17. Bis… @iStock.com/texelart
18. Das Problem:
19. @iStock.com/Rawpixel
20. @iStock.com/Andrew_Howe
21. @iStock.com/rgbspace
22. Ihre… • Organisationsstruktur • Prozesse / Regeln • Budgets / Bonussysteme • Mittleres Management • Motivation der Mitarbeiter Verhindern, dass ihre Firma agil wird!
23. Ist das wichtig?
24. Economic Darvinism HT to Uwe Friedrichsen
25. Ist das wichtig? Ja!
26. Werbepause ;) David Tanzer (@dtanzer) business@davidtanzer.net Ich helfe meinen Kunden: • Effektiver als Teams zusammenzuarbeiten • Ihre Arbeitsweisen zu verbessern • Softwaredesign und –qualität zu verbessern • Ihren Legacy-Code unter Kontrolle zu bringen. http://www.davidtanzer.net
27. Organisations- struktur
30. Kommunikationsproblem
32. +8 Werktage Lead Time! • Ops: Brauchen “deployment package” 1 Tag vor dem Release • Aber: Ihr braucht vorher Freigabe vom Release Management • RM: Freigabe innerhalb von 1-2 Tagen • Aber: Ihr braucht vorher ein Testprotokoll • QA: Liefert Testprotokoll 1-2 Tage nachdem Feature Fertig • Aber: Wenn sie einen Fehler finden, müssen Sie ihn beheben (1 Tag) und es muss erneut getestet warden (1-2 Tage)
33. + halbe Release Cycle Time!
34. Es ist oft noch schlimmer:
38. Oft wäre es besser, IT dort zu machen, wo sie benötigt wird, nicht in einer eigenen Abteilung!
39. Case Study: Dynatrace
40. “You always need pain for change.” Bernd Greifeneder
41. Man braucht langfristige Ziele
42. Man braucht Unterstützung auf allen Hierarchieebenen
43. Man muss die Firmenstruktur um 90 Grad drehen.
44. Jeder muss die Grundlagen "Agile" verstanden haben
45. Man muss Zeit und Geld investieren.
46. “Lead, follow, or get out of the way.”
47. “The way of the engineer: Solve all problems in a sustainable way.” Bernd Greifeneder
48. Motivation
49. Lob / Anerkennung
50. Regeln, die die Motivation zerstören…
51. “Refactoring muss vom Product Owner eingeplant werden”
52. Technical Dept Crappy Code
56. An diesem Punkt ist gar nichts mehr einfach oder billig!
57. Und: Die schlechte Qualität zerstört die Motivation!
58. http://www.davidtanzer.net/cc
59. Prozesse / Regeln
60. “Nobody sets out to create a bueaurocracy”
61. Wie man eine Bürokratie erschafft… In drei einfachen Schritten: • Etwas schlimmes passiert • “Das darf nicht mehr passieren – Niemals mehr!” • Neue Regeln
62. Bürokratische Regeln Organizational Dept?
66. An diesem Punkt ist gar nichts mehr einfach oder billig!
67. Und: All diese Prozesse und Regeln zerstören die Motivation!
68. “When pointing out a problem, also provide a possible solution.” Innocent (?) Example
69. Case Study: Smarter Ecommerce
70. Um agil zu bleiben, muss man seine Prozesse immer an die Leute anpassen, die man hat. Als manager muss man hier sehr viel empathie für seine Mitarbeiter und Teams entwickeln. Christian Gorbach
71. Prozessänderungen aktiv verfolgen
72. Prozessänderungen müssen aus den Teams kommen!
73. Die gesamte Firma muss agil sein
74. Wenn sich dein Produktmanagement weigert, agil zu arbeiten, wirst du niemals agil werden. Peter Rietzler
75. Budgets / Bonussysteme
76. Das Mittlere Management
77. Kleine / Junge Firmen
78. Noch nicht viele Regeln. Keine Zeit, eine Bürokratie zu werden!
79. “Survivor Bias” Noch keine Kriegskasse!
80. Von Entwicklern geführt “In order to be good at software development, you need an organization that’s optimized for software development” – Samir Talwar
81. Was Jetzt?
82. “Partial Agility” Nur in der Entwicklung? Nur in IT?
83. Vereinfacht. Schonungslos.
84. Erlaubt “Technical Excellence”. Erlaubt euren Mitarbeitern, ihren Job gut zu machen.
85. Vorsicht vor “Corporate Scar Tissue”
86. Bittet um Hilfe!
87. Hausaufgabe: Lob / Anerkennung
88. http://devteams.at /your_company_will_never_be_agile_intro
89. Danke! David Tanzer (@dtanzer) business@davidtanzer.net Ich helfe meinen Kunden: • Effektiver als Teams zusammenzuarbeiten • Ihre Arbeitsweisen zu verbessern • Softwaredesign und –qualität zu verbessern • Ihren Legacy-Code unter Kontrolle zu bringen. http://www.davidtanzer.net