Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Optimized for what

3.083 visualizaciones

Publicado el

Most software development processes are focused on tracking and delivery. Unfortunately, writing code is no longer the bottleneck. The real bottleneck is the team ability to learn about the domain complexity and do the right thing.

Publicado en: Liderazgo y gestión

Optimized for what

  1. 1. Optimised for… @ziobrando avanscopertaAlberto Brandolini
  2. 2. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Lean #Entrepreneur #Developer #EventStorming #Coach #Facilitator #Consultant
  3. 3. Let’s start with a long boring recap Part 1
  4. 4. In principle there was “waterfall*”… *Yes, I know Royce actually meant a different thing. I just need a stereotypical villain as a starter. And no one applies waterfall the way royce intended anyway.
  5. 5. …but no one uses waterfall anymore
  6. 6. {end}
  7. 7. How did humans behave in there?
  8. 8. ...we wanted only one thing Well… 3 things actually Autonomy Mastery Purpose
  9. 9. We need to feel We did a good job
  10. 10. In principle there was waterfall…
  11. 11. The Pink Check (Early Waterfall) Autonomy: Totally depending on specs Mastery: Overdesigning architectures Purpose: Let’s not screw up everything this time! Note to technicians: The projector isn’t broken, it’s me. ;-)
  12. 12. After some months…
  13. 13. The Pink Check (Late Waterfall) Autonomy: guessing and cutting corners Mastery: Cowboy coding Purpose: Let’s get out of here (possibly alive)
  14. 14. The one thing “waterfall”is optimised for
  15. 15. …is finger pointing
  16. 16. What about “agile” then?
  17. 17. {Boring slide about the Agile Manifesto Omitted}
  18. 18. More specifically…
  19. 19. in Scrum… TEAM iteratively* delivering quality software in sprints Scrum Master removing impediments Product owner providing clear vision and priority ITERATIVELY*: means that you’ll rewrite existing software, when learning new stuff, with incremental, you can pile up crap week after week.
  20. 20. In principle there was waterfall…
  21. 21. The Pink Check (Ideal Scrum) Autonomy Cross-functional autonomous team Mastery Best engineering practices Purpose Satisfying customers, Shipping quality software week after week
  22. 22. Not bad, apparently
  23. 23. What is agile optimised for?
  24. 24. Responding to change?
  25. 25. But then I see this…
  26. 26. How many days is a story point?
  27. 27. And i realise the secret desire is predictability* *this color is “Boredom Grey” I took some risk in choosing it before checking the projector. I hope you can see it
  28. 28. But maybe…
  29. 29. Dan North deliberate-discovery/ “Learning is the bottleneck”
  30. 30. “Software development is a learning process Working code is a side effect” Me, whenever I have a chance
  31. 31. We’ve been optimising the wrong thing
  32. 32. Learning isn’t a deliverable note to self: if you’re reading this note you’re not looking at the audience.
  33. 33. Learning isn’t VISIBLE
  34. 34. BuT…
  35. 35. It’s developer’s (mis)understanding, not expert knowledge that gets released in production
  36. 36. Learning is an ASSET
  37. 37. In principle there was waterfall… with a little fine tuning…
  38. 38. When I look at this…
  39. 39. …I don’t see breakthroughs
  40. 40. Focus on predictable delivery is postponing breakthroughs
  41. 41. And of course “It Depends” There still will always be some boring activity still labelled “Software development” consolidated vs new domain Core vs non-core (supporting or generic) Change might be coming from the outside, so it’s a BET
  42. 42. More specifically In high value / High Risk areas, learning has a clear payoff In low value areas, you’ll be more likely to end up doing a watered down, tracking oriented, version of agile.
  43. 43. Focus on predictable delivery is postponing breakthroughs But the problem remains
  44. 44. Let’s get back to pink Well… 3 things actually Autonomy Mastery Purpose
  45. 45. we need to feel we did a good job
  46. 46. We’re programmers
  47. 47. We’re Learners
  48. 48. We’re hackers
  49. 49. Learning is going to happen anyway
  50. 50. Let’s try to see things with different eyes And now…
  51. 51. Product Owner as Domain Expert Antipattern
  52. 52. The context
  53. 53. The resulting knowledge #DDD
  54. 54. PO thinks: “I am going to do all the learning in order to speed up the coding” G ood guy, tries to help Terrible idea
  55. 55. Key feedback loops Sprint planning? Sprint retrospective? Backlog Grooming?
  56. 56. You just talk with me!
  57. 57. Oops
  58. 58. Pink Check: PO as Domain Expert Autonomy: Need to ask to the PO Mastery: … mmm Purpose: Making the PO happy (kinda weak…)
  59. 59. Patronising slide: Product Owner wasn’t intended to be that way, Managing priority and vision doesn’t mean “be a single source of truth”
  60. 60. Do I have a solution for that?
  61. 61. Of course I do!
  62. 62. Big Picture Workshop Invite the right people The ones with questions The ones with answers a facilitator Provide an unlimited modelling space Surface, Markers, stickies Start Modelling with Domain Events
  63. 63. But I already talked about it way too much
  64. 64. It’s about the problem, not my solution
  65. 65. A single person knowing everything is a risk
  66. 66. A single person pretending to know everything is an even bigger risk
  67. 67. But who can tell the difference?
  68. 68. User Stories as specification Antipattern
  69. 69. WOW! A template!
  70. 70. Not so far from reality As a Project Manager I want feature #245 So That we can release the project
  71. 71. I guess the “future conversation” was meant to be…
  72. 72. What’s the link to the specification?
  73. 73. Optimised for… reducing meeting time
  74. 74. Pink Check: User Stories as spec Autonomy: Need to ask to the PO, anyway Mastery: … mmm (feeling almost insulted) Purpose: deliver something on friday
  75. 75. Specifications are BORING
  76. 76. I won’t read your 200 pages spec
  77. 77. But I will read this
  78. 78. Learning is the arch-enemy of boredom
  79. 79. Boredom is the arch-enemy of Learning
  80. 80. So, whenever the specification is too detailed
  81. 81. Let’s add some new technology! Do you mean there’s a close connection between boredom and microservices? …Yes I do!
  82. 82. Learning how to ride a bike Exercise
  83. 83. Possible strategies Take a bike and ride it Ask a guy that rides a bike Read a book about bikes Talk to a guy that knows somebody that has a bike Read a specification document written by a person that probably interviewed some bikers
  84. 84. Even worse Take a bike and ride it Ask a guy that rides a bike Read a book about bikes Talk to a guy that knows somebody that has a bike Read a specification document written by a person that probably interviewed some bikers Read a specification document written by a guy that talked with the wheels guy, the chassis guy, the pedal guy and the tyres guy.
  85. 85. Let’s rename the pattern
  86. 86. Domain Expert as Spoiler Antipattern
  87. 87. I’ll write you a document so that you won’t waste time learning
  88. 88. …It’s not “wasted”
  89. 89. there’s a misconception about learning
  90. 90. Learning needs mistakes
  91. 91. expert Experience Experiments
  92. 92. 2012/12/REU-POY-157.jpg
  93. 93. possibly in a safe to fail context
  94. 94. Lessons learned There is a window of opportunity for asking newbie questions …better anticipate the learning. Looks like I am Quoting Dan North again:
  95. 95. The Dungeon Master Antipattern
  96. 96. Yes I am quoting myself, sorry.
  97. 97. Then I added this picture…
  98. 98. And then I discovered… Bias: I only recommend books that prove me right.
  99. 99. Pink Check: Dungeon Master Autonomy: as long as your chain Mastery: can’t beat the master in the dungeon Purpose: …
  100. 100. Learning check I’ll be learning somebody else’s perversion
  101. 101. Cadence Antipattern
  102. 102. uploads/2015/04/Learning-to-Walk.jpg
  103. 103. My kids Started Walking while on holiday Started Talking while on holiday Started Climbing while on holiday Started coding while on holiday
  104. 104. I see a pattern
  105. 105.
  106. 106. Unexpected Stimuli force us to think
  107. 107. But iterations are repeating in a boring way
  108. 108. Idea: take a ‘special day’
  109. 109. On a ‘Special Day’ People take deliberate actions to learn as much as they can Visiting or observing real users Engaging with real users Talking with experts Studying competitors … you name it!
  110. 110. Unfortunately…
  111. 111. ‘impediment list’ is long the agenda is already planned We can’t get out of office we’re already committed to a schedule We’re not supposed to do that We’re not paid for doing that Travelling is expensive
  112. 112. ‘impediment list’ is longer I won’t be able to calculate velocity any more It’s not my responsibility to do it
  113. 113. the temptation for predictability is still there…
  114. 114. Reinventing the wheel Antipattern
  115. 115. reinventing the wheel is learning
  116. 116. reinventing the wheel is necessary
  117. 117. Who’s got a pet project? accountants don’t have a pet balance sheet, we’re programmers
  118. 118. reinventing the wheel is necessary
  119. 119. But no one told us to mix them with production
  120. 120. Same office, same desk Antipattern
  121. 121. Same office, same desk Antipattern
  122. 122. Exchangeable “resources” Antipattern
  123. 123. I could continue for weeks…
  124. 124. Most of our working habits aren’t designed for learning
  125. 125. Developers in a vacuum
  126. 126. Where is the purpose?
  127. 127. Who are we helping?
  128. 128. Without a real purpose, we’ll find another one introducing new technology, pretending to write great code, maybe becoming a dungeon master one day
  129. 129. Find your users
  130. 130. Deserve yourself a “Thank you”
  131. 131. Wrapping up
  132. 132. learning is crucial, but…
  133. 133. Our environments aren’t designed for learning
  134. 134. In principle there was waterfall…
  135. 135. Take a different perspective and look for opportunities
  136. 136. Re-embrace change …with a lot of inspiration from the Lean Startup field
  137. 137. Managing tendencies is more interesting than blaming
  138. 138. We’re humans and we won’t change easily
  139. 139. Learning is going to happen anyway
  140. 140. Purpose is a great driver for doing a god job
  141. 141. Questions? Every question is welcome, except “When will you finish the book?”
  142. 142. Questions? Thank you!
  143. 143. References
  144. 144. References • • EventStormers on Google+ • 113258571348605620818 • LeanPub book in progress: • • Blog: • • • Twitter: @ziobrando • Trainings & Workshop facilitation: •