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.
The alignment
@ziobrando
About me
Very hard to explain my job to my mother
running www.avanscoperta.it
Modelling (almost) everything with sticky no...
In the last years
• seen many more companies and ecosystems
• Went quickly to the core problems
• Started to see patterns
...
Big Picture Workshop
Invite the right people -> Business, IT, UX
Provide unlimited modelling space
Surface, Markers, stick...
Establish a timeline
Some facilitator tricks will kickstart
the discussion quickly
Explore with domain Events
The underlying knowledge
Enforcing the timeline
Experts will usually post a locally
ordered sequence of events
But enforcing a shared timeline then...
Outcome (big Picture):
The whole process is visible
Massive learning (crossing silo boundaries)
consensus around the core ...
Outcome (big Picture):
Multiple storytellings
Incremental Notation #NoUML #NoBPMN
A language for different tribes #Lean #U...
More specifically…
No scope limitation (paper roll)
Exploration of boundaries (External Systems &
People)
-> The BOTTLENEC...
Awesome!
… now what?
1. The shape of the problem
I might start here
But it starts from here
#BlameTheSilos
Silos must have a reason
Silos minimise the amount of learning
needed to be “productive”
unfortunately, the emerging
struc...
Asymmetry
And this is what you get
But fragmented knowledge
is only one ingredient
Let’s look at the outcome
There are recurring patterns in blockers
A clear business narrative
A massive
blocker
Recurring anti-pattern
“That’s our key class”
Big class with overloaded responsibility in the disputed land
between 2 (or more) Bounded Contexts
Nouns won’t helpEverybody agrees
what an order is?
Of course we do!
An order is an
order!
And has a
customer
too! Agreed!
Perfect recipe:
Talk with many people
Model Data-First (everybody agrees on
nouns)
Add some “Dogmatic DRY principle”
Repeat
The Big Ball of Mud
I swear it was a
monolith last time I
checked!!!
One solution
A Draft Model with
loose integrity
constraints
Constraints
implemented as
warnings
A Validation barrier (cons...
Data-first modelling is
flawed
And we knew it from Long Ago… #DDDesign
Everything is a code smell
here!
follow the money
• Bad code is everywhere!
• Implementation flaws with the
highest negative impact on the
enterprise are m...
Wait! Monoliths and BBoM
aren’t necessarily the
same thing!
Monoliths mechanics
It takes little to worsen the code
It takes a lot of effort to improve it
LEGO Entropy laws
Mixing LEGO boxes takes seconds
separating LEGO boxes takes ages
Database Entropy laws
Make a copy of an important table and give it a
nontrivial name
Measure how much time is needed to r...
Asymmetry
People will try to improve
systems only if they’re
going to be around long
enough to see the benefits
Will you clean your ...
Asymmetry
We can’t hire good
developers
A portion of our
codebase is so bad that devs quit
the company whenever we ask them
to touch...
Most companies don’t
understand technical debt
until it’s too late
They might, but waiting their “permission” is a losing ...
Refactoring stories won’t help you
• Product Owners will prioritise about what they know.
• Total transparency, but YOU ar...
…Hidden agendas, unclear
benefits, many other
reasons…
Asymmetry
Features bring revenues, refactoring reduce risk
If we could start from
scratch…
Conceptual boundaries
Implementation boundaries
2. The Impediment
Some companies attacked
the problem
Some didn’t
You don’t mess with the Bottleneck #ToCot
A clear business narrative
A massive
blocker
The author of the original
software was still around
The dungeon master
• Authors of the original code
• Only ones knowing some areas
• Can’t be beaten on their own playground...
And then I
discovered…
Bias: I only recommend books that prove me right.
“indefinite
procrastination”
We finally opened up
that portion of the
code!!
WOW! It was
smelling bad in 2011!!
It was bug...
Guilt?
protection?
We have a few problems
here
In a talent-driven job
market, nobody cares
about your monolith
Thin red line
• Start a project with a data first approach
• Lack of control requires protection & specialisation
• few pe...
Thin red line
• Postpone evolutions of critical software
• prevent the organisation from getting new feedback
• -> how lon...
They’re the same problem
We don’t have dungeon
masters: everything is developed by
contractors
People will try to improve
systems only if they’re
going to be around long
enough to see the benefits
Will you clean your ...
Accelerated Growth
• A few developers build up the foundations
• Success brings money -> Hiring frenzy #Scale #recruiting
...
3. The business
Not a single business
vision wasn’t flawed
There is value in “discussing business”
…and “Don’t worry about it” isn’t the b...
Transparency helps
People won’t self organise
around a system they don’t
understand
My personal experience
EventStorming +
Radical Transparency
A “culture” of rewarding exploration
a clear mission
Transparency is hard
Competing goals anyone?
“agile doesn’t work here”
The purpose of our
organisation is to make
money
so…
“agile doesn’t work here”
One more time: Agile
doesn’t happen in a vacuum
Purpose matters
Yep it’s Pink on Purpose
Good news: The Rise of
Good Companies
Conclusions
Sometimes you have to wrap-up
The curse of enterprise monolith
natural tendency
natural tendency
“It will pass”
is not a strategy
Monolith and dungeon
master are often the same
problem
The monolith is the
dungeon
Stop pretending that it’s
cheap
Events are way better to prevent it
can’t solve one ignoring
the other
#feelings & #Code
But the coding ecosystem
is OUR responsibility
Can’t delegate it to pixies
A clear business narrative
A platform for self-
organisation
Transparency & purpose
will make magic happen
Questions?
Every question is
welcome, except
“When will you finish
the book?”
Questions?
Thank you!
References
References
• www.eventstorming.com
• EventStormers on Google+
• https://plus.google.com/u/0/communities/113258571348605620...
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
The alignment
Próxima SlideShare
Cargando en…5
×

The alignment

1.791 visualizaciones

Publicado el

Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.

Publicado en: Liderazgo y gestión
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

The alignment

  1. 1. The alignment @ziobrando
  2. 2. About me Very hard to explain my job to my mother running www.avanscoperta.it Modelling (almost) everything with sticky notes, markers and a paper roll. Calling this stuff
  3. 3. In the last years • seen many more companies and ecosystems • Went quickly to the core problems • Started to see patterns • #SelectionBias
  4. 4. Big Picture Workshop Invite the right people -> Business, IT, UX Provide unlimited modelling space Surface, Markers, stickies Model a whole business line with Domain Events
  5. 5. Establish a timeline Some facilitator tricks will kickstart the discussion quickly
  6. 6. Explore with domain Events
  7. 7. The underlying knowledge
  8. 8. Enforcing the timeline Experts will usually post a locally ordered sequence of events But enforcing a shared timeline then triggers long awaited conversations
  9. 9. Outcome (big Picture): The whole process is visible Massive learning (crossing silo boundaries) consensus around the core problem
  10. 10. Outcome (big Picture): Multiple storytellings Incremental Notation #NoUML #NoBPMN A language for different tribes #Lean #UX #Agile #SW
  11. 11. More specifically… No scope limitation (paper roll) Exploration of boundaries (External Systems & People) -> The BOTTLENECK is in the picture. -> The CORE DOMAIN is in the picture
  12. 12. Awesome! … now what?
  13. 13. 1. The shape of the problem
  14. 14. I might start here
  15. 15. But it starts from here
  16. 16. #BlameTheSilos
  17. 17. Silos must have a reason Silos minimise the amount of learning needed to be “productive” unfortunately, the emerging structure of silos is hardly reversible Even small organisations will tend to become silos if not managed otherwise … if only we could make learning cheaper… ;-)
  18. 18. Asymmetry
  19. 19. And this is what you get
  20. 20. But fragmented knowledge is only one ingredient
  21. 21. Let’s look at the outcome There are recurring patterns in blockers A clear business narrative A massive blocker
  22. 22. Recurring anti-pattern
  23. 23. “That’s our key class” Big class with overloaded responsibility in the disputed land between 2 (or more) Bounded Contexts
  24. 24. Nouns won’t helpEverybody agrees what an order is? Of course we do! An order is an order! And has a customer too! Agreed!
  25. 25. Perfect recipe: Talk with many people Model Data-First (everybody agrees on nouns) Add some “Dogmatic DRY principle” Repeat
  26. 26. The Big Ball of Mud I swear it was a monolith last time I checked!!!
  27. 27. One solution A Draft Model with loose integrity constraints Constraints implemented as warnings A Validation barrier (constraints implemented as blockers) An Execution Model, with similar data structure, but different behaviour
  28. 28. Data-first modelling is flawed And we knew it from Long Ago… #DDDesign
  29. 29. Everything is a code smell here!
  30. 30. follow the money • Bad code is everywhere! • Implementation flaws with the highest negative impact on the enterprise are mostly related to missing or wrong bounded contexts
  31. 31. Wait! Monoliths and BBoM aren’t necessarily the same thing!
  32. 32. Monoliths mechanics It takes little to worsen the code It takes a lot of effort to improve it
  33. 33. LEGO Entropy laws Mixing LEGO boxes takes seconds separating LEGO boxes takes ages
  34. 34. Database Entropy laws Make a copy of an important table and give it a nontrivial name Measure how much time is needed to remove it #INeedToBeSure…
  35. 35. Asymmetry
  36. 36. People will try to improve systems only if they’re going to be around long enough to see the benefits Will you clean your hotel’s garden?
  37. 37. Asymmetry
  38. 38. We can’t hire good developers A portion of our codebase is so bad that devs quit the company whenever we ask them to touch it
  39. 39. Most companies don’t understand technical debt until it’s too late They might, but waiting their “permission” is a losing strategy
  40. 40. Refactoring stories won’t help you • Product Owners will prioritise about what they know. • Total transparency, but YOU are the expert.
  41. 41. …Hidden agendas, unclear benefits, many other reasons…
  42. 42. Asymmetry Features bring revenues, refactoring reduce risk
  43. 43. If we could start from scratch…
  44. 44. Conceptual boundaries
  45. 45. Implementation boundaries
  46. 46. 2. The Impediment
  47. 47. Some companies attacked the problem Some didn’t You don’t mess with the Bottleneck #ToCot
  48. 48. A clear business narrative A massive blocker
  49. 49. The author of the original software was still around
  50. 50. The dungeon master • Authors of the original code • Only ones knowing some areas • Can’t be beaten on their own playground https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.1koij6bk1
  51. 51. And then I discovered… Bias: I only recommend books that prove me right.
  52. 52. “indefinite procrastination” We finally opened up that portion of the code!! WOW! It was smelling bad in 2011!! It was buggy as hell… :-/
  53. 53. Guilt?
  54. 54. protection?
  55. 55. We have a few problems here
  56. 56. In a talent-driven job market, nobody cares about your monolith
  57. 57. Thin red line • Start a project with a data first approach • Lack of control requires protection & specialisation • few people become key, others retire or get minionized Business grows on top of old code • More responsibilities: less time to change it, harder to make the call • Hard to recruit seniors to finish the job
  58. 58. Thin red line • Postpone evolutions of critical software • prevent the organisation from getting new feedback • -> how long are your iterations? • Suddenly realise that the organisation is dumbed down and blames IT for everything
  59. 59. They’re the same problem
  60. 60. We don’t have dungeon masters: everything is developed by contractors
  61. 61. People will try to improve systems only if they’re going to be around long enough to see the benefits Will you clean your hotel’s garden?
  62. 62. Accelerated Growth • A few developers build up the foundations • Success brings money -> Hiring frenzy #Scale #recruiting • Hiring is too slow -> Outsourcing • External code is now maintained internally. • Builders -> controllers -> caretakers -> cleaners
  63. 63. 3. The business
  64. 64. Not a single business vision wasn’t flawed There is value in “discussing business” …and “Don’t worry about it” isn’t the best answer
  65. 65. Transparency helps
  66. 66. People won’t self organise around a system they don’t understand
  67. 67. My personal experience EventStorming + Radical Transparency A “culture” of rewarding exploration a clear mission
  68. 68. Transparency is hard
  69. 69. Competing goals anyone?
  70. 70. “agile doesn’t work here”
  71. 71. The purpose of our organisation is to make money so…
  72. 72. “agile doesn’t work here”
  73. 73. One more time: Agile doesn’t happen in a vacuum
  74. 74. Purpose matters Yep it’s Pink on Purpose
  75. 75. Good news: The Rise of Good Companies
  76. 76. Conclusions Sometimes you have to wrap-up
  77. 77. The curse of enterprise monolith natural tendency natural tendency
  78. 78. “It will pass” is not a strategy
  79. 79. Monolith and dungeon master are often the same problem
  80. 80. The monolith is the dungeon
  81. 81. Stop pretending that it’s cheap
  82. 82. Events are way better to prevent it
  83. 83. can’t solve one ignoring the other #feelings & #Code
  84. 84. But the coding ecosystem is OUR responsibility Can’t delegate it to pixies
  85. 85. A clear business narrative A platform for self- organisation
  86. 86. Transparency & purpose will make magic happen
  87. 87. Questions? Every question is welcome, except “When will you finish the book?”
  88. 88. Questions? Thank you!
  89. 89. References
  90. 90. 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

×