the alignment

The alignment

@ziobrando

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

In the last years

• seen many more companies and ecosystems

• Went quickly to the core problems

• Started to see patterns

• #SelectionBias

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

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 triggers long awaited conversations

Outcome (big Picture):

The whole process is visible

Massive learning (crossing silo boundaries)

consensus around the core problem

Outcome (big Picture):

Multiple storytellings

Incremental Notation #NoUML #NoBPMN

A language for different tribes #Lean #UX #Agile #SW

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

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 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… ;-)

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 (constraints implemented as blockers)

An Execution Model, with similar data structure, but different behaviour

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 mostly related to missing or wrong bounded contexts

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 remove it

#INeedToBeSure…

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 hotel’s garden?

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 it

Most companies don’t understand technical debt

until it’s too late

They might, but waiting their “permission” is a losing strategy

Refactoring stories won’t help you

• Product Owners will prioritise about what they know.

• Total transparency, but YOU are the expert.

…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

https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.1koij6bk1

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 buggy as hell… :-/

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 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

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

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 hotel’s garden?

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

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 best answer

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

ConclusionsSometimes 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/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