Optimized for what
•
18 recomendaciones•4,601 vistas
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.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Optimized for what
Similar a Optimized for what (20)
Más de Alberto Brandolini
Más de Alberto Brandolini (14)
Último
Último (20)
Optimized for what
- 2. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Lean #Entrepreneur #Developer #EventStorming #Coach #Facilitator #Consultant
- 3. Let’s start with a long boring recap Part 1
- 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. …but no one uses waterfall anymore
- 6. {end}
- 7. How did humans behave in there?
- 8. ...we wanted only one thing Well… 3 things actually Autonomy Mastery Purpose https://vimeo.com/15488784
- 9. We need to feel We did a good job
- 10. In principle there was waterfall…
- 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. ;-)
- 13. The Pink Check (Late Waterfall) Autonomy: guessing and cutting corners Mastery: Cowboy coding Purpose: Let’s get out of here (possibly alive)
- 17. {Boring slide about the Agile Manifesto Omitted}
- 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. In principle there was waterfall…
- 21. The Pink Check (Ideal Scrum) Autonomy Cross-functional autonomous team Mastery Best engineering practices Purpose Satisfying customers, Shipping quality software week after week
- 23. What is agile optimised for?
- 25. But then I see this…
- 26. How many days is a story point?
- 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
- 29. But maybe…
- 30. Dan North https://dannorth.net/2010/08/30/introducing- deliberate-discovery/ “Learning is the bottleneck”
- 31. “Software development is a learning process Working code is a side effect” Me, whenever I have a chance
- 32. We’ve been optimising the wrong thing
- 33. Learning isn’t a deliverable note to self: if you’re reading this note you’re not looking at the audience.
- 35. BuT…
- 36. It’s developer’s (mis)understanding, not expert knowledge that gets released in production
- 38. In principle there was waterfall… with a little fine tuning…
- 39. When I look at this…
- 42. 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
- 43. 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.
- 44. Focus on predictable delivery is postponing breakthroughs But the problem remains
- 45. Let’s get back to pink Well… 3 things actually Autonomy Mastery Purpose
- 46. we need to feel we did a good job
- 48. We’re Learners
- 49. We’re hackers
- 50. Learning is going to happen anyway
- 51. Let’s try to see things with different eyes And now…
- 52. Product Owner as Domain Expert Antipattern
- 53. The context
- 55. 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
- 56. Key feedback loops Sprint planning? Sprint retrospective? Backlog Grooming?
- 57. You just talk with me!
- 58. Oops
- 59. Pink Check: PO as Domain Expert Autonomy: Need to ask to the PO Mastery: … mmm Purpose: Making the PO happy (kinda weak…)
- 60. Patronising slide: Product Owner wasn’t intended to be that way, Managing priority and vision doesn’t mean “be a single source of truth”
- 61. Do I have a solution for that?
- 62. Of course I do!
- 63. 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
- 64. But I already talked about it way too much
- 65. It’s about the problem, not my solution
- 66. A single person knowing everything is a risk
- 67. A single person pretending to know everything is an even bigger risk
- 68. But who can tell the difference?
- 71. WOW! A template!
- 72. Not so far from reality As a Project Manager I want feature #245 So That we can release the project
- 73. I guess the “future conversation” was meant to be…
- 74. What’s the link to the specification?
- 76. Pink Check: User Stories as spec Autonomy: Need to ask to the PO, anyway Mastery: … mmm (feeling almost insulted) Purpose: deliver something on friday
- 78. I won’t read your 200 pages spec
- 79. But I will read this
- 81. Learning is the arch-enemy of boredom
- 82. Boredom is the arch-enemy of Learning
- 83. So, whenever the specification is too detailed
- 84. Let’s add some new technology! Do you mean there’s a close connection between boredom and microservices? …Yes I do!
- 85. Learning how to ride a bike Exercise
- 86. 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
- 87. 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.
- 90. I’ll write you a document so that you won’t waste time learning
- 97. possibly in a safe to fail context
- 98. Lessons learned There is a window of opportunity for asking newbie questions …better anticipate the learning. Looks like I am Quoting Dan North again: https://dannorth.net/2010/08/30/introducing-deliberate-discovery/
- 100. Yes I am quoting myself, sorry. https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.1koij6bk1
- 101. Then I added this picture…
- 102. And then I discovered… Bias: I only recommend books that prove me right.
- 103. Pink Check: Dungeon Master Autonomy: as long as your chain Mastery: can’t beat the master in the dungeon Purpose: …
- 104. Learning check I’ll be learning somebody else’s perversion
- 105. Cadence Antipattern
- 107. My kids Started Walking while on holiday Started Talking while on holiday Started Climbing while on holiday Started coding while on holiday
- 108. I see a pattern
- 110. Unexpected Stimuli force us to think
- 111. But iterations are repeating in a boring way
- 112. Idea: take a ‘special day’
- 113. 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!
- 114. Unfortunately…
- 115. ‘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
- 116. ‘impediment list’ is longer I won’t be able to calculate velocity any more It’s not my responsibility to do it
- 117. the temptation for predictability is still there…
- 119. reinventing the wheel is learning
- 122. Who’s got a pet project? accountants don’t have a pet balance sheet, we’re programmers
- 124. But no one told us to mix them with production
- 129. I could continue for weeks…
- 130. Most of our working habits aren’t designed for learning
- 135. Who are we helping?
- 136. Without a real purpose, we’ll find another one introducing new technology, pretending to write great code, maybe becoming a dungeon master one day
- 137. Find your users
- 138. Deserve yourself a “Thank you”
- 139. Wrapping up
- 141. Our environments aren’t designed for learning
- 142. In principle there was waterfall…
- 143. Take a different perspective and look for opportunities
- 144. Re-embrace change …with a lot of inspiration from the Lean Startup field
- 145. Managing tendencies is more interesting than blaming
- 146. We’re humans and we won’t change easily
- 147. Learning is going to happen anyway
- 148. Purpose is a great driver for doing a god job
- 149. Questions? Every question is welcome, except “When will you finish the book?”
- 151. References
- 152. References • www.eventstorming.com • EventStormers on Google+ • https://plus.google.com/u/0/communities/ 113258571348605620818 • LeanPub book in progress: • http://leanpub.com/introducing_eventstorming • Blog: • https://medium.com/@ziobrando • http://ziobrando.blogspot.com • Twitter: @ziobrando • Trainings & Workshop facilitation: • http://www.avanscoperta.it