Clear your calendar. Something big is happening in Berlin in October 2025!

We’re thrilled to announce that Avanscoperta is joining forces with the KanDDDinsky Conference to co-organize the Pre-Conference Workshops in Berlin!

One city. Two days. Four Masters.

Calling all Software Developers, Architects, Tech Leads

📅 October 20 - 21, Berlin

We’re bringing together leading minds in Domain-Driven Design for two days of immersive, hands-on learning before the main event:

🙋 Strategic Design for Software Teams, with Eric Evans
⚙️ Event Sourcing & CQRS Master Class, with Marco Heimeshoff
🔶 EventStorming Master Class, with Alberto Brandolini
💬 Practical Messaging Workshop, with Ian Cooper

🙋 Strategic Design for Software Teams, with Eric Evans

Design decision-making for large systems, teams, and legacy challenges

Strategic Design is a 2-day deep-dive workshop led by Eric Evans, the book Domain-Driven Design: Tackling Complexity in the Heart of Software, known globally for introducing essential tools like context mapping, core domain focus, and bounded contexts.

This workshop gives Development Leaders, Architects, and Technical Managers the mindset and tools to make meaningful design decisions in complex, multi-team environments, even when legacy constraints are involved.

⚙️ Event Sourcing & CQRS Master Class, with Marco Heimeshoff

Learn to Model, Evolve, and Scale Complex Systems

Join Marco Heimeshoff for a 2-day, hands-on workshop. You’ll master CQRS and Event Sourcing to design systems that are scalable, testable, and ready to evolve. Built on real-world practices you can apply immediately.

🔶 EventStorming Master Class, with Alberto Brandolini

The visually effective problem-solving technique that puts everyone on the same page

EventStorming is the fastest way to explore and model a complex business domain, in an event-driven fashion: join the Master Class with his creator Alberto Brandolini!

💬 Practical Messaging Workshop, with Ian Cooper

Transform Your Distributed Systems with Messaging Patterns

Join Ian Cooper and learn how to design and implement reliable, scalable messaging solutions for your distributed architectures. Build the skills you need to succeed with event-driven systems and take your software design.

Avanscoperta loves KanDDDinsky  

We’ve teamed up with the KanDDDinsky team to bring you a series of pre-conference workshops designed to make your KanDDDinsky experience truly special. Together, we’re curating intense, hands-on sessions that go beyond theory, helping you apply powerful ideas in practice.

This collaboration blends our shared passion for learning, community, and meaningful software design.

Join us!

Whether you're deepening your knowledge or exploring new ground, these workshops are the perfect way to immerse yourself in practical, collaborative learning before the main conference begins.

The pre-conference workshops are the perfect chance to learn and work with people coming from different contexts and level up your skills.

Tickets are limited, don't wait too long to grab yours.
Check the KanDDDinsky Website, choose the workshop and join us now! 🤩

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

We’ve been into remote working for years now. It started as a smart alternative played by some niche organisations; it became the de facto standard for many organisations during the Covid-19 pandemic and became a mainstream possibility after the restrictions were lifted.

In the meantime, companies and teams learnt how to use different tools in their jobs. Technology was a strategic enabler for these new ways of working, providing better tools for collaboration and coordination in a market that boomed in size.

Remote work shouldn’t be an interesting topic anymore. It’s normal. It’s boring.

Except, something isn't quite right. Organisations aren't settling on a new paradigm and trying to roll back the change. Others embraced the new paradigm, but they're turning into something different. Something isn't yet working as it should, and it’s hard to pinpoint exactly what’s wrong.

For me, it all started with a feeling of growing dissatisfaction. We deliberately moved to remote work before the COVID-19 pandemic, and when the world was forced into the new standard, we were already prepared.

Slowly, things started to worsen. Solving non-trivial problems started taking longer than usual. Meetings were more likely to turn out inconclusive, and the team inertia was growing. We were still a small company, but changes were slower. And everything was so boring.

Consulting for clients wasn’t much better. Despite preparation efforts and multimedia support, online meetings weren’t effective. Ideas weren’t landing as they used to be. Conversations weren’t so actionable.

I started investigating the matter a little better as a systemic issue, trying to move beyond the mainstream narrative. I knew what an effective organisation tasted like, and we were shifting from grandma’s recipe to microwave food.

What I discovered wasn’t nice. The long-term consequences of remote work were stiffening my company, but we weren’t alone. Remote work introduced new habits, tools, and constraints that progressively turned from reasonable choices into addictions. And this was happening everywhere.

Remote work is undermining the organisation’s ability to evolve. And it has very little to do with us. It's a systemic problem that in most cases doesn't have a valid solution. I guess I need to provide some more background.

It's not only about work

When talking about remote work, we reasonably focus on the most visible part of the work. Software developers can probably code more effectively from home than from an office where they must wear noise-cancelling headphones. But that’s only one side of the work.

An evolving team or organisation must balance their focus between doing today’s job well and improving to be better tomorrow. One more version of the chicken and egg problem.

If we split remote problem work into these two perspectives, we can have many context-dependent narratives about the impact of remote work on business as usual; it’s very hard to find positive narratives about the current ability of organisations to evolve and reinvent themselves.

Diagnosing problems, designing solutions, building consensus, and implementing changes all seem to take more time and energy and be less effective.

Not every organisation needs to evolve at the same pace. Some industries evolve faster than others, and often, you only need not be as fast as your slow competitors to survive. But few have the privilege of deciding when they need to change. The world outside does, and now AI is spurring a new wave of transformation before you completed the previous one.

While we progressively discovered ways to perform complex tasks and deliver value remotely, we still haven’t found a decent solution to vital issues like onboarding juniors and building trust.

Have you tried …?

Meanwhile, we underestimated the consequences of the countermeasures we found to enable remote work. Online meetings can be almost as good as the in-person version and even more convenient if they involve travel. Still, they deplete brain energy faster and are more prone to dysfunction and uselessness. There’s less bandwidth in a remote meeting. You can’t kick your colleague’s leg under the table to stop them from saying something inconvenient, or you can’t offer homemade snacks to create a friendly atmosphere.

The most severe blow to the remote organisation ecosystem involves transparency and trust.

No matter how much you share on the company wiki, something will still not be visible. And no matter how much you invest in corporate retreats and team-building moments, trust will be built slowly and eroded faster in a remote organisation.

We got rid of the embarrassing motivational posters from the eighties, and that’s a plus. But we also severely harmed the observability of our work and the effectiveness of key practices like leading by example, Gemba, inspect and adapt and so on without finding a valid replacement.

Trust is probably the most critical issue. It is harder to build trust remotely and easier to lose it. Many organisations that turned remote didn’t realise they were running on a trust capital they accumulated in the past but could not find good ways to replenish it. They put hope in team-building events, inflating the expectations for corporate retreats in fancy locations, often with disappointing results.

Technology isn’t the solution

Technology has been a fantastic enabler for remote work. Cloud services make it possible to coordinate a distributed team without being colocated. Tools like Zoom and Miro’s relentless effort to improve their user experience make the interaction better and better. Chapeau!

But are the tools good enough? No, they’re not. Online meetings are still an intrinsically depressing experience, no matter how good your background image, microphone, or light. Online modelling will inevitably be less interactive than being in the same room with a good whiteboard, markers, and an engaged audience.

Almost is the keyword here. Online tools can give you almost what you need; this gap will make all the difference.

Technology is also taking something back: you must build templates for your Miro boards supporting critical meetings. More and more meetings will need active facilitation and precise time management. This doesn’t happen for free: extra time will be needed for preparation, but more importantly, extra attention will be needed to keep everything under control in a remote setting.

I said attention. But I could have said brain energy. Online tools are depleting our brains faster. Our minds more easily wander around in a boring meeting, and we’re spending an extra amount of free will, forcing ourselves to be focused.

“Am I boring you?”

“Yes, but it’s not personal. It’s the format.”

Free will, focus and intentionality are not free meals. They are the scarcest resources in a world continuously craving your attention, and we are consuming them faster.

This is not my experience!

I have no idea about your overall experience with remote work. Maybe it’s working for you, or maybe you think it’s working for now. I am reading signals and connecting dots; many signals point in the same direction. And this direction is scary.

There are exceptions. I know of organisations that were designed around the notion of remote work and that were successful this way. It may be interesting to explore their recipe to understand whether it is truly replicable.

Others were only temporarily successful, like Nassim Taleb’s turkey, which reported receiving free meals every day until Thanksgiving.

On this topic, context is more important than ever. Company size, industry, working relationship, role, country, market, and so on affect how remote work impacts the ecosystem. Every ecosystem is different, and our experience can only tell us so much. This obviously affects me as well.

While biases are true for many problems, remote work affects our perception, reducing visibility and, ultimately, the perception of system-level problems.

Using only your personal experience to discuss remote work is like assessing that you’re funny after drinking a bottle of wine.
You are not the one to ask.

Remote fragmented the work ecosystem into many unique bubbles. Your remote is not my remote. We think we’re discussing the same thing, but we’re not.

No quality conversation

Talking about remote work is hard. Raising the topic in a normal setting often lowers the level of the conversation. Since everybody has tasted remote work, everybody feels entitled to join the conversation without realising we are coming from many different bubbles.

The rush to remote work during the 2020 lockdowns had the side effect of synchronising the remote clock for too many organisations. Remote was already there, with its hype cycle, early adopters, etc. The moment remote became a global issue, everybody joined the conversation simultaneously, ready or not.

Some of this conversation became global, with the feeling that “we are in this together.” Boundaries disappeared, and terms became blurred. Newsmagazines spread watered-down descriptions, and legislators added their contributions. “Smart Working” (in English) is an official way to designate remote work contracts for Italian employees.

Remote work also affected workers’ lives in hardly reversible ways. Moving from a really expensive neighbourhood to a more affordable one and establishing a better financial status, work-life balance, and family routines isn’t something to give up without fighting.

So, touching this nerve often makes the conversation emotionally harder to manage. Even worse, some organisations (context, again) took the hard stance of forcing employees back to the office, making remote work look like a third-millennium class struggle.

Talking rationally about a complex problem that is heavily context-dependent and has massive emotional strings attached seems like a recipe for disaster. And it often is. Most conversations I had didn’t end well. They quickly leaned into the left side of this spectrum, where for every problem raised, there is a balancing narrative stating that "It works for us", dragging the conversation into the inconclusive space.

I felt stressed, angry, and sometimes cheated. I was flooded with fallacies, biases and emotional overload, but I had very few truly challenging arguments. I knew it would happen, but is this a good reason not to point at the iceberg?

Remote is here to stay

Typically, this is where somebody plays a straw man argument like: “So you’re suggesting to go back to the office? I am not. I am pointing at a complex, underestimated problem, and the solution won’t be as easy as a catchphrase.

We discovered that the office routine was based on a weak assumption: “The office is the workplace.” The moment the assumption was invalidated, the system became unstable, and irreversible changes happened. Some locations were dismissed, and restaurants and pubs in office areas closed because of reduced business.

Choosing individually to return to the office won’t give the expected results if your colleagues aren’t there too. You’ll be trapped in hybrid-remote rituals even if you’re physically there. Making Zoom calls instead of going to the upper floor. Remote poked a bubble.There is no rewind button, and I am not looking for it.

What's next?

As I said earlier, I am reading signals and connecting dots. I am trying to have a meaningful conversation and warn you about a potential threat. I started talking about these problems a while ago, but started connecting more and more dots while preparing my keynote speech at XP2024 conference in Bolzano.

That gave me momentum, and led me to discover some more evidences and dots to connect. Too much for a single blog post, the plan is to build a more articulated narrative and see where it leads me. More posts coming!

This blog post is the transcription of the chat we had with Oskar Dudycz about his Event Sourcing workshop on 12 February 2025.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Would you tell us something about your upcoming workshop and what is it?

Oskar: I’m a huge believer that event-driven architectures and event sourcing can bring a lot into the game, like observability - both technically and from the business standpoint - and also a good synergy in reflecting our business domain requirements into our code.

I’ve been doing that for many years, starting as a regular developer, architect, manager, etc., and I saw those benefits in my projects. Working on the tooling, such as EventStoreDB, Marten, Emmet, I gathered a lot of experience, and not only good one… We were even joking before going live that you cannot always be the best version of yourself.

That's also why I started doing those types of workshops—to help people get started quickly, be more productive in event sourcing, and reap the benefits that I mentioned.

I always think that the best way to learn is to learn from your own mistakes, and that may be the best type of learning, but I don't think that this is always the fastest way to learn.
If at least one can learn something from my mistakes and past projects, then that type of workshop can smoothen this journey because, unfortunately, event sourcing is too often pictured as a complex or even complicated way of building applications. I disagree with that. I know that it can be like that, but it doesn't have to be.

And that's what I want to show during the workshop. We’ll be doing this very hands-on. For most of the workshop, people will get their hands dirty in code and build their own application from scratch. Of course, we start from a simpler application, but it's still quite real-world, and I think it could be a good starting point for including that in their projects or maybe at least to have fun. That's also important.

Avanscoperta: We already anticipated that the workshop will be extremely hands-on and with a particular focus on coding. At Small Talk we always go with the basics first, so we just discussed what the workshop is about.
The next questions is then about event sourcing. What is it? Why should one care? Why is it so relevant today in your opinion?

Oskar: Event sourcing is a storage pattern. It can be seen in a similar category as relational way or document way. And each type of storage has its own benefits.

The biggest benefit of event sourcing is that you are not losing the business information.

It works like this: we are making decision, such business logic or like regular “if” in our code, and then as an outcome, instead of just overriding the current state, we are storing additional information, additional facts, which is called event.
In event sourcing, the name comes from the fact that events are the source of truth. So there is no other state.

For instance if we are modeling the guests’ stay in the hotel, then we can record events like “guest checked in”, “night state charge recorded”, “spa payment made”, “guest checked out”. So all of those events are representing a specific fact that happened during the business workflow.
And most of the time, in our industry, we had to optimize for the storage size. And because of that, relational databases with normalization and the possibility to reduce the size of the data to not repeat all that information were really popular.

Nowadays, data storage is relatively cheap, but the information is priceless. So the more we can keep this business context, the more we can make better decisions and get better insights from our business workflow.

I really love the sentence by Anita Kwamme is that:

event sourcing is architecting for the tomorrow's questions.

I'm really jealous that I didn't come up with the sentence on my own.

Avanscoperta: So who is this workshop for?

Oskar: This workshop is definitely for engineers. It will be a very hands-on experience.
It’s probably aimed for people who already did some application, such as web API, or they did some business logic, etc., but you don't need to be an extremely skilled developer.

You might be still a junior, you might be an architect also. As long as you can write simple code in C#, Java, or TypeScript, you should be fine.
I will be introducing all the concepts from the beginning, and we will be doing a gradual step-by-step learning experience.
I think that this approach is also good for the people that already are doing event sourcing because it's a good chance to ensure that you didn't miss something.
But as you know, each group has its own dynamic. So if the majority of people are more experienced, then we can go a bit faster.
In general, I'm always trying to ensure that no one will be lost during the workshop.

Shall I share my screen for a second and show how the exercises will look like?

Avanscoperta: Sure, we said we don’t have slides at Small Talk but screen sharing is always fine.

(You might wanna check out the video on YouTube for the screen sharing part, from minute 10 more or less.)

Oskar: As I mentioned, we’ll be working with Java, C# and TypeScript, and we will have the same flow.

But as you see, we will be going from the events definition, then how to get the state from events, how to append events, how to run the business logic, how to build the the application logic and then also read models, etcetera.

And just to prove that no one will be lost, for instance, this exercise starts with basic modelling and putting in code your events, so not much there. But then the next exercise starts with the solution of the previous one.
The exercises are not so important on their own, but they are built in a way so that they are polished throughout the years that I've been doing this workshop, so I'm putting some places here and there to trigger the discussion.

The most important thing it's not coding, it's learning through coding.

I believe that for this type of workshop the more hands-on the better because then you will see that it's not that hard and it's not that scary. At least that's my idea behind it.
And of course we will be doing some sticky notes and basic EventStorming because how can we not do it if we are here with Avanscoperta?
But jokes aside, that approach really plays well with event sourcing because both have the idea of making it easier having proper discussions.

Avanscoperta: So we just got the big picture (pun intended) about what we’ll be doing in this workshop - there will be code, Miro, screen sharing, group exercises, etc.
One thing I really liked is your statement about “it's not about coding but about learning through coding”.
Of course we are all fans learning by doing and all of that, but if there is some help from someone who already made some mistakes and can ease the learning process somehow, that's really cool.
And also the learning through coding idea is really effective and I believe folks will like it, especially because we are also targeting people who we can classify as beginners or juniors, as well as folks who already know what to do, but maybe need some refresh or want to see other perspectives… because learning by coding means talking to other people that are exactly like us.

One thing we like to do with our workshops is to keep them in the range of 12-16 people, so it's not like everyone is sitting in front of their screens watching slides or Oskar talking with their camera off.

In a nutshell - it will be extremely interactive and therefore each one of you coming to the workshop will have an active role in this.

Oskar: All the exercises are intended to be short and I don't expect any one to complete all of those exercises because that's not the goal. The goal is to understand each concept and that's not only by solving 100% this coding exercise. That's something that you can do and repeat on your own time, but this is just to show practically how that works and having a proper discussion, asking questions and having those questions triggered, because I really believe that coding is also a form of design. That's at least how I see it.

Avanscoperta: Each of our trainers has a story of either solving problems, at one point being asked to do something, or just feeling natural about starting to teach. So, how did it start for you? Why are you doing this workshop?

Oskar: Somehow I always wanted to teach, maybe because my father and my grandparents were always telling me that I should help others to learn and sometimes I was even helping during like a primary school my friends.

I really struggled with event sourcing at the beginning. It started with reading so many articles, watching all of Greg Young's talks, etc. It was eight or nine years ago, and there were way fewer resources compared to now.

Then I finally got the chance to use event sourcing in my project and I thought, “This is my moment”. I started to design and work on this application and I realized that I have no idea what I'm doing. And my first thought was, “This event sourcing is terrible. Why did someone invent that?” But then I thought, “Okay, so many smart people are doing it, then probably that's something wrong with me”.

I'm somehow a grinder. I do not necessarily recommend being that type of person, but I always try to push myself to at least ensure that I'm not doing something wrong. So then I started to learn and doing small exercises, and sharing that in public.

I also started to be more active on Marten’s GitHub at that time. Marten is one of the tools that I eventually co-created in a .NET space for event sourcing, and I saw that people were having the same issues that I had.
And I started to answer them with the solutions that I found. And those solutions were helpful for the people.

Step by step, taking baby steps, I realized that maybe my journey, my findings, and my knowledge about the tools could help other people to make it easier.

Plus, I think it was also some kind of challenge for me because in my projects, I saw that event sourcing doesn't have to be that hard or scary.
It's also kind of addictive that when you start to do that and you get your “aha moment,” you just want to continue doing it. So maybe I wanted to show people that it doesn't have to be as it is mostly pictured. So it was a mix of all these reasons.

In the end, as I was maintaining Marten for a few years, I was working at EventStore, now called Kurrent after rebranding, and I also built Node.js tool Emmet. So I also wanted to teach people how to use those tools correctly.
So that was my main motivation. But I just truly believe that event sourcing should have wider usage. It is a niche approach, but it should be a much broader niche, and not this small, because it can help many projects.
I'm not in the team to say that you should do every event sourcing in all possible places. Definitely, there are many places where it can be extremely useful and people can benefit from that. But not all the places.

Avanscoperta: So what are those places? Where is event sourcing a game changer?

Oskar: We’re talking about places where we have business workflows that are maybe a bit more complex than two or three steps, or workflows that are just important from the business perspective. This extended tracing where you’re not losing any information is super helpful.
I think that in general I don't see a domain where it couldn't work but definitely those that are related more to processing workflows etc - they are definitely useful.

Most of the time we say that financial domains are really great for event sourcing because event sourcing works as accounting.
I even heard the joke that Hammurabi invented event sourcing when he invented the first accounting stuff.

Avanscoperta: It sounds like a DDD Borat joke.

Oskar: That could be… I don’t remember who said this, maybe Greg Young… but it might have been DDD Borat too.
Definitely financial domain is an obvious choice, but I wouldn't just lock in event sourcing in that type of domain.

I see it working in many medical projects because it works well when you need to have this strict audit log and, in general, when you have areas of your system that can benefit from getting more insights from your data, and business workflows.
It always works well when you have engineers and a business logic that looks like a state machine. These are the places where event sourcing is a really good candidate.

Avanscoperta: What are the biggest factors of resistance when folks want to start using it, or introducing it in their company?
One is to do it for your project or within your small team, but we talked about finance or medical, and you know, of course, we are not probably talking about the whole hospital or what's not, but definitely a few departments.
So why is it difficult, if it is difficult at all?

Oskar: There are multiple factors. As Gerald Weinberg said, “Mostly it's a people's problem”, as everything.

Of course, I don't want to say that people intentionally don't want to use event sourcing, that's not how it goes. But as I mentioned it is a niche. So many people just prefer to choose the boring tech stack, which is a good decision in general, to just stick with your favourite tooling. On the other hand, too often that's also a limitation because you might not benefit as much as you could from it
And the knowledge about event sourcing is not spread enough, so there are not enough people uh teaching about event sourcing and writing about it.
It's changing, right now we have much more than when I was starting but it's still a matter of lack of good resources, but it's getting better.

The other factor is that event sourcing for many years was pictured wrongly.

Instead of focusing on streamlining workflows, representing your business workflow in code, registering all your facts and making decisions… for many years it was somehow conflated with stuff like messaging and Domain-Driven Design, and I think for many years it was shown like the highest level of enlightenment, which is kind of a joke, such as, “First you need to learn everything about DDD, then everything about distributed systems”, etc.

And because when people were looking at the resources about event sourcing, they thought, “Okay, that's really cool, but I won't ever be that smart, or I won't ever have such a big project to work with event sourcing”, I think that's a false narrative because event sourcing can be really accessible.

Event sourcing brings a lot of fun and makes many things even simpler but we need to approach it with an open head which means that we need to unlearn some stuff and some past ways that we were doing. If we don't do that, then try to apply each of those past techniques won’t necessarily work well with event sourcing.

For the person who is seeing event sourcing for the first time, getting all this buzz, and understanding its potential, it's hard to filter out what you don't need at the beginning, when to apply specific techniques, etc.

That's also why I'm doing this workshop, I want to show a simpler and more pragmatic way to share and use the knowledge about event sourcing.
You can also learn things as you go, starting simple and then adding stuff from DDD and from distributed systems where and when you need it.

Avanscoperta: What is the pain point we are aiming to solve with your workshop? Why should folks come along?

Oskar: The pain point business-wise is observability, easier debugging, easier testing, and understanding complex systems. Event sourcing can help in that.

So who should join? I think “everyone”, but that’s a bad answer.
Definitely, folks that are starting or started their way in event sourcing. If they want to get started, if they’re doing it already, if they want to make sure they’re not missing anything and they’re on the right track, or they want to learn more about tools like Event Store DB, Marten, Emmet, then that's a great way to do it.

This also appeals to new people, because in the current shape of our IT industry, you need to somehow have knowledge that is an outlier to the other people, and in my opinion event sourcing can be such thing, because even though it is a niche, it's growing and boiling underneath the surface.
Knowing this event sourcing pattern, even if you currently are not using it in your project, can also be an important aspect and eye-opener. Also, I will be touching stuff like CQRS, vertical slices, event-driven architecture, and business workflows.

There is also an overlap with the traditional way of building applications.
If someone is interested in this area, then that can be also a good way.
For those who know me and are curious about how I do things, this workshop is the outcome of my personal journey.
But it won't be only biased because I will show different ways and different flavours of how you can do stuff.

Avanscoperta: As we close for today, I also wanted to briefly touch on your career, if we can call it such, as a writer. I’ve noticed your consistency, and that's really cool. How does that work? What keeps you motivated? When did you start, and what feedback have you been receiving?

Oskar: I’ve always liked to write. I don't know why but I always like to write. I like to do creative stuff, and that’s also why probably I like coding.

I started blogging quite a long time ago, probably 12 years ago, and I was writing my Polish blog, but at the beginning and for the majority of my, as you said, “blogging career”, I wasn't that consistent. I was just blogging once or twice per year, but what helped me is that instead of thinking about what great stuff I could write and what great stuff I could provide some information about, I inverted my thinking about blogging.
So I said, "Okay, so this is Friday, and I would like to write something every week." So let's say that I have six hours right now on Friday, and instead of trying to build a really great, huge article, I started to think about what useful things I could write about within that time.

Instead of trying to invent something, I started to search for what questions I answered and what interesting stuff I did, and it doesn't have to be something extremely innovative or totally brand new.
If someone asks you how you do a certain thing and you manage to help that person, then there's a high chance that there are more people like this one who can also benefit from it. Even if someone else wrote about it and showed a better way, then this is your way.
If someone would like to start writing, then just write for yourself. I'm writing because I forget things, so really you never know.

I wrote some articles that I thought were some of my best ones, actually not many people read them.
Some that I just created within two hours where those that are most read.

You never know, you won't ever guess who will be reading it. But if we build this consistency, maybe it doesn't have to be every week, maybe every other week, every month… but for me, this inversion helped me and in the meantime, I also started to do this - when I'm discussing with someone in some chat and I help them, then writing what we discussed about somewhere in a private GitHub orin a Notion page, or somewhere else… then if you gather many similar answers like that, then it can be already a good starting point for a blog article.
That would be my advice.

Avanscoperta: Basically it's a matter of documenting what you've been already doing, rather than reinventing the wheel or trying to come up with a shiny new incredible thing every time.

Oskar: Indeed. I noticed that many people are struggling with this, and I was also struggling because I had this idea that I think it's great, but then when I sit in front of the computer, I realize that I won't ever make it today.

Plus, the good thing is that at the beginning, no one will read what someone just started writing. And that's a great chance to make mistakes and write something wrongly.
You can always amend it and change it.

Check out Small Talk on YouTube or Spotify.

Credits: Picture by Christian Holzinger on Unsplash.

Learn with Oskar Dudycz

Oskar is the trainer of the Practical Event Sourcing Workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

This blog post is the transcription of the chat we had with Bruno Boucard and Kenny Baas-Schwegler about their Deep Dive into Model-Driven Design on 16 February 2024.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: I would like to ask you to introduce the workshop. So what are we talking about? What is it for?

Kenny: Let’s introduce ourselves first. I’m Kenny, a software developer, software architect, and independent consultant.
My expertise is in Domain-Driven Design and Team Topologies, and my goal is to enable teams to develop software, design software, and run that software as independently as needed. We're going to deep-dive into the second-part design because that's the bit that a lot of teams and organizations are still missing.
And this is, namely, “How can teams independently design with their stakeholders?”

Bruno: I'm Bruno. I have more than 20 years of experience in IT. And I would like to explain how I discovered Domain-Driven Design.
It was 10 years ago. I met Alberto, Eric, and Matthias at the Build Stuff stuff conference. It was for me a great moment. I felt like crossing the world, like an episode of Black Mirror. And since this period, I've not yet returned to my original world.
So I think it's important to say some words about how I discovered the Blue Book. It was a very strange experience for the first time. I started reading the Blue Book, and I was very surprised by the literacy style of the book more than by its complexity.
And I returned to it several times. And finally, I began to understand the finest of Eric's words. And I fell in love with the third part of the blue book, the reason why I'm here. That's the motivation behind wanting to do this workshop.

Kenny: And now back to the original question, “What is this workshop about?”
It's about part three of Eric Evans’ Blue Book. And what we see, well, at least what I see and observe in the Domain-Driven Design community, is that people get the problem. But what problem?

It all started with me as well 12 years ago, writing software with anemic domain models, thinking about surface object patterns, and then a domain model that maps with object relationships, right? Okay, that's not how you want to do it.

So I started using Domain-Driven Design, got my aggregate out, and got my rich domain model out. I thought that it was okay, but if I had read the book correctly, it wouldn't have felt like the promise of DDD was being fulfilled.

And this is where I see the industry move now as well. A lot of people focus on strategic design, which is perfect, as we need that. But we're missing the depths of tactical design because most people we encountered using Domain-Driven Design talk about aggregates and value objects, which is a good head start…

But the problem is that there's still a disconnect from a situation like, “Okay, we modeled and designed it together with the stakeholders, and now software developers are starting to build software.”

I think it's even in chapter two of Eric Evans’ book, where he says, “There's a disconnect then between the code and the model,” and that's because developers are left to implement it by themselves.
So we need that deeper connection with stakeholders, with domain experts as he calls them, which is what we're going to do in this workshop, go deeper into Model-Driven Design, which also means that we can also design and model through coding.

We're going to spend more time in the code, going back to our modelling space, and realize that aggregates are indeed a first start but we need to go deeper. It might not even be the best start. You might not even use aggregate, right? It's just the tactical patterns, but that depth, which is called deep modeling, that's what we see is lacking.

And because we're lacking that, in most organizations I see Domain-Driven Design doesn't live up to its promise of making software more adaptable to users' needs, making that deeper connection, because usually we stop there.

We're going to go through the whirpool once, we got our domain model and never improve it, never adapt it, never change it. And I think that will be what this workshop is about, and where the problem is.

Bruno: I totally agree with what Kenny says, and I’d like to add something. Deep-modelling is an approach; it’s not a tool. It's a way to organize how you deep-dive and how you discuss and think about the complexity of the domain of your business roles.

Generally, people love solutions because things like aggregates, value objects, and entities are easy to understand. However, it's very useful to protect your modeling. But inside your aggregate, you have to deep-dive into your modeling, and that’s the problem of the developer because honestly, part three of the book is not so easy to understand for a new developer. I think that's the problem.

Kenny: You need to have experienced it. You need to have worked on a domain for at least six months, better even a year. Also we're focusing on Java and C# at this moment.

Bruno: It’s important to have experienced this situation, to be hands-on and ready to have a good way to discuss with the domain experts, and apply what Eric said, which is make a prototype, discuss that and make refinements.

And Eric talks about refactoring, indeed the title of the third part is Refactoring toward deep insight. But this refactoring is not exactly the refactoring defined by Martin Fowler. It's another way to make a refactoring. It's a refactoring like carving the wood. It means that each time you see something, you see the world is not exactly aligned with the domain, you have to change a little. Or maybe sometimes you do a refactoring like Martin Fowler does.

Kenny: I like this point, Bruno. Because the code is not the model. The code is like a reflection of the domain model. So if you go into code and you see this nice folder called “domain model”, you might hope that it represents the domain model, but it is not in fact THE domain model.

That's why we use supple design in order to make sure that the code in there is adaptable to the domain model, because the domain model in this case is an abstraction.

The domain model is the conversation we're having with our stakeholders, with our domain expert. It is the understanding of our domain represented in a form, which is kind of abstract, but that's what we're going to experience during this workshop.

But again, we're looking at how fast we can go to code in changing that model. And that's the refactoring the domain model, which of course, if you refactor the domain model, you need to refactor your code.

Now, if you refactor your code, you also need to refactor your domain model. It goes both ways to refactoring. And that's what Eric says, “Refactoring doesn't mean the code”... well, it does mean the code. But if you refactor the code, you must refactor your domain model and the collaboration you have with your stakeholders.

That's a good point about Model-Driven Design. We don't want to confuse it with Model-Driven Development, which is also a technique.
We are being explicit that we’re talking about the Model-Driven Design as described in the original Domain-Driven Design book by Eric Evans.
Eric's being exact in that it's about collaboration, about continuously changing the model to a deeper insight.
And we only do this, of course, where it really matters. “Tackling complexity in the heart of software”, right?
We won't do this for a very complicated or simplistic challenge or domain challenge. We do this only when people are working on complex problems.

Bruno: When you have something very complex, you need several steps to understand.

The first step is quite blurred, then the next step is quite clear. And the third is clear. It's because in your mind you have a mental model growing and you get something new, but it takes time. It takes time to do discussions, conversations and coding to be sure to be aligned.

Kenny: As an example, in one of my previous clients, we had a very complicated domain. It wasn't complex, but it was very complicated. We had deep conversations with several domain experts, at least three different types.
We went over three months of iteration, continuously updating the model, then the code, and then again the model and the code.
And everyone, especially the domain experts and product owners, were saying “Why is it taking so long?”, even getting a bit upset. And then you have that breakthrough come to a very simple, clean model.
Then after three months of development, we caught up. Every new feature that was brought in was built in within minutes or hours. It was very fast.

And that understanding, that intrinsic understanding, that's what we're going through in this workshop.
We start with a naive model and we'll give you a naive model to work with. You're going to code a bit on it and then we're going to give you a whole new feature. That's what happens in real life.
“We designed, we modelled, we took into account what we know. It's complex, we don't know the future.” And while you're working on the first model, the product owner comes in and says, “You know what? We might be able to do this”, and then you think, “Oh, but that's not how we accommodated the model for.”

And from there, we're going to start the Model-Driven Design, see how we can make the code supple in order to accommodate these new features and how we can refactor to a deeper model.
This is the kind of process we're going to follow and that makes this different from your normal tactical Domain-Driven Design workshop where you go into aggregates.
So you need to have a base understanding of aggregates and objects as well, and how they're represented in the code, because we're gonna go deeper to it.

Avanscoperta: So what is Model-Driven Design?

Bruno: Model-Driven Design is a connection of two things—deep modeling and supple design. But as a definition, it's not enough because it's an approach. As Kenny said, we practice supple design, which is a way to to apply your ubiquitous language in your code, apply autonomy of your classes, to continue to refactor with ease.

My point is, Model-Driven Design is not a chapter in the Blue Book, which is a shame. It is a pattern in the book, but it’s not well-named and defined.
It is explained in every chapter in the part three, where you have some mention of a Model-Driven Design. There is something more in the Orange book, but not in the blue one.
All part three of the Blue Book is dedicated to Model-Driven Design. And since it’s not so explicit, plenty of developers miss the definition and don't understand clearly what's the aim of part three. This workshop aims to fix this.

Avanscoperta: Do we need people to have read Eric Evans' book or even just the part three of the book to join the workshop?

Kenny: No, because you're going to experience this ongoing dialogue between domain experts and practitioners in the workshop.

I want to emphasise this as we don’t usually see this ongoing conversation happening. This means that this conversation will also carry on as we work through the code.
I usually don’t see it happen in our industry. We stop from a design session, we stop and then the developers go back to their working station and gonna work with each other to make pretty aggregates and value objects… but there’s never an ongoing collaboration with stakeholders. This is what our workshop is about.

Avanscoperta: We've seen this in many other workshops—it's all about collaboration… but then what happens when it stops? You find yourself in a lost-in-translation kind of scenario and this does not help.

Kenny: I want to emphasise the why of the workshop as well…

The code moves away from the domain model when developers go to code and stop the collaboration with other stakeholders because you did a lot of collaboration, there's a domain model, there's a shared understanding and domain model, then you go through code and there's so much in code, which is what Eric talks about - the breakthroughs and the deeper understanding.

That’s why big up-front design does not work—because in the code, you get new insights that you need to bring back to the domain model… and all of this bringing back from the code to the domain model is the actual focus of this workshop—making sure that code stays more aligned to the domain model.

If you don't do that, it's going to get in your way because you're constantly progressing. Every change, every new feature, will be harder to implement because you need to translate again, and that translation is what we try to actually solve with Domain-Driven Design in the ubiquitous language.
But we're not aware that we're moving away from the domain model in our code. That's the pain point we're aiming to solve, right?

“I did Domain-Driven Design, I did all this design with the stakeholders, now I'm coding. Two months later this new feature comes in and I don't understand anymore because there's just these nouns in my code right and I don't know what they're talking about specifically and it's different and I need to translate it…”

That's the pain point and that's why a lot of people think, “Well, there's so much work going into creating aggregates and value objects and it doesn't work because two months after we're using it I'm still making these translations.”
Yes, that’s because because we're not continuously refactoring.

Bruno: On the developer side, we need a specific behavior, self-determination, and engagement because it's not a lazy position.
You can’t do deep modeling if you are lazy; you need to be engaged and think about it. Then, as Eric says, you need to sleep on it. It means you have a short meeting. We do sessions with a domain expert to understand deeply. And sometimes you need several days to think about, and this is also very important. You cannot do any of this if you’re not engaged and you don’t care.

You also need to exercise the ubiquitous language all the time because it helps a lot in the way you think.

Avanscoperta: And now some questions from the chat, here’s Anthony’s: “Can you outline some heuristics that can allow us to build a model and code that represents that model to be pilable and allow for changes? “

Bruno: This question is more about supple design. Actually, supple design is the answer to continuously refactoring.
Supple design is a collection of patterns for your code to obtain something very supple and change your mind without breaking your design.

Kenny: And if you want a very concrete heuristic, Test-Driven Development is the answer. If you do that together with supper design, it works. A big part of this workshop is using Test-Driven Development. We use our clear scenarios from our modeling, a Test-Driven way, but not the normal way.

We have a design. We already have design. So we're not doing dogmatic Test-Driven Development. We're doing it from the rich model that we get.
And from there, the heuristic is, “Don't use a new feature in Test-Driven Development inside your current domain. Use it in a test. So don't use your current code and your current domain model in your code while introducing new tests. Just use it from where you're starting with a test.”

And this is what we're gonna do in the workshop as well. We're gonna start from our tests and then integrate them in our domain model or find out that our domain model isn't optimized for this, so maybe we need to change it.
And again, what Bruno said, if you use proper supple design patterns, then it would be relatively easy, right?

Bruno: I would like to add that we’re talking about TDD outside-in, and not only test. We’re talking about acceptance tests, not unit tests.

Avanscoperta: Let’s jump to the next question by Federico. “Refactoring a model in an event sourcing system can be tough due to the immutability nature of the stored events. What do you think? Are you going to tackle the event sourcing even in the workshop?”

Bruno: No, because event sourcing is a specific pattern for a specific use case. We can use deep modeling for it, absolutely, but we don't want to deep dive in a specific pattern.
But to answer, if you have some invariant in your aggregate with some complexity, you have to use deep modeling effectively, even if you practice event sourcing.
Supple design is based on capability to be immutable. You should avoid side effects. We apply a pattern called closure of operation, it's a mathematical pattern to return back a type and avoid a mutation. Supple design is dedicated to autonomy and immutability.

Kenny: We don't tackle event sourcing, but it's the same as Eric says. “Domain modelling is separated from your technology.”
We're going to use object orienting, but there are great books, like the one by Scott Wlaschin on functional programming, doing the same. That doesn't really impact the deep modeling. Of course, it impacts the technology. We're using object-oriented methods because most of the world still uses them. But from my experience, actually using event sourcing should make this simpler.

I'm very curious as to why this can be tough due to the immutability nature of the stored event. But yeah, that's not what this workshop would be about.
That in itself is already for me a flag because that means now that you're using event sourcing it's not supple anymore because your modelling code is not easily adjustable. So now a domain expert comes in and says, “Well, we need to go this way”, and then you're like, “Well you know, I use event sourcing”.

I don't think event sourcing is the problem here, it should make it even easier than object-oriented and functional (well I'm not sure about functional programming…), it makes it easier to change your modelling code. So for me for me that’s a very interesting question that I need to understand a bit deeper.
Event sourcing should enable deeper modelling better and more supple.

Avanscoperta: We have another question from our chat. “What tools are you using for your modelling?”

Kenny: We’re aiming at Java and C# developers, but you don't need a deep understanding of C# or Java. We're almost not using any framework, we're only using a unit testing framework.
The rest is just plain old C# or Java code, so Pojo and Poco inside the code. For modeling, we're gonna use Miro in this case, we're not doing a lot of whiteboard modelling, but most we'll be focusing on the code.

Sometimes we go back to the whiteboard modeling to update our domain model, but I think those two tools is what we're mainly gonna use. So you need your favorite IDE, able and capable of running, and Java and/or C# in their latest versions.

Bruno: We should split people in small groups. It means we work together, and if you don't know the language very well, you should be pairing with other folks who might know better, so it should not be a problem for you.

Kenny: We're not gonna focus on the programming language. We're really gonna focus on the modelling aspect inside the code.

Avanscoperta: Time to show a picture that Bruno prepared for the workshop. I know Bruno prepared a very nice picture for this workshop. We spoke about the whirlpool, which we all know about when it comes to Eric's book, but we also have our whirlpool.
Would you say something about this?

Bruno: There is already a picture by Eric Evans about refactoring deeper toward a different insight.
And we thought it was good to create something ourselves.

The first reason is to design our commitment to this workshop.

The second reason is to make the original diagram more human, because if you see the whirlpool process model exploration by Eric is a collection of arrows, but there are no people around. We wanted to illustrate a team and of a conversation with the domain expert, and we also wanted to keep the spirit of the original one, this was the goal.

The third reason is to find a way to embrace all of part three of the Blue Book. It's the reason why you notice on the right, there is a cloud with a storm, and it stands for the breakthrough.

Kenny: The main reason for it being a cloud is because if you've gone through this deeper modelling it can be frustrating from time to time. It can be conflictuous, right?
I always see conflicts popping up, frustration popping up, folks asking, “Why does it take so long to get it right?” And all of a sudden there's a flash and… here’s the breakthrough.

That's why we added that breakthrough in the middle of the team working with their domain experts. Again, we're focusing very much on that collaboration with domain experts even while we're doing code probing.

Bruno: We discussed this with Kenny and as I am a drawer I did a prototype on a notebook. And Kenny said, “Wow, it's correct, but I see something else”, and so on. I then moved to do this on a tablet, as it was easier to communicate. And we wanted to include a conversation. And even here, we iterated a lot to find a good idea to illustrate what the workshop is about, which is, mainly, “We started from nothing. And we're growing the idea. We have a new mental model at the end, and we obtain this feature.”
It's not a survey path, but it illustrates the workshop.

Avanscoperta: Before we finish today, I have two more questions from the chat. Victoria says, “I absolutely love the continuous refactoring approach, but sometimes you have devs who are absolutely terrified of changing anything about the system.”

Kenny: What I usually see is a disconnect, and that’s what Eric talks about a lot, right?
A disconnect with the underlying model. So the code has a disconnect with the underlying model.
And yes, I would be terrified of changing something in a system that I don't understand what will do on the business side, on the domain side.
There's no alignment anymore, and a lot going on… A lot of arrows and wires going to the business.

“So I need to cut the green, the blue or the red wire now? And what does that happen in the business?” That's what we're trying to solve here with Model-Driven Design, which is to keep that intrinsic knowledge of how things work because I know I understand perfectly how this will change my business.
That's why a lot of people are terrified of changing anything about the system because the domain model and the words in the code don't respond to each other.
So if someone is saying, “Kenny, can you change the A, B, C?”, I look at the code and I don't see the A, B, C,  and I'm like, “Okay, what is this, and what do I change?” And it doesn't match anymore… And I would be terrified…  

I’ve worked in an asset management domain. I was terrified the first month I came in and someone said, “Can you please change this interaction of 2.5 millions?”, and I was petrified. Then someone showed me and I'm like, “Oh, what this person says actually matched my code. Oh, now I feel much more comfortable of changing that code”.

That's what we're trying to tackle, that fear of knowing exactly how this small change impacts my product and my business. And understanding that if I decide to change a certain thing, that can be a high risk change. So let's start collaborating more again with my stakeholders.
I actually witnessed this—a user went into my code and said, "Kenny, this piece of code, this piece of code is wrong. The calculation is wrong, it should be different", and this person was no coder.
And that was nice. This was an economical domain. So it's not totally fair because they could read my calculation in the code a bit because that matches, but the point is that the code surrounding my calculations and the naming surrounding it all made sense to this person who was no coder.
So I could easily change that, push a button, go to production, and fix it. And that's the power, that's why I wasn't terrified of changing the system anymore because I understood exactly what the business was and what the impact of my code was on the business.

Bruno: When we do deep modeling, we suppose we are in a core team and it means we create something new and we are protected by the bounded context.

But if we started in a legacy system, I would prefer to use a bubble pattern, a bubble context, to protect me and to start with a clear and integrity core, not in the pure legacy system, which is very, very difficult and dangerous.

Avanscoperta: One of the pain points we're aiming to solve here is also avoid being so scared and making sure code and business requirements are aligned from start to finish.
Last question, this time from Wouter: “Is there a curve of change frequency? Do the number of larger changes to the domain info get less over time?”

Kenny: It's a very good question. Of course, it depends on your domain, but from my experience, going through a couple of these iterations, like the one I did previously… doing that for a complex domain takes time, like three months, but after three months, the number of large changes went down. All the changes were done in one or two days and it was even so much.

And this was interesting that I came to work one day and I asked, “How is this new change going?”, and they said, “Well, yeah, it's on hold”. I asked why, and they said that the business wasn’t ready for this change. “We went too fast.”
To which I replied, “Okay, we have another problem, but it's a better problem this time, right?”

It depends on the complexity of the domain. It depends on the market you're in. That can highly affect it. But overall, if you do this, and again, I would like to state that you don't do this for more supporting domains, as we call them in Domain-Driven Design because the investment is not worth it, right? You really do this deep modelling more for complex core domains.
And then yes, it's well worth it. The number of large changes to the domain gets less over time, except, of course, when you have stuff like COVID or major things that can screw it up big time.

Bruno: I would like to add that the engagement is fundamental. The more you are engaged, the more it's easier for you to understand everything and make sure everything is precise. And your capability to change some part of your system and of your code become very easy if you apply supple design.
So, effectively at the beginning, you can change a lot of things. If the model is not correct or too naive, for example, but the more you dig inside the model, the more your brain understands everything deeply.
That's the consequence of your engagement.

Kenny: And to finish that one off, I'm again going to stress it—you do it only for core domains. Else we're going to end up with this whole aggregate debate where everyone's using aggregates everywhere.
No, you do it for this particular reason. This is not the silver bullet that we're talking about. We're using it for core domains, for complexity, and there it has a definite payback over time.

Avanscoperta: I would finish off with some suggestions. Is there anything we can recommend to our learners online that they can watch or read?

Kenny: We did a talk at KanDDDinsky 2023, which gives a quick and short overview of what we’re gonna do.

And Bruno and I will work on a blog post to go a bit more in depth on this over the next coming months.

Also, if you need to get started on this very topic, it's either with part three of the Blue Book or watch our video if you want to take less time. Also Nick Tune’s work is amazing, check it out.

Check out Small Talk on YouTube or Spotify.

Credits: Picture by Adrian Cuj on Unsplash

Learn with Bruno Boucard and Kenny Baas-Schwegler

Bruno and Kenny are the trainers of the Deep Dive into Model-Driven Design Workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

Storia di unconference all'italiana su Domain-Driven Design

La sesta edizione di DDD Open Space si è tenuta il 4 - 5 febbraio 2025 a Verona, dopo una prima edizione in presenza nel 2024 e ben quattro edizioni da remoto negli anni precedenti.

La non-conferenza su DDD in Italia

Abbiamo organizzato DDD Open Space per riunire nello stesso luogo tutte le persone che in Italia si interessano a Domain-Driven Design. Che si tratti di persone altamente esperte o persone che si stanno interfacciando ora con questo vasto argomento e hanno voglia di confrontarsi.

Anche per il 2025 abbiamo confermato la formula dell'Open Space Technology per l'evento. Abbiamo quindi progettato uno spazio di esplorazione collettiva, creativa e partecipativa sul tema centrale del Domain-Driven Design, capovolgendo l’approccio tradizionale relatore-pubblico.

Organizzare e fare un Open Space significa creare uno spazio di discussione, in cui i partecipanti sono liberi di muoversi scegliendo, in completa autonomia,
quando e come contribuire alle discussioni.
Condizione fondamentale e necessaria per il successo di un Open Space è il reale interesse delle persone per il tema. Interesse che porta le persone a impegnarsi ed essere parte attiva, sia nel contribuire sia nel partecipare alle discussioni.

Il risultato dell'Open Space di febbraio è stato un fitto programma co-creato ciascuna mattina dell'evento e un gran movimento tra le persone.

Un movimento che abbiamo innescato sin dai primi minuti, con un'attività di connessione e attivazione, perché sappiamo quanto sia importante stare nel qui e nell'ora, lasciando fuori i pensieri e disporsi al meglio per imparare e contribuire.

Ed ecco allora spuntare un sacco pieno zeppo di LEGO che Ivano Masiero, il facilitatore che abbiamo coinvolto per questo evento, ha portato con sé per dar vita all'attività di connessione del giorno 1.

Prompt di questa attività: scegli un pezzetto LEGO che rappresenti lo spirito con il quale arrivi in questa giornata. Racconta a quante più persone possibili perché hai scelto quel pezzetto, nel tempo di una canzone.

Abbiamo così rotto il ghiaccio e facilitato la possibilità che persone che non si conoscevano potessero farlo.

Market Place

Alle 9.30 è iniziata la fase importante di popolamento del Market Place dopo una breve introduzione.

Tra giorno 1 e giorno 2 sono state proposte 45 sessioni, di cui due Ask Me Anything, due sessioni di modellazione su domini reali, molte sessioni di confronto e qualche sessione hands-on, con codice alla mano.

In particolare, nelle proposte del Market Place, sono emersi:

🔹 Storie di casi reali
🔸 Design patterns
🔹 Concetti e strategie.

Sessioni - Giorno 1

• Big Map of DDD - Alberto Brandolini
• Salvare gli Aggregati - Luca Giovenzana
• Giochiamo all'orchestrator - Alessandro Colla e Alberto Acerbis
• Vendetemi DDD - Luigi Cardamone
• Chaos in DDD - Strategie e Best practices - Antonio Liccardi
• DDD e Debito tecnico - Daniele Agosti
• La torre di Babele - Ubiquitous Language - Mauro Ghiani
• Rappresentazione nel Dominio 1 di un concetto gestito da un Dominio 2 - Flavio Camillo
• Context Mapping - Alberto Brandolini
• Team Topologies - Bounding and Mapping Team Contexts - Sebastiàn Magrì
• Ask Me Anything - Alessandro Colla e Alberto Acerbis
• DDD Clean Architecture - Piergiorgio Vagnozzi
• Application Service Pattern - Walter Nuccio
• Osservabilità dei domini: come farla - Antonio Liccardi
• Come l'introduzione di un comportamento possa stravolgere un modello di dominio - Flavio Camillo
• Layers nello spazio socio-tecnico - Alberto Brandolini
• DDD with Python: Build Django, modular monolith - Davide Ria e Michele Matera
• E se chiedessimo a Platone o a Eraclito? - Alessandro Colla e Alberto Acerbis
• Abbiamo cominciato, abbiamo litigato, vediamo la tempesta: confrontiamoci! - Massimiliano Cantoni
• Comunicazione tra microservizi: quando, come e perché - Nome Host

Sessioni - Giorno 2

• Microservices Sucks - Gianluca Padovani
• Object Calisthenics: 10 regole per rendere forte, che esprima il dominio - Marco Consolaro
• A scuola di aggregati - Luigi Cardamone e Simone Dorati
• Un CQRS per domare tutti i domini - Piergiorgio Vagnozzi
• Teaching DDD: collect info and methods to teach DDD - Alberto Barillà e Gianluca Padovani
• Debito Tecnico: un possibile punto di vista - Martino Vallara
• EventStorming Showcase (Software Format) - Alberto Brandolini
• Rust can DDDo it! - Sebastiàn Magrì
• Event Modelling: c'è qualcosa di buono? - Giovanni Messina e Gianni Bortolo Bossini
• Servizi di dominio che hanno bisogno di attingere a dati provenienti da altri contesti - Flavio Camillo
• DDD: c'è qualcosa di nuovo? - Daniele Agosti e Pietro Roversi
• Event versioning - Alessandro Colla
• Domain Model: codice vs configurazione - Pietro Martinelli
• CQRS/ES: un piccolo piccolo esempio reale di successo - Eduardo Silvi
• Modelling Clinique: un problema da risolvere insieme - Alberto Brandolini
• Collaborative modeling: From EventStorming to BDD - Sebastiàn Magrì - Walter Nuccio
• DDD no Frills - Luca Giovenzana e Gabriele Toselli
• Orchestrator che fallisce - Alessandro Colla e Alberto Acerbis
• Event Sourcing vs CRUD - Giulio Cesare Solaroli
• Ho messo l'anti-corruption: e ora? - Salvatore Caputi
• Ask Me Anything - Alessandro Colla e Alberto Acerbis
• Job asincroni: quando sono degni di un contesto - Host Name
• Quando i bambini fanno OOO: ovvero come l'ontologia orientata agli oggetti spiega il perché gli oggetti sono difficili da "modellare" - Luca Guadagnini
• Domain Expert vs Effective Model - Giulio Cesare Solaroli
• DDDesign per analisi preliminare della progettualità e nuovi prodotti: Alberto Picco

Feedback e testimonianze dai partecipanti

Una piccola raccolta di post in giro per la rete delle persone che hanno partecipato.

𝗟𝗮 𝗽𝗿𝗶𝗺𝗮 𝘂𝗻𝗰𝗼𝗻𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗻𝗼𝗻 𝘀𝗶 𝘀𝗰𝗼𝗿𝗱𝗮 𝗺𝗮𝗶! ❤️
La scorsa settimana ho partecipato #DDDOpen Space a Verona, un evento organizzato magistralmente da #Avanscoperta. Sono rimasto davvero sorpreso: questo formato di conferenza è stato una vera scoperta per me. Ne avevo sentito parlare molto bene, ma non avevo mai avuto l'occasione di parteciparvi prima.
La motivazione per cui mi ha colpito particolarmente è perché promuove discussioni autentiche e stimolanti. È un ambiente in cui tutti possono partecipare, che tu sia un novizio su un tema o un esperto pronto a confrontarti con altri. E in aggiunta, si possono conoscere tante nuove persone.
Antonio Liccardi

The DDD Open Space was my first experience with this format.
I have to say that I was hesitant. Attending an event where you don't know what will be discussed is not easy to justify, even to yourself.
After spending two days in Verona, I can't wait for the next edition: I don't think there are many opportunities to participate in so many conversations about real cases and share ideas with so many skilled people about the DDD 💪
Luca Agostini

As far as I remember, this is the fourth year in a row in which I took part in DDD Open community but why does it matter to me and other developers, solution architects and front-enders?
The un-conference meeting organized by the incredible team of Avanscoperta is the perfect chance to get a deep insight into what #domaindrivendesign is by knowing from people who applied it at work. Since it's an un-conference, there's no planned agenda and no call for talks, everyone at the beginning of the meeting may propose anything about DDD, technical stuff, new domain-driven concepts and even questions and doubts. So don't miss the chance the next year! Join the ride! 🚴
Luca Guadagnini

Guarda le foto dell'evento.

Conclusioni

Organizzare un Open Space non è banale. Ci sono almeno due fattori di criticità non da poco: trovare una venue adatta, con una molteplicità di spazi che possano essere usati per le varie sessioni, che siano adattabili a diverse esigenze, che siano informali e accoglienti, ma dotati delle giuste attrezzature; far innescare conversazioni di spessore tra persone che non si conoscono e su temi particolarmente complessi.

E poi ci sono le aspettative con le quali ogni persona arriva. Chi partecipa a un evento (magari investendo il proprio budget di formazione annuale) lo fa con l'aspettativa di rientrare in ufficio arricchita da questa esperienza, sia a livello umano sia a livello contenutistico.

Quello che facciamo è curare al meglio lo spazio, molto prima dell'evento, durante le due giornate, durante la sera, e durante le sessioni. Ci mettiamo una buona dose di esperienze maturate negli anni in tanti eventi organizzati, ci mettiamo la cura, la creatività, raccogliamo i feedback perché possano essere un modo per fare meglio. Ma accettiamo anche che non tutto è sotto il nostro controllo e che la forza di un Open Space sta anche in questo. Nel lasciare che ciò che deve succedere, succeda.

Ringraziamo tutte le persone che hanno preso parte a DDD Open Space 2025. Ringraziamo Alberto Brandolini, Alberto Acerbis, Ferdinando Santacroce, Alessandro Colla per essere gli ispiratori di questo evento.
Ringraziamo Ivano Masiero per averci accompagnato e facilitato anche quest'anno.

Prossimi appuntamenti e segnalazioni

Se ti interessa seguire le conversazioni della community DDD Open, ti segnaliamo questi canali:

• Linkedin
• Youtube
• Slack

Il prossimo evento sarà disponibile sul sito DDD Open.

Libro su Domain-Driven Design in italiano

Ti segnaliamo il libro Cronache di Domain-Driven Design, scritto da Alberto Acerbis, Matteo Baglini, Uberto Barbini, Alberto Brandolini, Alessandro Colla, Marco Consolaro, Emanuele DelBono, Gianluca Padovani, Francesco Strazzullo, disponibile su Leanpub in versione digitale e Amazon in versione cartacea.

Restiamo in contatto :)

Vuoi continuare a leggere le cose che pubblichiamo?
Iscriviti alla nostra Newsletter 📩.
Ti faremo compagnia ogni venerdì mattina. ☕️

This blog post is the transcription of the chat we had with Bjarte Bogsnes about his Beyond Budgeting Master Class on 6 November 2024.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Let’s start from the basics: Beyond Budgeting, what is it?

Bjarte: Well, first of all, it is a somewhat misleading name because this is about so much more than budgets.

It is about challenging traditional management and leadership, and we will argue based on two main assumptions:

1) you can't trust people,

2) the future is predictable.

None of the two are true and that is what we are challenging.

So beyond budgeting is a management model that has a positive view on people and employees, and also offers much more adaptive, or agile, or whatever you want to call it, ways of leading and managing.

We've had long discussions internally, like, “Should we change this name a lot?” We know it's misleading, but it has become a brand, and it has one benefit: It provokes people. And if we can use that attention to explain what this really is about, then the name might have served its purpose.

But of course there is also a link to budgets, because, at the core of the traditional way of managing, you find the budgeting process and the budgeting mindset.
It's impossible to change management and leadership without also addressing the budgeting process. It's necessary but not sufficient.

Avanscoperta: Now I'm curious to know more about how the name beyond budgeting came about and who came up with it. I guess you referred to a group of people or was it you in the first place?

Bjarte: No, it was not me in the first place. It was actually two English authors and researchers, Jeremy Hope and Robin Fraser. Back in the mid-90s, they discovered that some companies out there, mainly in Europe, had done interesting things around their leadership and management model, including budgeting and kicking out the traditional budget.

One of these companies was a Swedish bank, which I will discuss extensively in the masterclass, called Handelsbanken. And another company was Borealis, which was Europe's largest petrochemical company at the time. And I was heading up the finance function in this company.

Through some coincidences, we got the chance to kick out the budget in that company in 1995. And it worked wonderfully. Cost, for instance, came down. Back then, there was nothing called Beyond Budgeting, so it was a bit risky, but it worked wonderful.

And then, I think the year after, I saw a small advertisement in a UK magazine that these two guys were looking for companies that had done stuff in this area.
So I called the UK number and got in touch with Jeremy. They came over to Copenhagen, and we met. We've been friends ever since. Unfortunately, Jeremy has passed away, but I have been involved in Beyond Budgeting movement since then, and I've been the chairman of the Beyond Budgeting Brown Table for many years. It is a network of interested individuals and companies, and we have been operating since 1998.

Beyond Budgeting was born before the Agile Manifesto. The two have many similarities. However, there was no contact at the time. Fortunately, that has changed today. There's a lot of contact, and there should be because this is about business agility in practice.

Avanscoperta: So indeed you are the best person right now to learn about Beyond Budgeting in the Master Class we’re hosting in Berlin together.
Would you tell us something more about the in-person event?

Bjarte: First of all, I've been doing sessions on Beyond Budgeting for many years - workshops, keynotes, shorter sessions… It was actually a conference company that strongly encouraged me to do something longer than a one-day session. We tried it and it worked.

I have to say that, initially, two days could be a bit long for people participating, but the feedback has been extremely good. I have really enjoyed myself.
So I really like this format, because then there is time for good, deep, broad discussions, and engagement dialogue, which, when it's only one day, because this topic is so big, actually one day can be, or typically is, too short.
I promise participants two unforgettable days. If your feedback is as good as the other participants', you will not regret participating here.

Avanscoperta: Indeed we can't wait.
Let's go back a bit to the why is beyond budgeting a thing, why is it important and why we've seen it working many times. In which way is budgeting itself a problem?

Bjarte: Let me first define what we mean with budget, because a lot of people think about budgets just as cost budgets, but the finest definition is broader.
We talk about revenue budgets, profit and loss budgets, balance sheet budgets, and cash roll budgets, so it's a broader definition.
One problem or issue is that this is an extremely old management technology.

Budgeting was actually invented a hundred years ago, and I'm sure it worked well back then, maybe even 50 years ago. But today this way of thinking, of leading, and of managing, is doing exactly the opposite of its original intentions, which was actually to help organizations perform better.

Today, this way of managing is doing exactly the opposite. It has become more of a barrier than a support for getting off to the best possible performance. And that problem list is long. I mean, it's a very time-consuming process. It creates gaming and lowballing, sandbagging, resource hoarding, and fancy December spending. Assumptions are quickly outdated.
To define good performance as hitting budget numbers is very narrow and often completely irrelevant.

So we need a richer, broader, more intelligent definition of good performance. Is it, for instance, a good performance to hit your cost budget if you could have spent less or should have spent more, as one example?
And how do you know upfront in the Autumn what the right spending level is? How do you know exactly what the right spending mix is within that spending level? How do you know what is the right dose of travel cost for next year? No, we don't. But still, we insist on putting numbers on this.

These numbers become the truth against which everything shall be managed. You know, I sometimes wish that we all woke up one morning with a collective memory loss in this area. We couldn't remember anything about how we were leading in managing. And I doubt that what we would then come up with would resemble anything like traditional budgeting. What we would come up with is closer to the stuff that we are talking about now.

The problem is that we don't have that memory loss. And on the contrary, everybody remembers too well and everybody is too scared to break out of it, right?

Fear is a big element here—the fear of losing control. But many people haven't understood that the control they are so afraid of losing is nothing but the illusion of control. And when people ask me, “Will we lose control?” My response is, “Yes, we will lose some control, and we shall lose some control.” That's the bad control, the stupid control. We will get more of what we call good controls.

One example of a good control mechanism is, for instance, transparency, which is a very simple self-regulating way of making sure that people spend money wisely.
I've got loads of examples of how transparency is used as a control mechanism in the masterclass.

Avanscoperta: This links back to the two points you mentioned before, which are trusting people and predictability of the future.
The first point I'd like to stress now is this: How do you enable a culture of trust, which is basically one of the foundations of the whole beyond budgeting approach?

Bjarte: The interesting thing is that executives and managers, or especially executives, are asked, "Do you trust your employees?" Then almost everybody will say, “Yes, of course, we only recruit the best, right? Of course we trust people”. And sometimes they even mean it. Not always, but sometimes. So that's not the issue. It's not the issue of what these guys are saying, what they are writing.

The issue is, is this reflected in their management processes? And the answer is so often, no. That's the issue. The issue is this lack of coherence, these poisonous gaps between what is said and what is done in organizations.

One classical example is to talk loudly and warmly about how fantastic employees we have on board. But then still insisting on detailed travel budgets. Again, hypocrisy.
Or if the organization talks equally much about collaboration and teamwork and everybody is in the same boat, but when it comes to rewards, it's all about individual bonuses. Again, there are poisonous gaps between what is said and what is done, and people notice this.
And then the words become hollow because the management processes have the opposite message.

So if you want to show that you're serious about trust, show it in your management processes, which includes, for instance, kicking out the detailed travel budgets and a lot more.
And trust me, generally and typically, cost does not explode, if you apply the right control mechanisms to it. Very often costs actually come down.

But again leadership, including trust, is not something you can talk about in isolation. You have to look over your management processes and make sure that the words are reflected in those processes.
This is key in Beyond Budgeting—creating coherence between what is said and what is done. This is why Beyond Budgeting has 12 principles. Six are on leadership, like purpose, autonomy, and transparency. Six are on management processes, like target setting, forecasting, resource allocation, performance evaluation, rewards, and recommendations on the rhythm of all these processes.

There is also a strong focus on creating coherence between what is said about leadership and what is practiced through these management processes.

Avanscoperta: So many things resonate with what we've been discussing during our previous interviews with our other trainers, whether it's OKRs, portfolio management, or, again, the culture of trust and all of this.
This brings me to ask you, who is this for? From what you say, it looks like it's not for, let's say, smaller companies, but maybe more corporate, bigger teams. Or is it not?

Bjarte: It's both for the big and for the small.

It's for the big, given the advice on how they can find their way back to that business agility they had as a smaller organization.

Because I keep saying that companies are born beyond budgeting. They become something else when they want to grow and become big because they copy what the big companies are doing, and then they end up in the same misery of bureaucracy, rigidity, lack of engagement, and all that.

For big companies, it’s about how to find their way back without losing the benefits of being big.
For small companies, it’s about how you can grow without ending up in the same misery.
So it’s for big and small companies, it's for managers, it's for finance people, it's for HR people, it's for agile people, it's for everybody interested in these important issues of leadership and management.

Avanscoperta: Is it more for people who are in charge of someone else or charge of some processes?

Bjarte: Not necessarily. Of course, at one stage, the executives need to be on board, but most revolutions do not start at the top. What you need are some brave and willing people who can take the lead on this and work on this to make it happen in the organization, including convincing executive teams.
I also recommend people from the public sector to come along. I will share some amazing cases from the public sector where stuff is starting to happen.

Avanscoperta: Are there any cases or suggestions on how to make this happen in a remote scenario?

Bjarte: Of course, everything in this area is more difficult when you are not in the same room. So if I could choose, I would always try and be together. If it isn't possible, of course, don't let that be a showstopper. It is still possible.
This is more challenging remotely because it is not just about changing what we do. It is just as much about changing how we think, right? And in my experience, that is easier when you can look people directly in the eyes.

There is no rocket science in beyond budgeting when it comes to changing what we do. We talk about rolling forecasts, relative targets or maybe no targets, holistic performance evaluation… but there is really no rocket science.
But if you try to do things in a different way with the same old mental models, then you will typically fail.

And of course, the change in how you think is the most painful one because so many people have grown up in that traditional way of doing it, believed it, maybe even made a career out of being good at it. So it can be painful to admit that maybe we need to change.

That's why I think it's very important that we be very careful when criticising people for what they have done. What we shall try to get across is that things have changed. And because things have changed with the competence of employees, with the VUCA (volatility, uncertainty, complexity and ambiguity) level of the business environment, we need to change how we work.
And the starting point is accepting those changes. If you accept those changes, you have started to change how you think.

Avanscoperta: This links to the second point, one of the assumptions that you mentioned at the beginning about the future. Change is not only the overall evolution of things but also the fact that we cannot predict things.
This again is connected to the relationship between agility, business agility and beyond budgeting, as workshop description there is no real agile transformation without beyond budgeting.

Bjarte: This is something I will talk a lot about in the masterclass, and we will discuss that a lot, because I'm a big fan of agile.

What I'm going to say now is no criticism of agile at all.

However agile was not designed and developed as a way to run an enterprise. It was born in software development and meant to improve software development and team work.

And agile was a huge success. But when you try to scale agile, the holes in agile become visible, and I refer to all the things agile didn't need to think about back then, because enterprise management was not the key focus.

These are the holes that Beyond Budgeting is filling, because Beyond Budgeting was born at enterprise level by people with deep and strong experience from corporate enterprise level.
I think that is one of the main differences between agile and Beyond Budgeting.
But again, there are many similarities, and the two together can be extremely powerful.
Agile transformation without Beyond Budgeting? Forget it.

I think that's why so many agile transformations are struggling because they have not realized it. These organizations are trying to scale agile using exactly the same framework, language and labels that did wonders in the software development area and back then. But you can't scale it without broadening this, and that is what Beyond Budgeting is doing.

Avanscoperta: Let's come back to the actual workshop. How did that happen? When did you start to deliver this, and why? Was there a request in particular?

Bjarte: I've been doing things like this for almost 30 years now since my Beyond Budgeting career started back in the mid-90s. In the beginning, there was a lot of interest in the finance community, then it later spread to the HR community and to the Agile community. Lately there’s been quite a lot of interest from corporate-level executives and also the consulting business.
And now I'm talking about the big consulting companies, which have become seriously interested in Beyond Budgeting.

I’ve been asked to do this for a long time. I've done a number of one-day workshops, but then it was this conference company that strongly encouraged me to run a two-day session. And I'm very glad they did because it has worked very well.

Avanscoperta: How can one get started with the Beyond Budgeting? What are the first steps?

Bjarte: I would definitely recommend people to check out the Beyond Budgeting Roundtable website, which has a lot of information. You might also want to check out my website. On both websites you find reading recommendations and also other relevant stuff.

Avanscoperta: As we were discussing before we started this conversation, I found out not only you published two books… ut they actually are two and a half books. How come?

Bjarte: What happened was that back in 2008 I wrote my first book, it's called Implementing Beyond Budgeting, aimed at finance people. You might know the one who wrote the forward, the American professor Robert Kaplan, who is the inventor of the Balanced Scorecard.
That book did really well, and a lot of people encouraged me to write a new book. My US publisher encouraged me to write the second edition first, and I ended up with something in between. So it came out in 2016, and it’s called Implementing Beyond Budgeting second edition, but there's a lot of new stuff in it compared to the other ones, that's why I call it that two and a half books.

These two books have one thing in common: They are normal book lengths, say 250 pages. That is too long for many busy people, including executives with limited time to read.
So my last book, which came out recently, it's called This is Beyond Budgeting, it’s much shorter, more focused. So busy people can have time to read it. It's also out in audiobook for those who don’t even have time to read, but they might drive or fly from time to time and so they can enjoy the audio book.
The last book has a foreword by Professor Gary Hamel, who is US-based, and Gary is number one in the world within the management innovation area. He is simply unbelievable. If you haven't heard him, check him out. He's got some amazing videos. He's simply dynamite, so I'm really proud that he wrote the foreword.

Avanscoperta: As we mentioned, it's not only a change in how we do things but also about how we think. Of course, whenever you try to introduce something new and different, you might get good, but also bad response. So I wanted to know from you what was the best and worst response to this approach.

Bjarte: There are stories in both camps when it comes to best and worst, but fortunately, much more good stories than bad stories.

Very few companies go back once they have started. I don't need one hand to count the number of companies going back, and we know the reasons why. It's about a two-week case for change or a flawed implementation. But fortunately, these are the very few exceptions.
The big majority do not go back. On the contrary, they become braver as they go along. Because this is a journey where the direction is clearer than the destination, to the extent there is a destination.

What is scary today is not scary tomorrow, because it works.

Fortunately, I don't have many of these worst responses to share with you because there's been so few. It has been sad the few times I have learned that companies are going back.

Sometimes, it's also linked to a radical change in top management before this platform has become solid enough to withstand some earthquakes.

Avanscoperta: Thanks a lot, see you in Berlin!

Check out Small Talk on YouTube or Spotify.

Credits: Picture by Jodie Righos on Unsplash

Learn with Bjarte Bogsnes

Bjarte is the trainer of the Beyond Budgeting Master Class, a 2-day event taking place in Berlin on 10-11 April 2025.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

This blog post is the transcription of the chat we had with Jenny Martin about her OOPSI Workshop.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Let's start with the basics: What is OOPSI and what does it stand for?

Jenny: OOPSI stands for outcomes, outputs, process, scenarios, and inputs.

It's a collaboration framework that helps teams collaboratively break down complex problems. All the different sections of OOPSI offer an opportunity to collaborate, align the team towards value, and get real concrete focus for what you're doing next.

It essentially comes from wrestling with different analysis and testing practices, trying to figure out how to get started, start small, and integrate other practices usefully.

Avanscoperta: Thanks, Jenny, so we covered the basics. One of the things we read on the website description is something like you can just start small and still deliver something valuable, right?

Jenny: OOPSI helps you navigate towards a point where you can get started.
When we work in an agile environment, there are often many small user stories and lots of complexity. It's difficult sometimes to know how to get started, even though you need to collaborate and have these conversations.
It does this by guiding you through these different steps, which spell out OOPSI. As you go through those steps, each layer is an opportunity to prioritise, inspect, illustrate, and achieve a shared understanding.
So you're able to work through those different sections to a point where you have a really concrete example-based test for a specific process, generating some really concrete specific outputs that will help define what you're doing and align the team towards it.

So how does OOPSI work?

In terms of how it fits in with what you're normally doing, you might have a kickoff OOPSI workshop at the beginning of an initiative, and you might figure out the key outcomes and the key outputs and illustrate those, which will give you a really good understanding of the higher level of scope that you're looking at.
You'll then examine those outputs and look for the really important ones that you want to generate first as part of your system.
This will lead you to analyze the process and hunt for the most important scenarios so that you can start developing your user story and different acceptance criteria and tests.
It helps you defer some of that thinking and still have an opportunity for really good feedback as early as possible.

Avanscoperta: One of the things you mentioned is that OOPSI is about the whole team, right? Not only developers or a specific profession, because something is only targeted at some parts of the business or of the IT department.
What we see with OOPSI, as well as with other things like EventStorming, is that it's somehow aimed at the whole team.
Let's be more specific and say, for example, who would be the best person to use OOPSI and attend the workshop?

Jenny: It does change a little bit as you go through. So it's useful to involve, all kind of key stakeholders and key people involved in an initiative at the beginning, particularly for the outcomes and the outputs part where you probably want to involve the customer or somebody as close to the customer as you can, similar to EventStorming, right?
So the domain, you're understanding the domain, you're understanding the ubiquitous language and you're figuring it all out together. For that part of the process, you would typically have somebody representing domain knowledge, somebody representing development or design knowledge, somebody representing testing knowledge or expertise, all different representations.

As you move through OOPSI and into the scenarios and inputs part of it, it looks more like the three amigos, where you'd have a developer, a tester, and a product owner or business analyst figuring that out together.
So OOPSI represents different levels of detail. As you get closer towards the end of OOPSI, you're looking at more low-level details.

Avanscoperta: At each one of these five stages, we might have different people involved.
Jenny, where did it start? Where did the original idea come from?

Jenny: Eight or nine years ago, I was working in a small team, and we were using practices like specification by example, from Gojko Adzic, which is an acceptance test-driven development type of practice, which really brings forward concrete examples into the discussion on the development team to help you avoid mistakes and rework. We were using that with really, really great results.

I was also interested in Chris Matts's work, which examined feature injection and practices based on starting with outcomes and using outcomes and behaviour to drive your approach to software development.
I was also looking at some work by Kent McDonald on agile analysis and how you actually get into those rhythms of agile analysis.

It wasn't just me looking at this on my own, there were other patterns of agile behaviour in teams and other experts who were looking for a bit more structure around processes, in particular how to help collaborate.

Jeff Patton's story mapping was also happening when I first discovered this, and as I was talking about it to my colleague Pete Buckney… it sort of just developed.
I started writing “outputs, outcomes, process, inputs,” and I thought there was a bit in the middle that brought things together, like cucumber and scenario stuff. Then I realized it was “OOPSI.” Of course, that's a bit tongue-in-cheek, but it's kind of stuck since.

Avanscoperta: We're talking about roughly 10-15 years ago, is this correct?

Jenny: We said all of those things when we started using it, and it sort of formulated into OOPSI, I guess, in about 2015, so gosh, yes... that is 10 years ago.

Avanscoperta: Thanks Jenny for the overview. Let's go back a bit to what we are actually gonna do during the workshop. We said it's two half-day modules remote. What's gonna happen?

Jenny: On the first day, we'll examine the key concepts around OOPSI, how you do it, the key process patterns, and some of the principles behind it. The second day is much more about hands-on work through examples of OOPSI so that you can feel confident actually taking it out there into your organization and having a go.

Over the years, I've developed many examples of OOPSI and many exercises, which helps it land because I've been doing this for quite some time in various ways.
It's very much participatory. There's room for discussion and reflection on how this might work in your environment, how it might work based on the software development methodology that you’re using, because you can really apply it to all sorts of environments.

So on the first day, we have an overview and all the key principles, methods and process patterns, and on the second day, it’s much more about working through worked examples, discussing, sharing and leaving feeling comfortable that you've really able to put it into practice.

Avanscoperta: As you mentioned, the workshop will be very participatory and interactive despite being remote. Of course, you won’t just sit and watch slides, and that applies to all our workshops, and yours will be no exception. We can't wait to have this full interactive experience. We'll be on Miro, Zoom, and Slack…

Jenny: It's incredible what you can do with Miro and how you can design remote training to be engaging and powerful. And the post-it notes don't fall off the wall, so there's a benefit there.

Avanscoperta: It’s the first time I've considered this after all these years—that’s a great benefit indeed!
I also know you are in the process of formalizing this wealth of knowledge in a book. As it’s not a secret anymore, would you tell us more about it?

Jenny: As you probably know, in the last few years, I've been involved in lots of different things, including product and agile development stuff. I also work with teams on other things.
And so for that reason, I haven't written about OOPSI for a little while. And then it just keeps coming back to me from time to time.

I keep hearing that somebody went to an interview and was asked what practices they use, and they've answered, “I use OOPSI”, or I find out that the consulting company in the UK has done comparisons with example mapping in OOPSI and has chosen OOPSI, or I find out that organization based in the States somehow found out about OOPSI and they're using it to underpin their development framework and testing framework.

This has given me a real nudge this year, as it keeps coming back, to actually write something down beyond the articles and blogs that I've done. So I’ve been accumulating content, examples and all of that stuff for quite some time, and now it's just about getting on and doing it.
I'm actually doing it in the open with a colleague who's also writing a book and we're doing fortnightly sessions, zoom calls, and asking each other questions, and sort of capturing all of our thoughts verbally and then going back and refining them.
So far I've already done the introduction and the overview.

Avanscoperta: The feedback and writing process with your colleague, where you literally verbalize and write down as you speak, is just amazing.

Jenny: Also there’s a lot of folks in the community, people with a lot of agile experience, agile coaching and product development experience. So I'm seeing if I can convince them to rally around and give me some feedback. So, watch this space!

Avanscoperta: Do you already have a release date in mind, or a deadline you gave to yourself?

Jenny: We gave ourselves six months, and we started in December, so that will be June 2025. It feels good.

Avanscoperta: Thanks, Jenny. Now we get to one of the questions we need to ask, and it is the famous, “So what?” After years of talking to experts, at one point in this conversation, you might find yourself asking, “Okay, so what is actually the problem that we are trying to solve?” So I would like to know the same about OOPSI.

Jenny: There are quite a few things actually.

There's wanting to get started small, but not knowing how to break things down, and that's a big one. One of the challenges with agile delivery is knowing when to do the deep thinking and where that fits into your iterations because sometimes it feels like there's no time for that. So it definitely addresses that.

The other thing is about rework. So if you're finding that your team is working on stories or working on implementation and they feel like there's a lot of rework or a lot of errors or that the documentation doesn't feel quite clear enough and there's back-and-forth, OOPSI really helps with that because the practices of collaborating together around examples and making things really concrete are absolutely embedded in the OOPSI approach.

It also gives you a line of sight from the small things you're working on to the bigger picture, which is really important. So, one of the challenges working with small tokens, like user stories, is that teams can feel a bit lost in terms of how what they're working on contributes to the overall problem that they're trying to solve.

So OOPSI takes you through a process where you know how what you're working on contributes to the outcome you're trying to achieve. That's really useful because teams that are strongly aligned towards outcomes make good decisions. They're more motivated because they're solving problems together rather than just being given a load of work over the fence.

As we can see, OOPSI solves lots of problems. It helps you stay aligned with valuable stuff and do the work on the things that are most important first so that you're always working on the most important thing which ultimately helps you optimize your whole process for feedback.

Avanscoperta: The next question is how to get started with OOPSI.

Jenny: The most recent blog that I've done on LinkedIn is the main source as of now.
Understanding the value of collaboration and the use of examples is important. So you might start by just getting together and talking about these things, such as, “what are the outcomes? Tell me about the important outcomes. What are the important outputs that drive those outcomes? Which process do we use to generate those concrete outputs? What are the most important scenarios?”.

So I guess even if you don't know much about OOPSI, it's a good conversation framework. If you find yourself holding the pen, trying to figure out what the needs are of a customer or how to get started, those questions around understanding all those different things will help you get started and help you collaborate around the important stuff and find the gaps.

Avanscoperta: We have a comment from Martyn. “I started using OOPSI on project design to bring out the end goal and drill down from the outcomes into the fine-grained individual work items, even when the outcomes are subjective, looking at outcomes, efficiency, effectiveness, economy, and evidence of empathy.”

Jenny: That’s all it is, really. Starting with the outcomes should always make sense. And then the next step will be exploring how well those outcomes are understood.

One of the pitfalls of user stories is just blindly following some user story kind of parlance without anybody properly understanding or taking the time to understand the problems that they're trying to solve. That's an important one.

Avanscoperta: Let's close with the feedback on OOPSI so far. So, best and worst response to OOPSI.

Jenny: The really good feedback comes from folks who say to me, “This is exactly what I've needed. This has given me clarity and structure in what we're trying to do. It's helped us collaborate. It's so simple”. Or, “Wow, you can get started that quickly with an example. This makes so much sense that everyone can see what they're doing”.

I guess the worst sort of feedback is when people say, “Oh that sounds like a mistake, OOPSI”, and I'm kind of like, “Yeah, you know, it's just an acronym that people know and that they can remember”.

I'm not sure if this is good or bad but when I presented this at Skills Matter about eight years ago when I was doing one of my first talks, somebody in the audience said “Well, if you work the wrong way up through OOPSI, and you start with the inputs, it IS POO”... which is true! If you do it wrong it doesn't work!

I don't know if that's a good thing or a bad thing. It's a nice story, though.

Avanscoperta: Thanks Jenny and see you at the workshop!

Check out Small Talk on YouTube or Spotify.

Credits: Photo by Zdeněk Macháček on Unsplash.

Learn with Jenny Martin

Jenny is the trainer of the OOPSI Training Course (online and in live-streaming).

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

Il 12 dicembre 2024 ho partecipato alla seconda edizione di LSP Camp, l’Unconference italiana di LEGO® SERIOUS PLAY®, magistralmente orchestrata da Emanuele Moscato e 📌Piergiorgio Lovato, e generosamente ospitata da Sensei Srl.

Il principio dietro a questo evento: se il Metodo LEGO® SERIOUS PLAY® è condiviso da Lego con un documento sotto Licenza Creative Commons (dove si trovano i principi fondanti e la filosofia LEGO®), allora il metodo non può essere cosa per pochi. E il Camp vuole essere il luogo per tutte le persone che hanno voglia di praticare, esplorare, conoscere, capire, imparare LSP.

«Non solo un "evento", ma l’inizio di un laboratorio permanente, in perfetta sintonia con uno dei valori del documento open source: we welcome creative uses of these tools, and innovation in the community», si legge sul sito di LSP Camp.

L’evento si è svolto con una leggerezza e una fluidità eccezionali.

Al mio arrivo alla venue, nessuna accoglienza formale ma una bella maglietta dell'evento a disposizione su un tavolo; su un altro tavolo name tag e minifigure di carta da personalizzare con i proprio dati e appiccicare su una parete.

Alle 9:45, tutti riuniti nella sala principale, breve connection, spiegazione di come funziona un Open Space e via a popolare il Market Place!

Sono state proposte 24 sessioni in totale, tra lo slot della mattina e lo slot del pomeriggio. Molto interessante la decisione di avere il primo slot tutto dedicato a proposte di “SKILL BUILD”, cioè proposte più “entry level”: workshop di comprensione del metodo, per settare le basi.

Le sessioni a cui ho partecipato

Mattina

Fioriamo - Sara Parroco
Una sessione "SKILL BUILD" molto efficace e tenuta con grande competenza, chiarezza e leggerezza da Sara Parroco.

Formazione Legale - Maria Meloni
Una bella sessione di co-progettazione di sessioni di formazione in ambito legale con l'aiuto dei mattoncini.

Restituzione e pausa pranzo

Pranzo delizioso di BoxingCatering srl e consumato nella bella terrazza di Sensei.
Breve activation post-pranzo facilitata da Giuliana Ubertini

Pomeriggio

Kol Katso: un workshop per dire "No" in maniera creativa - Beatrice Gamba
Esplorazione delle diverse opzioni di risposta oltre ai canonici "Sì"- "No". Un workshop per riflettere e fare introspezione, per distinguere i fatti dai pensieri e dalle emozioni, e permetterci di agire consapevolmente.

Pensavo che... Ho capito che… Perché avevo bisogno di…

Questions Design - 📌Piergiorgio Lovato
Le domande sono la struttura di una sessione LSP di successo, oltre l'effetto WOW dei mattoncini!
Piergiorgio ha condiviso i principi guida che lo aiutano a progettare le sessioni di LSP. Su questi principi, Piergiorgio ha scritto un post dedicato.

Bonus track

LEGO + Training From the Back of the Room - Carlo Rizzi
Non ho partecipato alla sessione di Carlo ma è doveroso citarlo qui perché Marco Dussin ne sarà molto fiero! :)

È stato bello rivedere Valentina Vantaggiato, Giada Trovato, Luca Cianci, Alessandro Giardina e conoscere tante nuove persone.

Grazie Lego®Serious Play® Camp per aver organizzato questo evento, grazie Avanscoperta per l'opportunità di studio e crescita continua.

Avanscoperta

Avanscoperta è un ecosistema di professionisti con una grande passione per l'apprendimento: amiamo esplorare nuovi territori, scambiare esperienze e idee nel campo del software nel senso più ampio possibile.
Cerca tra i nostri corsi quello giusto per te oppure scopri come aiutiamo le organizzazioni.

Rimani in contatto!
Vuoi continuare a leggere i nostri articoli? Iscriviti alla nostra newsletter 📩.

This blog post is the transcription of the chat we had with Allan Kelly about his Writing OKRs Class on 16 July 2024.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Hello Allan, we're glad you're joining us for this chat about your upcoming Writing OKRs Class. Would you please introduce yourself and then explain OKRs—what they are and what we're talking about?

Allan: There are different ways to answer that question; I never know how to answer it. These days, I help companies become more effective and productive, and I tend to call it modern management in more general terms. Yes, it includes a lot of agile stuff. It also includes OKRs and product thinking, as in thinking about your product more than about your project because products have longevity. I help companies do this, in one way or another.

Once upon a time, I was a former programmer. I got into doing this because I wanted to make life better for the younger me, the former me who'd struggle with meaningless projects and pointless deadlines. I want to make the world better and that's why I do this.

Avanscoperta: We often hear this, "I want to do what the younger me would have liked to know". That's wisdom. So Alan, what are we talking about? This chat is about OKR—Objectives and Key Results.

Allan: The way I like to think about OKRs is that they’re a test-first management tool. The same idea we've been applying in test-driven development, test-first development, on BDD and all that good stuff.

What we're basically saying is,

What is the objective? What is the outcome we're trying to create? What is the change in the world? How do we want things to be different? That's your objective.
It's an outcome you're trying to bring about… and your key results are effectively your tests.

The key results are where you're going to measure whether you've met that objective or not, whether you've got close enough to it, whether you've got fast enough, if you’ve had enough customers, or whatever the characteristics of that objective that you see as valuable and useful. You codify them as key results.
So, in a nutshell, tell me what we're going to do and how you're going to measure it, and you'll get objectives and key results, respectively.

The other thing to say is that we typically do this in 12-week cycles. It doesn't have to be 12 weeks, but it's a great big-time box. When you get to the end of your time box, you do not just roll things over to the next quarter because after that 12 weeks have passed the world is a different place.
You need to sit down and assess the situation, as in we are closer to the outcome we wanted. We may not be all the way there. We may not met all our key results tests, but right now it's the best thing we can do for the next 12 weeks to do more of the things we've been doing for the last 12 weeks. Or is there something else? And we should bank what we've got and focus on something else.

Avanscoperta: I really like the idea of OKRs being a cycle. They're not something that you set in stone once and forever, but rather something that you review—in your example, every 12 weeks. It fits very well with the messy times we’re living in. It’s not like you decided something one year ago and it stays there forever. We need to be adaptable and flexible.

Allan: It's one of life's great conundrums, isn't it? Do you stick with the thing you've decided to do and you bear with it, you keep working hard at it? Or do you dive off in a different direction to do something different?
Both extremes are wrong. It's wrong to keep flogging a dead horse, to keep doing something that won't return. It's also wrong to keep shooting in different directions and not being consistent.

We found that, at the micro level, every two weeks is about the right schedule. What we're saying here is that we've got to step back a bit, think a little bit more long-term, and think about 12 weeks at a time.
In this way, we'll get two perspectives.

Avanscoperta: Let’s talk a bit about the workshop we’re doing together. It’s a 3-hour online class called Writing OKRs. It’s an extremely practical learning experience where folks will experience how to write good measurable OKRs. Who is this for?

Allan: One answer is anybody who needs to set OKRs, anyone who's involved in the OKR-setting process. The most obvious people there are scrum masters, agile coaches, product owners, project managers, and people who consider themselves to have some element of leadership.
However, my approach to OKRs is that I see them as a team-level initiative. Teams should be doing this together, and everybody on the team should have a voice in the OKR setting.

I can quite believe that anybody on a team using OKRs would get value here. The people who are going to be most interested are people who are responsible for those OKRs—responsible for setting and pursuing them, so anyone with any kind of leadership or management title.
I also know this is landing on the plates of many scrum masters and agile coaches, which is certainly how I got into them in the first place. If you're a scrum master or an agile coach, it might be an opportunity to get ahead of the game.

Avanscoperta: I remember one of the profiles or roles we referred to when we first started talking about this with Allan was folks who are somehow victims, those who are forced to use OKRs. What do we mean?

Allan: A few years ago, I knew about OKRs. I'd heard about them. I'd probably even made some talks on them. I was coaching at a company, and we were on a call one morning, and we just got told by a senior person, "Oh, and we want you to add OKRs. We want the teams to do OKRs." On top of everything else they're doing, on top of Scrum, on top of the Spotify model, on top of whatever, "Oh, by the way, can you just do OKRs?"
This was one of my motivations for writing the book. I wanted the book that I wish I'd had that morning.

But the other agile coaches were pretty much in the same position. We all kind of had some understanding, but none of us had done it.
I've joked about this story because it is humorous looking back on it. But it turns out this is an experience that is quite common. Companies have a habit of saying, "Oh, by the way, can you just add OKRs to the mix?" If you ask, "Can you just add barbecue sauce as well?" It's just added in there. It's a bit like that old Dilbert cartoon, where Dilbert says, "Where's my training?" And the manager says, "That was it."

People get dropped in it. And you can survive. It can be a baptism of fire. I myself ran out and bought the books and read the blogs…
But at the same time, it's going to be so much faster and so much more effective for you to spend three hours with us. I like to run the workshop as a practice setting. You can practice setting OKRs in a safe environment, ask questions, and discuss some of the dos and don'ts. I’m just trying to save you six months.

Avanscoperta: Would you recommend that folks come along with their senior colleagues—aka the ones setting OKRs and the ones who have to use them afterwards?

Allan: I would like senior people involved, but

for me, OKRs should be bottom-up. They need to be set by the teams who are going to deliver them. The senior people are going to paint the big picture, some overriding objectives, and goals, and describe where the whole organization is going. But then effectively, they say to the teams, “How can you help?” And the teams reply by saying, “In the next quarter, we will do this”. And they offer the OKRs.

I see that as a feedback loop. The senior people are saying, “Look, our great objective is this,” and the teams are saying, “OK, in the next quarter, we can move that forward.” They offer that up, and they have a consultation, then feedback, and so on.
Senior people might not be in the room, but I think it can help. Similarly, I think an appreciation from those senior people of how OKRs work and what to expect when they've been set.

For example, one mistake often made with OKRs is that they have an objective and then key results that come in afterwards, and they read like a to-do list.

• Objective = build a house.
• Key result 1 = build the foundations.
• Key result 2 = lay some bricks.
• Key result 3 = putting some plumbing.

And that's not how it should be. Too many people expect that.
If you'd like to know more about OKRs, either because you're setting them, or you're going to be reviewing other people's, then please come along.

Avanscoperta: Now that you mentioned this bullet point approach, it reminds me of another workshop we are doing with a person you also know, because he's translating your book "Succeding with OKRs in Agile" into Italian, and he is Francesco Fullone aka Fullo.
As we ask participants for some warm-up questions before the workshop, one of the most common issues is that people think OKRs are just a to-do list of things where the overall picture is not taken into account.
We know it’s not a matter of just completing some tasks, rather everything needs to be connected with the mission and vision of the company and of what we’re trying to achieve in general.

Allan: Indeed it is Key Results, and not Key Things-To-Do!

Avanscoperta: The next question is, why is it so difficult? Crafting and writing some good OKRs, which you can measure in a few months, can be challenging, otherwise, there wouldn’t be workshops and training about it. I'm sure you've seen loads of people getting it wrong.

Allan: There are three reasons.

One is the easiest one to deal with, and it refers to quantification. Key results should have numbers in them; you should be able to quantify them somehow. If you don’t have a number in a key result, it's immediately suspicious.
And it's difficult to quantify a whole bunch of things, and it's difficult to quantify less tangible things. And this is the first issue.

The second one is that it is actually difficult to think yourself into the future and imagine how the world could be different and how you're gonna be able to measure the world being different.
That also means you'll have to talk to people about how the world is going to be different and listen to their points of view.

The third reason why it's difficult is the whole problem of psychological safety.
Imagine setting something that you're going to use to judge yourself. Particularly in an environment where it's not safe to fail, this can be really scary.

So sometimes the issues you're having around this may present as an issue of measurement or as an issue of not really understanding something... but deep down inside, people are just nervous about offering something up which they could be seen to fail at.

Avanscoperta: This leads me to the next question which is about company culture. You just touched on psychological safety. How do OKRs play a role in that? What’s the best setting? How do you suggest people introduce OKRs in a good way if the company culture is somehow wrong?

Allan: You've got two broad approaches here.

You can either say, “Let's make everything right, and then we can infuse OKRs”. And I see the logic in that, I see why people wanna do it, and it's hard to argue with it that we must get A, B, and C already, and then we can infuse OKRs.
However, I suspect you'll be waiting a long time.

The way I prefer to see OKRs now is that

the OKR process is imperfect, and it is not something you do when you have the company culture you want, but it is a mechanism for bringing about a better company culture.

So when you're setting OKRs, and when you start to see that people aren't setting very stretching OKRs, and they're setting safe, achievable OKRs, that's the time to start saying, “Do we want them to be more ambitious, and what would we need to do to make people more ambitious?”

Is it because our reward system isn't aligned? Such as when people get bonuses for meeting some goals, so they all want goals they can meet. Is it because people don't see as though they can speak up?

Seeing OKRs as a mechanism for bringing about changes in the organization, so that the organization is open, is embracing a different point of view, is psychologically safe, is ambitious, does accept that there's always some element of business as usual…

Whatever those issues are, you need to consider OKRs as a mechanism for highlighting those problems, and then you can fix them.
I sometimes go as far as calling OKRs a strategy debugger because, using that feedback process we talked about before, they allow you to discuss the bigger questions.

Avanscoperta: Excellent, thanks Allan. I know a lot of your work has been in the agile field too. So how do the two worlds of OKR and Agile come together?

Allan: It's painful because so often I see OKRs used in a non-agile fashion. If you think about where OKRs came from originally, they grew out of an earlier technique called Management by Objective (MbO), in the 1970s, and some of the literature you see on OKRs is still rooted in the 1970s.

When you look at them, the OKRs people were writing in 1975 are decidedly un-agile. They are decidedly top-down and follow the bullet point approach we’ve discussed earlier (which should be avoided).
And that flies in the face, not just of agile, but of the fact that it's 2024. We have a workforce full of millennials, we are in a post-pandemic world, and people are looking for more control and more meaning in their work.
If you implement OKRs like it's 1975, you won't have that. You'll have a command-and-control MbO system.
I'm sorry to say an awful lot of places deal with OKRs like that.

However, if we accept it's 2024, and we've had the agile revolution, we've got the millennials, we've had the pandemic and we need to enroll people in the way we're working…

And if, instead of considering them as a thing that trickles down from the top, you look at OKRs as something that the teams (and teams are the fundamental unit of work) are using to communicate what they're doing, in an environment where teams are setting their own goals. And indeed the teams should be setting their own goals, their own objectives, such that those goals help their customers, their peers, their senior leaders in the company, such that they all dovetail together with those goals.

Think of it this way: If a manager says, "We're going to do something," the CEO agrees to do something, and then they start instructing everybody at every level on exactly what they have to do, it's a recipe for disaster because the senior people don't know enough detail.

On the other hand, if the senior leader sets out the overarching goals and objectives and asks the people who do the actual work, "How do we move forward? How do you help us move forward?" and the teams reply with their statement, which is their OKRs, then we can compare the two.

We can say, “Oh, the CEO thinks we should be entering the Italian market. Oh, but look, the teams want to translate their products into French. We've got a gap here”. What's going on here? And it could be that somebody is misunderstanding. It could be somebody has information somewhere. It could be the team who said, “We're going to translate to French”, knows that there's a really big French customer about to sign a deal if they do it. And if the CEO doesn't know that, they may well agree.

So, doing it in an agile fashion may be much more collaborative and a feedback process, embracing the feedback you can get here. And as I said right at the start, think of OKR as test-first management.

Avanscoperta: We know OKRs were not invented yesterday, but they’ve become somehow more fashionable lately—as in your example of managers wanting to do OKRs for the sake of it. Are they here to stay? What's the current situation?

Allan: They've been around for a while now. I think they will continue to be around in one form or another. I think they do fill a gap in the agile world. They’ve been very good at low-level, micro-planning, spring situations, even today. Some people have been coming up with ideas for roadmaps and strategies at the other extreme, so I think we've been missing something in the middle.

OKRs are a goal-setting framework. I think goal-setting is going to get bigger, and we need to connect our goals to a purpose.
I think OKRs is about the best goal-setting framework I know of. There may be something better out there. I see every reason that it's going to be around for a good few years yet.

Avanscoperta: Thanks, Allan. As we close this interview, would you please suggest some readings, books, blogs, or videos for our community to continue learning about OKRs?
As mentioned before, you’re the author of Succeeding with OKRs in Agile, soon available in Italian as well.

Allan: Yes, I just received Jeff Gothelf's new book, Who does what by how much? So I'm looking forward to reading it. It's next on my reading list.

Avanscoperta: Thanks Allan and see you at the workshop.

Check out Small Talk on YouTube or Spotify.

Pic by Afif Ramdhasuma on Unsplash.

Learn with Allan Kelly

Allan is the trainer of the Writing OKRs Class, taking place on 31 January 2025 online.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Subscribe to our Newsletter 📩 (available in Italian and English) and be the first to know when we schedule a new workshop or we publish a new workshop.

This blog post is the transcription of the chat we had with Chris Richardson about his Designing Microservices Workshop.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Chris, would you please introduce your workshop to us?

Chris: Designing Microservices Workshop is a three-day in-person experience. As you can guess from the name, it's about designing microservices. Specifically, it introduces a process, a sequence of design activities with deliverables for designing a microservice architecture. It's not about technologies like Docker, Kubernetes, Kafka, and many of the things that we traditionally associate with microservices.

This is for one simple reason—technology is important, but it's not the hard problem to solve when using microservices. The key to determining the success or failure of your development efforts is to design a service architecture.

You define the service architecture by identifying services, defining their responsibilities and APIs, and then designing distributed operations or requests that span multiple services. This includes appropriately applying service collaboration patterns like Saga, API composition, and CQRS.

This is the key challenge you will face when using microservices. If you get it wrong, in the worst case, you can create a distributed monolith that combines the complexity of a distributed architecture with all of the friction of a monolithic architecture. So, instead of accelerating software delivery, it will actually make it worse, and you can end up in a world of pain.  

The first thing you need to do is ask yourself - is the microservice architecture a good fit for my application? Do I have the complexity and the team size, the warrants using microservices, or should you stick with the monolithic architecture? And then if microservices are a good fit, in the workshop we will see how to design a good microservice architecture.

The workshop is targeted at senior developers, enterprise Java, C#, .NET, but all in all it's pretty language-neutral and technology-neutral.
So it's for people who are building enterprise applications, architects, CTOs, VPs of engineering, who either want to use microservices or are thinking about it, or are in the middle of using it, and want to do better at it.

Avanscoperta: One of the things that emerged is the importance of this workshop not being purely technical. So it's not about the technology itself, but more about the overall approach.
Let’s read a question from the audience—this one is from Marco Heimeshoff, one of our trainers (Hi Marco!). He asks: How does API composition relate to CQRS and microservice architecture?

Chris: Microservice architecture it's comprised of multiple services (two or more), and as a result, some operations or requests will span multiple services. In order to implement them, you need to use what I call the service collaboration patterns. And there's four patterns, two for implementing commands, which mutate data, and two patterns for implementing queries, that retrieve data.

This question actually asks about API composition and CQRS, which are the two patterns for querying data in a microservice architecture. So the problem you're trying to solve is something like - find order history, which has to query a bunch of services, such as order service, restaurant service, delivery service, so on and so forth, and gather data from all of them.

API composition is a very simple pattern in which a query is implemented by retrieving data, issuing subqueries to retrieve data from the services that own it, merging the results together, and returning them to the client, the browser, or whatever.
Whereas CQRS actually maintains a replica of the data, designed from multiple services, specifically to answer that and perhaps other related queries. The services that own the data publish events that trigger the update of the replica so that it can be queried.

These are the two patterns, and there are just different trade-offs associated with each one. API composition is super simple but it might not be efficient. So you might want to use CQRS, but then you've got the cost and the complexity of replication and the fact that updates are delayed and so on and so forth.
Each pattern has its trade-offs, and this is one of the key topics we’ll explore in the workshop.

Avanscoperta: When we talk about microservices, it's still one of those buzzwords that's been around for a good number of years now. And your work has been really important for this.
So do you think microservices are they still in their moment of hype somehow or is it fading? How do you see the implementation of microservices in the overall scenario?

Chris: I would say that it’s like every technology - they go through this hype cycle. It rushes up to the peak of inflated expectations where people just think it's truly amazing and it has no downsides. But obviously, all technologies do have downsides and then it plunges to the trough of disillusionment where everyone thinks it’s terrible. And then after that, you've got the sort of plateau of enlightenment followed by the plateau of productivity.

The ideal state is to reach the plateau of productivity, where you understand the trade-offs associated with the technology and know when to use it.
I would say that microservices are past their peak of inflated expectations, and a fair number of people are writing about how the pendulum has swung the other way.

And if you post, and this has been true for a while now, a really insightful tweet about microservices, the level of engagement is OK, kind of average. Whereas if I say something good about monoliths, well, the engagement is off the charts.

Interestingly, I actually wrote about this 10 or 11 years ago, talking about the Gartner Hype Cycle and microservices. I've sort of always viewed my mission as actually fighting against the hype and the anti-hype and moving developers to the plateau of productivity as quickly as possible so that they know when to use it and when not to, and also how to use it effectively as well.

And I’ve been doing this because it's my area of expertise, but on the other hand, it's a tool, you know, and you use it when it's appropriate and you should not use it when it's not appropriate.

Avanscoperta: This is a good hook for my next question about monolith vs microservices, sometimes referred to as a dichotomy but as you just said - sometimes is good to have a monolith, it is not always a bad thing.

Chris: Well, it's like, what is better, a bicycle or an aeroplane? Depends on where you have to go, right?

I feel that the software community can become very polarized, which should be avoided. To stay within the example, I might use a bike to get exercise around my neighbourhood, but I'm not going to Europe on my bicycle.

Avanscoperta: There's a quote from one of our trainers, he also does a workshop on microservices, and he’s called Gianluca Padovani. He basically says that the monolith is like a person who does not feel well, you shouldn’t fight against or hate the monolith. The monolith just needs treatment. You shouldn’t be against the monolith for the sake of it, kind of thing.

Chris: Ten years ago, I created the microservice architecture pattern language. In the very beginning, there were three patterns: monolith, microservices, and API gateway. This was the first release of the pattern language, and by definition, the monolith is a pattern—it's not an anti-pattern. It's got benefits and drawbacks, and it depends on when you use it—just like microservices.

In a way, I feel like I've spent a lot of the past 10 years trying to refine the criteria for when you should use one versus the other and the trade-offs associated with each one.

Avanscoperta: As usual, it’s all a big “it depends”, as it is with all trade-offs. Next question from the audience: Does a database have to be a microservice on its own?

Chris: Interesting question for a couple of different reasons. One of the defining characteristics of a microservice architecture is that services must be loosely coupled. And there's a few different meanings to that word, but one that is relevant here is loosely design time coupled, which means that changes to one service should not require changes to be made to other services.
A key part of loose design-time coupling is services not sharing database schemas, which would introduce tight design-time coupling.
The schema is basically an implementation detail of a service, which you should be free to change without having to coordinate with the 10 other teams whose services are using the same database schemas as yours.

It’s like a database schema per service, and ideally, to maximize the loose coupling, you should have a dedicated database server. But that's not a hard requirement; it's just convenient from an operational perspective. One service cannot overload a shared database and perform essentially a denial-of-service attack on the other services.

And we just covered some background. The wording of the question is interesting—does its database have to be a service? In my mind, in a microservice architecture, you have services which are like well-designed domain objects, a mixture of behavior as in business logic and data as in a database schema.

I wouldn't have a database and stick a REST API on it to make it into a service. That's very likely to be an anti-pattern, primarily because of reasons of design-time coupling and lack of encapsulation, because you're basically exposing the database in its entirety as a REST API.

Avanscoperta: Let’s go back to what we’re actually going to do during your workshop. You mentioned that the workshop won't be based on a specific language. So how are we gonna balance the theory vs practice aspect during these three days? What will we be doing?

Chris: There are certainly lectures. The overall format is that I will walk you through the five steps of the design process, which are:

• discovering system operations,
• designing subdomains,
• defining a service architecture,
• evaluating said service architecture and
• refactoring.

So those are the five steps of the design process.

We're going through that design process for an example application. At the start of each step phase, there will be lectures and discussions introducing what we’re going to do next, but then the bulk of the time will be spent getting together in small groups—essentially four teams—and doing the design exercise either literally on paper or, if you want, on a Miro board or whatever medium you want to use. I've even had people in workshops using spreadsheets as design documents, which sounds strange, but it definitely worked for them.

Then we get together, and another really valuable thing happens: we review the design and discuss it in detail. The format is lecture, design, exercise, review, and iterate until we're done, basically. Post-it notes can be used for this too. Not quite as many as Alberto, but you can use a fair number of them.

Avanscoperta: As we discussed, you’re also the author of a few books on microservices, one of them being very famous. Are there any tips or interesting stories about how the books came about, or is there anything you’d like to share about the process of writing a book, which I imagine must be a challenge somehow?

Chris: Microservices patterns came out in 2018, and was my second book. The first one was Pojos in Action, all about Spring and Hibernate, published back in 2006.
I don't know why, but for some reason, starting in the early 2000s, I sort of had this desire to write a book. I even started drafting a completely different book about web frameworks as in HTTP and frameworks… so that is to say I did have this strange desire to write a book.

And then the first one actually ended up taking four years, I think I virtually had post-traumatic stress syndrome. It was such a painful process! I like comparing writing a book to climbing Mount Everest—it might seem fun at first, but then you get to 20,000 feet where it's freezing cold. You're starting to get frostbite and you can barely function because the oxygen level is really low.
But you've invested so much in it that you can't quit. It is just a truly stressful experience, and that was the first time.

The second time I spent two years writing the book and it was a lot less stressful but to a certain extent… Mount Everest was still there. A lot of analogy applies. But I did not suffer from PTSD the same time around. I could actually open the book and look at it without getting an anxiety attack. That's a good improvement.

Avanscoperta: Is there a third book in the work by any chance?

Chris: Very unofficially I'm in the super early stages of thinking about the second edition for Microservices patterns.

Avanscoperta: Would it be an updated edition or will there be some new content?

Chris: The microservices patterns book was written from 2016 to 2018, and what's really cool about it is that the core patterns have not changed, but obviously, some aspects of technology have changed. Kubernetes has become much more mature, for example.

Surprisingly, a lot of stuff, the concepts have not changed a huge amount, but in reality, I feel like I've changed a lot. So the design process that I'm teaching in the workshop we’re doing together was developed after the book. So in the book, I just have a few pages dedicated to the process, whereas now I've got quite a rich body of work around this design process, meaning there are quite a few years of conceptual improvements that can be incorporated.

I guess a lot of people know The Hitchhiker's Guide to the Galaxy, which started off as a British radio drama and comedy. One of the quotes from one of the authors, Douglas Adams, is, "I love deadlines. I love the whooshing noise they make as they go by."

My publisher doesn't like that quite as much, of course!

Avanscoperta: One of my last questions is about feedback on this approach. Do you usually get called into companies to transform from monolith to microservices, or not? In general, how are people reacting to this?

Chris: In a nutshell, I’ve been teaching this workshop for a while now, and then some of the core concepts from the workshop—I've been talking about those even longer, particularly the dark energy and dark matter concepts, which are about the 10 criteria that you can use to evaluate the suitability of a design.
In general, the feedback has always been positive. Folks say that it provides a good framework for thinking about design. I think this is at the core of it.

And the key message is - it depends. The next thing is—well, what does it depend upon? It tends to depend upon these 10 criteria within dark energy and dark matter.

Overall, my work provides people with a great way of thinking about the numerous design decisions that they need to make when designing a microservice architecture and avoids the trap of simply defining lots of tiny little services, which is the myth associated with microservice architecture.

Avanscoperta: Are there any other resources we should check out as we prepare for your workshop?

Chris: Yes, microservices.io has a tremendous amount of content, and you can read about the design process.
There's also premium.microservices.io, where, for a modest subscription fee, you can read practical articles about the challenges that engineering leaders face and how to solve them.

Avanscoperta: Thanks a lot!

Check out Small Talk on YouTube or Spotify.

Cover picture by Mitchell Luo on Unsplash.

Learn with Chris Richardson

Chris is the trainer of the Designing Microservices Workshop, taking place on November 20-21-22, 2024, in Milan (Italy).

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

Di seguito la trascrizione della chiacchierata su Training from the BACK of the Room! (di seguito TBR) che si è tenuta il 28 giugno 2024 in diretta con alcuni alumni del corso: hanno partecipato Anna Lombardi, Giacomo De Luca, Valentina Vantaggiato, Cristina De Toni e Giada Trovato.
In diretta con noi anche Marco Dussin, docente dell’edizione italiana del corso, di cui si sono svolte due edizioni in presenza a Milano (giugno 2023 e aprile 2024). Si è trattato dei primi corsi di TBR in Italia e in italiano in assoluto.

L'intervista è stata leggermente modificata per adattarla al formato scritto.

Avanscoperta: partiamo con una breve introduzione di cosa è TBR, giusto per dare un po' di contesto a chi ci guarda, e poi dritti verso un'attività che è anche parte integrante di TBR stesso.
Oggi abbiamo con noi delle persone che si sono cimentate nel voler sperimentare un nuovo modo di apprendere, far apprendere, trasmettere conoscenza e imparare a facilitare questi processi. Per cui vogliamo raccontare come è andata nelle esperienze dirette di chi ha fatto il corso e poi ha provato a mettere in pratica quanto appreso nel proprio contesto.
Marco, iniziamo: cosa è TBR in due parole?

Marco: Training from the BACK of the Room! è qualcosa di estremamente semplice nel modo in cui lo facciamo, e cioè: andiamo a riscoprire che cosa significa imparare per davvero e lo facciamo tramite un corso che a sua volta è un modo per insegnare e re-imparare qualcosa per davvero.

In questo modo riscopriamo come alcune modalità di apprendimento utilizzate dal nostro cervello siano estremamente semplici, a volte le riteniamo così giocose e pratiche da essere quasi banali, ma in realtà, mettendole una dopo l'altra, e soprattutto strutturandole sfruttando alcune metodologie o modi per mettere le cose in ordine, andiamo ad aiutare ad apprendere le persone che partecipano in aula con noi.

In particolare, e ci tengo a sottolinearlo, non lo facciamo solo se siamo dei docenti, ma lo facciamo anche in qualsiasi contesto dove sia necessario condividere conoscenza.
E questo riguarda gran parte dei lavori che ci troviamo a fare oggi, nel 2024: in realtà trasmettere la conoscenza, raccontarsi le esperienze, fare le domande in una maniera opportuna o rispondere alle domande in una maniera pratica che permetta alla cose che impariamo di fissarsi nella nostra mente - ecco che questo può diventare strategico e interessante.

Quindi il riassuntone è che:

si tratta di un corso estremamente pratico, di un’enorme cassetta degli attrezzi con tanta roba, e infatti a breve le partecipanti e i partecipanti ci racconteranno che a volte la sensazione è quella di un sovraccarico cognitivo, ci sono troppe cose che si possono fare… in realtà, con questa cassetta degli attrezzi, scegliendo opportunamente le cose e combinandole con creatività tra di loro, è possibile strutturare esperienze di scambio di conoscenza più significative, più interessanti e più efficaci.

O almeno questo è quello che in genere ci dice chi poi comincia a sperimentare dopo aver fatto il corso TBR, e non lo dico io: a breve ce lo racconteranno.

Avanscoperta: grazie mille Marco. Intanto hai già toccato uno dei punti fondamentali, ossia: TBR non è qualcosa solo per chi ha come titolo professionale insegnante, docente o coach, ma si applica con tantissimi ambiti, e lo vedremo tra poco.
Quindi ti chiederei di introdurci alla prima attività: priming e connection. Cosa stiamo per fare con i nostri panelists per far sì che si presentino?

Marco: l'idea è molto semplice. Molto spesso quando ci ritroviamo con altre persone, che siano incontri di persone oppure online, si comincia facendo il giro di tavolo. Il che è molto gentile nei confronti delle varie persone perché così tutti si presentano e dicono qualcosa su di sé.
Ma dall'altra parte, quando partecipi al giro di tavolo, dopo la quarta persona che si presenta, cominci a fare clic con il cervello, come se lo spegnessi, e questa è esattamente una delle modalità che il nostro cervello mette in campo perché non ritiene più interessante ciò che sta succedendo, e magari ha pure ragione, e in qualche maniera smetti di memorizzare, di controllare e di ascoltare. Io in queste situazioni per esempio memorizzo massimo un paio di nomi e mi ricordo vagamente quello che succede.

Quindi l'attività che abbiamo pensato per oggi è un giro di tavolo un po' diverso, ossia un giro di tavolo che usa la metafora del passarsi la palla come scusa per poter raccontare non soltanto chi siamo, ma anche come possiamo cercare di applicare, e come i partecipanti hanno applicato, TBR al loro contesto.

E allora iniziamo: io passerei la palla ad Anna.

Anna: ciao a tutti, sono Anna Lombardi, lavoro in Essere Agile. Ho partecipato alla prima edizione in presenza a Milano (ottobre 2023), e ho applicato sin da subito il metodo, e forse da un punto di vista ne ho anche abusato.

Durante i nostri workshop, abbiamo cercato di ricostruire tutte le attività da zero, utilizzando, applicando e provando tutti i metodi e tutti gli strumenti a nostra disposizione. Abbiamo interamente ricostruito un workshop di una giornata e le reazioni delle persone che hanno partecipato sono state totalmente diverse: abbiamo chiesto un feedback a persone che avevano partecipato anche alla versione precedente (pre-TBR), e la reazione è stata impressionante: nella versione post-TBR le persone si sentivano molto più partecipi e molto più coinvolte. Quindi da questo punto di vista il feedback è stato estremamente positivo.

Passo la palla a Cristina.

Cristina: ciao, sono Cristina De Toni, lavoro in DAB Pumps, mi occupo di gestione del cambiamento e progetti di trasformazione. Ho partecipato alla seconda edizione quest'anno a Milano insieme a Giada, Valentina, Giacomo e ovviamente Marco.

Per me TBR è stata una rivoluzione, anch'io forse ne sto abusando perché lo uso anche nelle riunioni e nelle comunicazioni con le persone. Il concetto chiave per me è quello di comunicare attraverso qualcosa che sia fuori dagli schemi, perché è un modo con cui le cose ti rimangono di più.
L’ho applicato su un'attività di coaching virtuale, su Teams, con persone da vari posti nel mondo, proprio per spiegare quelli che sono i concetti del cambiamento, e ho usato un po' tutte le tecniche, a prescindere dalla struttura, quindi le famose 4c: connection, concepts, concrete practice e conclusions.

Ho applicato anche le altre tecniche, quindi ho iniziato per esempio con suggestion for success, che è una cosa che viene consigliata: spiegare le regole e le non regole del gioco, è stata una cosa che ha colpito i partecipanti, così come il right to pass, cioè la possibilità di non essere lì, di non essere in quei training, quindi responsabilizzare ciascuno nell’essere lì perché lo si vuole, mentre a volte siamo un po’ incatenati alla sedia, al dover apprendere o partecipare per forza.

Altre tecniche che mi sono tornate molto utili sono il pair share, pass the ball, come quello che stiamo facendo ora… è stato molto apprezzato anche l’utilizzo dei meme per spiegare alcuni concetti di change management, e anche questo è TBR: utilizzare i meme! Penso che sia rimasto molto di quanto abbiamo fatto e le persone interagivano molto.

Passo la palla a… Giacomo!

Giacomo: sono Giacomo De Luca, dell’Università San Raffaele di Milano, ho avuto voglia di applicare subito TBR ai miei corsi universitari, quindi ho iniziato senza preavviso, da una lezione all'altra, a cambiare un po' il modo in cui facevo le mie lezioni. Ho iniziato a utilizzare elementi di TBR pian piano, sperimentando, per vedere quale fosse la mia reazione e quella delle persone che avevo davanti. Ho quindi iniziato ad applicare alcuni di quegli strumenti che abbiamo dalla cassetta degli attrezzi di cui si parlava e inserirli in corsi di laurea in medicina e infermieristica, e ho iniziato a inserire queste novità in corsi più piccoli come numero di studenti, per poi portarli a corsi più frequentati.

Alcuni degli strumenti usati hanno funzionato molto bene, come provare a costruire dei giochi di società per risolvere casi clinici in ambito medico (è stato un lavoro lungo ma molto entusiasmante), che è poi quello che facciamo nel nostro lavoro.

Le reazioni da parte di studentesse e studenti sono state entusiastiche: così come per me TBR ha rappresentato una rivoluzione concettuale, così è stato per loro partecipare attivamente e per la prima volta a una lezione concepita e svolta in questo modo. E anche la mia reazione è stata positiva: mi sono divertito e per cui ho provato con mano che è qualcosa che può davvero funzionare. Esperienza super positiva.

Passo la palla a Valentina.

Valentina: ciao, sono Valentina Vantaggiato, lavoro nel dipartimento formazione e sviluppo di NTT Data Italia. Anche io ho partecipato alla seconda edizione di aprile 2024: esperienza fantastica e rivoluzionaria, mi ha introdotto in un contesto a me completamente nuovo con concetti che ho deciso di applicare insieme a Giada, dato che siamo colleghe, concetti che ho applicato fin da subito nei workshop o attività di team building che facciamo in azienda.

Mi piacerebbe raccontare come abbiamo applicato TBR di recente: un workshop rivolto a 14 ragazzi e ragazze di 15 anni che sono venuti in azienda per fare una sorta di campus estivo. Inoltre si è trattato anche del primo workshop organizzato da me e Giada in completa autonomia e senza la guida di altre persone più senior in azienda.

L’ambizione era quella di far trascorrere una giornata diversa dal solito a queste persone e mantenere comunque attiva la partecipazione. Per cui cosa abbiamo fatto? Abbiamo cercato di progettare un workshop che si ispirasse a TBR e a una serie di attività di TBR, oltre che da LEGO®, e questo mix ha avuto risultati entusiasmanti.
Per sciogliere il ghiaccio abbiamo optato per un’attività diversa dal solito ice-breaker, per cui grazie allo shout out abbiamo chiesto ai ragazzi che cosa si aspettassero dalla mattinata. Qualcuno ha parlato di serietà, che poi è stata l'unica cosa non presente durante tutta la giornata. Abbiamo usato il ticket out per avere dei feedback e quindi capire anche noi come stavamo andando con le nostre attività. Durante tutta la giornata ci sono stati molti momenti incentrati sul movimento, sul disegno, sulla musica, e abbiamo sempre usato un timer, anche per dare un senso di urgenza e dare delle regole.

Inoltre abbiamo usato il disegno per far sì che raccontassero meglio le storie sui modelli che avevano creato, con tanto di gallery walk, dot voting con i mattoncini LEGO® per vedere chi avesse vinto, concludendo la giornata con il polpo, la mascotte della giornata, grazie al quale abbiamo fatto il ball toss (come ora, nel giro di presentazioni), e che abbiamo usato anche come antistress durante le varie attività.

Possiamo dire che risultato è stato soddisfacente, siamo state felicissime di aver applicato questo metodo. I ragazzi ci hanno chiesto se saremmo tornate il giorno dopo, ma purtroppo non abbiamo potuto gestire la seconda giornata di workshop... siamo rimaste comunque molto contente.

Passo la palla a Giada.

Giada: … e uso il nostro polpo come palla! Ciao, sono Giada Trovato, anch'io lavoro nel team di formazione e sviluppo di NTT Data Italia.

Abbiamo utilizzato TBR subito dopo il corso con Marco. Io l'ho utilizzato da sola con una collega che in realtà non fa parte del team formazione e sviluppo, quindi anche lei è stata un po' contagiata da TBR, e l’abbiamo usato a Napoli con un gruppo di 20 ragazzi, ancora una volta di 15 anni, che stavano facendo una Summer School con noi.

Anche noi abbiamo iniziato con uno shout out e in questa fase avevano identificato tra le varie aspettative anche la noia. Quindi io ero già in panico perché ero arrivata a Napoli due ore prima, mi avevano perso la valigia con tutto il materiale all'interno… ho chiamato subito Valentina e con la nostra responsabile ci siamo messe a ripianificare tutto il workshop... arrivo e loro mi dicono “mi aspetto di annoiarmi” e mi sono detta “ok, cominciamo bene!”.

Abbiamo rivisto un po' tutto, utilizzando diverse tecniche che fanno parte della metodologia TBR, come il pair share,e soprattutto li abbiamo fatti lavorare utilizzando la creatività: permettendo loro di utilizzare post-it, pennarelli, forbici, dandogli davvero spazio per poter creare qualcosa che fosse attinente alle tematiche che stavamo affrontando e dando loro la possibilità di capire qual era la loro strada per poter apprendere nella maniera corretta.

C’è chi ha elaborato dei disegni, chi una massa di post-it, chi ha fatto anche delle rappresentazioni 3D… tantissima creatività da parte di questi ragazzi. Abbiamo fatto ovviamente anche una gallery walk, indispensabile per poter ammirare tutto il nostro lavoro.
Nella parte finale, di key takeaways, abbiamo tutti unanimemente cancellato la noia (che era una delle aspettative espresse all’inizio, ndr), quindi a distanza di 8 ore dall'inizio questa è stata completamente rimossa.

C’è una cosa che voglio dire, perché credo che sia proprio il vero valore di TBR, qualcosa che i ragazzi hanno capito ed espresso in pieno, ossia: l'insegnamento con questa metodologia è un insegnamento davvero innovativo, e ci tengo a trasmetterlo come messaggio perché mi è rimasto dentro, e così è stato anche per la mia collega ed è bello condividerlo con tutti voi.

Avanscoperta: grazie a tutte e tutti per l’intro, c’è tantissimo di cui parlare.

Marco: ascoltando un po’ il giro, a me viene da aggiungere che alla fine, e anche grazie a quanto hanno detto tutti fin qui, non è un corso di rocket science o di magia.
TBR in realtà è un corso di cose abbastanza semplici. Sembra più un corso di cucina, dove a parte alcuni ingredienti o alcune tecniche che magari alcuni chef super stellati ti posso insegnare… alla fine si tratta pur sempre di uova, farina, impastare e mettere le cose in forno.
Solo che da una parte secondo me ti dà un po' la consapevolezza di quello che stai facendo, e quindi in realtà è come in cucina, dove a un certo punto dici “per lievitare deve funzionare in questo modo qui”, e dall'altra ti dà anche il coraggio di farlo, e ne ho avuto testimonianza anche ascoltando un po' il giro di tavolo appena fatto. TBR ti dà il coraggio di dire “adesso facciamo questo esercizio”, che sembra una cosa banale, ma poi in qualche modo ti fai coraggio.

Mi ha colpito ciò che ha detto Giacomo: alla fine vale anche come sperimentazione per te e su di te come docente. Ti fai coraggio e dici “mi han detto che questa roba funziona, ci provo, esperimento se funziona per davvero”, e in questo senso è un corso sperimentale come un corso di cucina. Una volta fatto TBR puoi dire “questa cosa per me funziona molto bene, quest’altra cosa per me invece non funziona, non la voglio più fare così, o la voglio ibridare”, un po' come abbiamo sentito poco fa nel giro di presentazioni.
L’ibridazione può avvenire anche con qualcosa che abbiamo studiato e che sappiano essere al di fuori di TBR. O ancora, possiamo voler riprogettare tutto con le nuove nozioni apprese grazie a TBR.

La cosa che vorrei raccontare di TBR è che non si tratta di un corso nel quale hai l'illuminazione gigantesca: fai un po' di ordine nella tua cassetta degli attrezzi, cominci a dare i nomi alle cose, cominci a capire perché alcuni di questi possono essere interessanti.
Quindi in questo senso secondo me è un corso che ti cambia la vita. Per me è stato così divertente farlo da partecipante che addirittura ho voluto diventare un docente certificante. Lo vivo con estremo entusiasmo ogni volta che ho l'occasione di poterlo rifare.

Avanscoperta: ottimi spunti, grazie a tutte e tutti. Vorrei dare la parola a Cristina che ha un appunto su una delle cose più importanti emerse prima, ed è il discorso sulla noia. Il nome stesso, Training from the BACK of the Room, tende un po' a voler rovesciare l'approccio classico che tutti abbiamo esperito, o in più casi subito, ossia di una persona davanti a te che parla all’infinito… che è un po’ l’esperienza della scuola, e non solo.
Uno dei punti che è stato emesso prima è proprio quello relativo alla noia: l'insegnamento a volte viene percepito una cosa noiosa o comunque dove chi dovrebbe apprendere ha un ruolo molto passivo, e quindi tutto viene percepito come noioso. Vai Cristina.

Cristina: volevo dire che anche a me TBR ha aperto un mondo. Qualche settimana fa ho scritto un messaggio a Marco dicendogli che non riesco più a seguire i training normali, quelli che non vengono strutturati con TBR, perché sono troppo noiosi… dopo TBR ho fatto altre cose, ho preso altre certificazioni ma… adesso faccio veramente fatica. Appena vedo qualcosa, penso subito a come si sarebbe potuto fare diversamente con TBR.

Marco: il senso del messaggio era “Marco ti odio: dopo TBR non riesco più a frequentare altri corsi”.

Enrico: vorrei passare un altro tema. Un aspetto interessante, che si ricollega a quanto detto da Giacomo e poi da Marco, è quello sul vincere questa sfida anche con se stessi.
Essendo così abituati a percepire o appunto avere esperienza dell'insegnamento in un certo modo, il fatto di buttarsi e provare a fare delle cose diverse ed entrare in una mentalità per cui si prova davvero a ragionare e fare le cose in modo diverso, a prescindere dall’ambito, è qualcosa di molto interessante e che vorrei esplorare con voi.

Per cui vorrei capire se, e queste sono parole chiave delle nostre dirette, quando affrontiamo argomenti che vogliono rivoluzionare il modo in cui le cose sono state fatte fino a quel momento… c’è scetticismo, c’è resistenza verso TBR? Come possiamo vincerla sia, diciamo, con noi stessi, abituati a fare le cose in un certo modo, anche se qui abbiamo persone che hanno già scelto di voler cambiare, che con gli altri?
Quindi chiedo: come avete vinto le vostre resistenze, se c’erano, e quelle degli altri, nel momento in cui avete iniziato a fare le cose seguendo quanto dice TBR?

Iniziamo da Valentina.

Valentina: ho una cosa da raccontare in merito. Nessuno scetticismo da parte mia, mi sono totalmente innamorata del corso, ma scetticismo da parte degli altri ce n’è stato un po', e anche un po' inaspettato.

Subito dopo il corso lo abbiamo applicato a un team building interno, quindi con quelli dell'azienda, peraltro tutte persone molto giovani, certamente generazione Z, quindi immaginavo interessate a una modalità un po' più interattiva e innovativa di gestire un workshop… e niente, quando ho detto che si sarebbero potuti alzare in autonomia durante tutto il workshop per prendere il materiale, camminare, fare una pausa, ecc., mi hanno guardata male. Ci sono rimasta malissimo. Ho fatto un gran respiro, e ho detto “ragazzi, sappiate che comunque il movimento serve per favorire l’ossigenazione del vostro cervello, noi non vi porteremo niente al tavolo, i materiali sono lì”. Poi alla fine hanno superato le resistenze e si sono anche divertiti.
Ma ammetto che all'inizio ci sono un po' rimasta male, soprattutto perché non erano persone grandi, abituate al solito modo di fare le cose.

Palla a Giacomo.

Giacomo: scetticismo da parte mia no: ha prevalso nettamente la voglia di sperimentare. Forse un po’ di scetticismo, ma forse più che altro inibizione, figlia di quella mentalità per cui bisogna stare composti, al proprio posto, le cose vanno fatte bene, e per cui alcune cose non si devono assolutamente fare… bene, questo scetticismo non l'ho trovato neanche da parte di studentesse e studenti che anzi hanno accolto l’esperimento con grandissimo entusiasmo fin da subito tranne una fisiologica fase di assestamento iniziale, in cui magari hanno pensato “oddio, cosa devo disegnare qua, non so disegnare”, una breve fase di imbarazzo durata davvero pochissimo.

Però anche quella secondo me, più che altro, e parlo del mio contesto, quello universitario, è solo un blocco iniziale che è dovuto alla mentalità per cui dobbiamo stare buoni, composti e ascoltare chi parla senza dare fastidio. Ho riscontrato molto più scetticismo a livelli un po' più alti che non da parte di studentesse e studenti.

Passo la palla a Cristina.

Cristina: Anche io assolutamente non scettica: per me TBR è stata una vera svolta. Sicuramente è più sfidante nella preparazione dei materiali e dei contenuti perché richiede più energia mentale nel momento in cui devi cambiare: si tratta di organizzare qualcosa che permetta alle persone di apprendere in un determinato modo con delle tecniche che loro devono applicare, e richiede sicuramente più creatività nel trovare dei contenuti, che possono essere anche visivi, e che devono essere accattivanti anche come attività da proporre. Nel mio caso era un workshop virtuale e devo dire che mi sono un po' appoggiata all’intelligenza artificiale.
Un'altra cosa importante riguarda la gestione dei tempi, ci ho dovuto lavorare parecchio perché soprattutto da remoto è fondamentale.

I partecipanti invece sono stati un po’ scettici, soprattutto quelle persone che sono abituate da anni a un approccio passivo, un po' come dicevamo prima sullo star seduti, ascoltare, annuire e non disturbare.
Ma già nella fase di connection, che come ha detto Marco anche nel corso è quella più importante, ho visto che si sono messi in gioco.
Il tema era il cambiamento, per cui mettersi in gioco era anche richiesto, e certamente ha aiutato molto iniziare a entrare in connessione con gli altri partecipanti e con l’argomento, attraverso attività che non li hanno portati troppo fuori dalla loro comfort zone.
Poi quando ho chiesto di disegnare qualcosa, ho visto anche nel mio caso un bel po’ di occhi sgranati.

Alla fine quello che mi è piaciuto molto è che erano tutti veramente molto coinvolti entusiasti e la persona più scettica, sia prima che durante, è stata quella che a un certo punto ha tirato fuori un maialino, come un salvadanaio, per spiegare un concetto, e lì è stato bello perché ho visto proprio un cambio di prospettiva.

Passo la palla ad Anna.

Anna: scetticismo da parte mia no, perché ho voluto fare il corso e avevo già letto di cosa si trattava. Arrivata al corso, ho avuto l'illuminazione: per come sono io, ed è una cosa che è trapelata prima, il lavoro del trainer, quando te ne devi occupare tu, è molto sulla parte di costruzione del workshop; mentre quando arrivi al workshop TBR da partecipante ti rendi conto che sono i partecipanti a diventare parte attiva, il focus naturalmente è su di loro. Le persone che partecipano diventano la parte attiva, quindi il riflettore cade su di loro.
E questa è stata un’illuminazione perché non sono la classica persona a cui piace stare davanti a una cattedra con molte persone che mi osservano, mi mette un po' in difficoltà, e poi soprattutto quando si distraggono.

Per quanto riguarda i vari partecipanti, noi quest'anno abbiamo un calendario fitto di workshop all'interno di un nostro cliente, una grande realtà, e stiamo proponendo dei workshop di agile awareness, perché ci occupiamo di consulenza organizzativa. Questi workshop li abbiamo tutti costruiti utilizzando TBR e all’inizio persone un po' più adulte, con un background di lunga data e abituate ai classici corsi frontali arrivavano in aula eleganti, aprivano il loro pc, si sedevano… e a fine giornata gli sembrava di aver giocato tutto il tempo.
Quindi avevano questa reazione un attimo scioccante. Poi i nostri corsi sono di due giorni, e quindi a fine del primo giorno erano tutti abbastanza sconvolti.
Il secondo giorno, dopo averci dormito sopra e aver metabolizzato, quanto accaduto, le attività andavano alla grande. Ma come diceva qualcuno - first reaction SHOCK!

Passo la parola a Giada.

Giada: scetticismo da parte mia, no: appena finito il corso con Marco ero ancora più convinta, ma nei ragazzi sì, come abbiamo detto prima. Loro si aspettavano la noia. Infatti quando abbiamo fatto vedere qualche slide li vedevo anche un po' più nella loro comfort zone: stare seduti a guardare uno schermo.

Invece quando ho detto “adesso prendete il materiale, si trova lì, dovete usare le forbici, non fatevi male ma create e divertitevi”... lì effettivamente ho visto l’effetto shock, e il bello è che poi dicono “effettivamente ho imparato qualcosa, e non perché me l’hai spiegato tu, ma perché l’ho messo in pratica”, e secondo me è questa la cosa bella di TBR.

Avanscoperta: bellissime storie di persone conquistate da TBR dopo uno scetticismo iniziale. Marco, qualche riflessione di chiusura di questo argomento?

Marco: secondo me il tema è proprio questo, ed è un po’ trapelato trapelato da alcune delle parole che abbiamo sentito…  c'è una cosa che io racconto scherzando, e che poi loro hanno anche un po' ripreso, ossia: il bello di fare TBR è che ti accorgi che poi il tuo ruolo di docente è che non devi fare niente.

Si passa dal fatto che le persone si arrangiano a costruirsi loro materiali, cerchi di creare la dinamica dove le persone si possono raccontare le cose… ma soprattutto è proprio lo scoprire che se la progettazione è fatta bene, e con progettazione non mi riferisco ai paletti e alle cose da fare, ma intendo un'attenzione molto forte sul ricordarti che di fronte a te hai persone, e che queste persone hanno un desiderio molto forte di raccontarsi delle cose, hanno un bagaglio di esperienze, hanno degli obiettivi per il futuro, hanno delle cose che conoscono già, e ci sono delle cose invece che conoscono...

il tuo ruolo sostanzialmente è quello di favorire quella sicurezza psicologica, quella dinamica giocosa, quell'ambiente che io chiamo proprio “la classe”, perché è quello che di cui parliamo, in cui le persone possono sostanzialmente sentirsi libere di raccontare le cose, sentirsi anche però incastonate in modo positivo in un meccanismo per cui il raccontarti le cose non deraglia in un brainstorming organizzato malissimo.

In questo tipo di dinamica, il tuo compito di docente, ma intendiamo la parola docente in modo sovraesteso, per cui il tuo ruolo di facilitatore o agevolatore dei processi di conoscenza, diventa sostanzialmente quello di creare questo tipo di ambiente e soprattutto di trasmettere alle persone il fatto che in questo tipo di ambiente ci possono sguazzare dentro molto bene.

Per cui ci sta che all'inizio le persone lo trovino in un po' strano, anche se questo ci fa un po' pensare e riflettere, perché in realtà lavoriamo tutti in contesti dove è importante poter trasmettere la conoscenza, poterla in qualche maniera a far girare e impastare con quella degli altri, ma tutti poi in qualche modo ci incastoniamo di più in un meccanismo dove preferiamo che ci venga detto esattamente cosa dobbiamo fare, come lo dobbiamo fare e, addirittura aggiungo, cosa dovremmo imparare.

Questa è la cosa che TBR ti aiuta un po’ a svelare, ovvero: come docente, ai corsi non posso sempre pretendere di sapere anche che cosa le persone dovranno imparare. Può essere che io arrivi in aula e in qualche maniera durante il corso scopra che tutto ciò che immaginavo di dover raccontare, insegnare, trasmettere, e per cui avevo preparato quantità enormi di slide, in realtà le persone lo sanno già.

Il mio compito invece è di rendere visibile le cose che non sanno e di permettere loro di creare discussione attorno a queste. Addirittura, e lo porto all'estremo, accade che anche lei o lui in quanto docente diventino parte del gruppo di quelli che non sanno di cosa stiamo parlando, e in qualche modo “creo la classe” e dentro alla classe comincio a costruire il percorso di conoscenza di ciò che non so.

Quindi sostanzialmente TBR è un po' una cassetta degli attrezzi che ti aiuta anche a ricordarti di questo: ti aiuta a fare una progettazione fatta bene prima, e ti permette poi in aula di tirare un bel respiro e a concedere alle persone il tempo per poter stare assieme per bene.

Vi ringrazio per il giro di tavolo perché mi ha ricordato un'altra volta perché mi piace tantissimo fare TBR.

Avanscoperta: grazie mille, l’entusiasmo è lampante nelle parole di tutte e tutti, quindi è sicuramente molto motivante sentire le storie di applicazioni così diverse di TBR.

Stiamo vedendo come ciascuno e ciascuna lo può usare in vari ambiti e banalmente, come abbiamo detto all'inizio, quasi nessuno dei presenti è docente in modo formale, quindi è la dimostrazione che veramente si può applicare in tantissimi casi.

Alla luce di tutto quello che ci siamo detti, qual è l’aspetto e la cosa che preferisci di TBR?

Una persona che ora sta guardando questa diretta o che sta leggendo questo articolo, si chiede: “quindi qual è grande la cosa più potente, più bella, o che preferisci? Quella dove hai trovato più valore aggiunto?”. Iniziamo da Giacomo.

Giacomo: il vantaggio più grande, ciò che mi ha fatto dire “wow!” e che davvero mi aspettavo di ricevere da TBR, è in termini di condivisione delle conoscenze in quello che è il mio ambito, ossia universitario/medico: fare in modo che quelle conoscenze vengano realmente acquisite e mantenute, così che quella sia una formazione davvero efficace.

Cosa che ho avuto modo di toccare con mano quando ho provato a utilizzare TBR nei miei corsi. Esempio banalissimo: è il terzo anno di seguito che faccio un corso su fisiopatologia, ossia come funzionano gli organi. Posso star lì a preparare slide e spiegare come funziona il cuore, cosa che ho fatto in passato. Quest'anno, alla fine di una di queste lezioni, in cui ho chiesto alle persone presenti di provare a disegnare i gruppi di 4-6 come funziona il cuore, chiedendo semplicemente, con cartellone e pennarelli, di disegnare come funziona il cuore, "raccontatevelo tra voi, e poi raccontatelo a noi" - ebbene, molti di loro a fine corso mi han detto “ora ho capito come funziona il cuore, non lo dimenticherò più”. E questo è un aspetto che mi è piaciuto tantissimo.

Un’altra cosa che mi preme dire è ora grazie a TBR posso far lezione ascoltando ogni tanto un po' di musica, che è uno degli aspetti che preferisco perché aiuta tantissimo a creare quella sicurezza psicologica di cui parlava Marco, a creare la classe e l'ambiente gusto, e a generare sicurezza psicologica nel comunicare le emozioni e facilitare l'apprendimento. E mi piace tantissimo preferisco perché posso dedicarmi, anche se poco tempo e per pochi minuti, ossia il tempo di una canzone, all’ascolto della mia canzone preferita. È qualcosa che sto amando.

Passo la palla a Giada.

Giada: io ho fatto anche una rappresentazione grafica, mi piacciono molto i LEGO®, quindi per farvi capire qual è l'aspetto che preferisco vi faccio vedere quello che succede a TBR, cioè non ci sono lezioni frontali, siamo tutti insieme, tutti che condividiamo, ci si divide in gruppi e si fa pair share.
Quello che mi piace è proprio la connessione con le persone: la metodologia TBR non solo permette un migliore apprendimento delle tematiche, ma anche la connessione con le persone. Solitamente andiamo ai corsi classici, ci mettiamo su una sedia, le persone sono tutte rivolte verso il palco, ci sono delle slide e al massimo parliamo o con quello che ci sta a destra con quello che ci sta a sinistra…

Invece con TBR hai la possibilità di connetterti con tutte le persone e conoscere tutti quanti, quindi questo è l'aspetto che mi piace di più perché sono una persona a cui piace molto socializzare.

Passo la palla ad Anna.

Anna: per quanto mi riguarda, gli aspetti che preferisco sono due: il toccar con mano e quello che ho sottolineato prima, che per me è importantissimo, ossia passare il testimone e la leadership del corso al partecipante. Sono due cose fondamentalmente collegate, perché alla fine se tu gli passi la responsabilità facendogli toccare con mano quello che gli sta insegnando, loro arrivano alla fine del corso che portano a casa qualcosa, quindi la soddisfazione è diversa rispetto all'approccio classico.

E come già diceva Giada prima, a me piace tantissimo osservare, quindi sentirli parlare, vedere le dinamiche che si creano anche cambiando gruppi, cambiando coppie, farli interfacciare tra loro… è una fonte di ricchezza estrema.

Passo la palla a  Valentina.

Valentina: l'aspetto che mi piace di più è che acquisire conoscenze o apprendere qualcosa attraverso questa metodologia rappresenta un apprendimento che passa da un’esperienza, attraverso un qualcosa che diventa poi un ricordo e che rimane dentro di te quasi per sempre, certamente per tanto tempo. E soprattutto il fatto che permette comunque di rendere i partecipanti, come diceva Anna, delle persone attive nell'apprendimento: il fatto di mettere in pratica attivamente quello che stai imparando durante la lezione o il workshop te lo farà ricordare molto meglio.

Non lo dico per sponsorizzare, anche se poi stiamo raccontando il metodo, però anche io ho partecipato a tanti corsi e riunioni, e non c’è paragone tra quanto mi sia rimasto impresso il corso di TBR rispetto a quelli passati. TBR vince nettamente: io mi ricordo davvero tutto, già dal primo momento del priming, in cui abbiamo dovuto studiare prima di iniziare il corso, e parliamo di leggere alcune slide e memorizzare alcuni concetti… ancora oggi me lo ricordo, questo è il risultato ed è fantastico.

Passo la palla a Cristina.

Cristina: io per “l'aspetto che preferisco di TBR” vorrei citare un feedback spontaneo che mi ha dato un partecipante del mio corso, e me l’ha detto il giorno dopo, quindi significa che anche lui ci ha pensato su e ci ha dormito sopra. Mi ha detto: “il corso è stato energizzante ed è stato curioso vedere come dal primo all'ultimo esercizio ci si è scoperti sempre di più”.
Secondo me ha sottolineato due cose fondamentali che ho vissuto anch'io quando ho fatto il corso con Marco, che sono appunto: l'energia, perché è veramente un rilascio di energia attraverso le connessioni con le altre persone, e di energia personale nell'apprendere; e poi la scoperta, perché appunto facendo insieme agli altri si scoprono gli altri e quindi le esperienze degli altri, nuove prospettive, nuovi approccio, ma si scopre anche se stessi. Si scoprono le proprie abilità e come magari le proprie esperienze hanno già toccato i contenuti del corso, e quindi ci si connette un po' di più anche su cose che magari si conoscono già ma si portano la luce nel gruppo.

Diciamo che queste sono le due parole che possono descrivere gli aspetti che preferisco di TBR - energia e scoperta.

Avanscoperta: avete usato elementi o spunti da TBR in modo diciamo camuffato anche nella vita, quindi TBR non solo a lavoro. C’è stato qualche momento in cui qualcosa che avete imparato o visto vi è stato d'ispirazione per altro?

Marco: per me la parte la parte di TBR, che poi in realtà mi diverte di più nella vita di tutti i giorni, è ricordarmi che mi interessano molto le altre persone, e questo non viene da TBR, anzi, è più travaso della vita di tutti i giorni dentro TBR, ma siccome poi il corso lo tengo io, un po’ spero che questo sia il sapore della mia classe di TBR, del corso che faccio.

Magari gli altri docenti in giro per il mondo ci mettono le loro spezie, ma la mia cucina ha quella spezia lì. E la mia spezia è che a me interessano le persone, proprio mi incuriosiscono, e quindi succede che tu sei in classe con me, dobbiamo magari parlare di una cosa anche molto tecnica, o siamo in una riunione e dobbiamo parlare di una cosa che magari è anche complessa o complicata, c'è qualcosa dentro che non è così facile da svelare o raccontarsi, però a me interessa. Mi interessi tu seduto o seduta lì con me, mi interessano le cose che sai, mi interessa quello che non sai, mi interessa il modo in cui ti muovi, il modo in cui sorridi, il tuo colore preferito nel sceglierti il pennarello, i post-it e i fogli che useremo…
E questa cosa in realtà a me piace molto, mi piace infilarla dentro a TBR, e TBR mi dà modo di poterla in qualche maniera esplodere sempre tanto.

Quindi questo è il mio aspetto preferito del fare docente di TBR, il corso per me ha quel sapore lì ed è quello che porto anche fuori. Questo mi ricorda che il fatto che le persone mi interessano può essere un potenziale, a me interessa tanto quello che devi raccontare. “Eh, ma servirà un'ora per farlo”. Va bene: facciamo connection una mattina intera. “Il corso per me è interessante se si può entrare in connessione con te”. Ok: se questa roba richiede 6 o 8 di corso, ci metteremo 6 o 8 ore.

Per cui mi gioco questa cosa di TBR anche in ambienti che non sono quelli di TBR avendo meno l'ansia da prestazione rispetto alla quantità di cose che devo mettere nel racconto, e potendomi concedere di ricordarmi che invece è la quantità di entusiasmo nella connessione umana, e a me piace quindi mettere tanto di quella roba lì nella negli incontri che faccio, per me ha un valore.

Giacomo: ho utilizzato TBR in due modi nella vita privata: il primo è che mi sento di avere più fiducia nelle persone, perché portare TBR in un’aula universitaria significa innanzitutto fidarsi di TBR e fidarsi delle persone, e sperare che le persone si fidano di te. Vedere che io posso fidarmi delle persone e che le persone si fidano di me è una cosa che mi dà molta fiducia, ed è una grossa influenza nella vita privata.
Il secondo modo invece è che mi ha insegnato a giudicarmi un pochino di meno. Questo è un altro aspetto che secondo me nasce anche da esperienze come questa in quanto partecipante, che poi quando le ho portate in ambito lavorativo, ed è bello vedere come dall'ambito lavorativo tutto ciò si leghi alla vita di tutti i giorni quasi spontaneamente.

Cristina: anche io vorrei raccontare due cose.
La prima riguarda proprio il metodo TBR, che mi hai influenzata nel senso di mettersi at the back of the room, ossia far parlare prima gli altri, sentire prima quali sono i contenuti, i punti di vista che le persone preferiscono esplorare, e questo in generale, anche con i miei amici…

E la seconda è un aneddoto: mio nipote ha 10 anni e ora le prove INVALSI, ero con lui a fare una prova che riguardava la comprensione del testo, ma lui non è troppo portato per l’italiano… sbuffava e si lamentava. Però alla fine abbiamo letto il testo insieme e gli ho detto: “proviamo a metterlo in scena, Francesco, e vediamo cosa succede”. E quindi forse, non so se sono stata influenzata da TBR, però l'ho fatto mettere al centro, cioè ho fatto sì che lui si mettesse in gioco proprio nella comprensione,  nel mettere in scena quel che aveva appena letto, nel provarlo come se fosse un attore di quel testo. Devo dire che continuavo a ridere mentre lo facevamo… e poi ha risposto giusto alle domande!

Giada: vorrei collegarmi a quello che diceva Giacomo sulla fiducia rivolta verso le persone. In realtà quello che è capitato a me è più sulla fiducia verso me stessa. Nel senso che fidandoti del metodo ti permetti anche di dire “ok, accettiamo che abbiamo dei limiti, accettiamo per esempio che tutti quanti ci distraiamo e ci annoiamo”, e quindi era anche un po' il mio timore quando sono andata in alla prima volta su come gestire il fatto che le persone che avevo davanti si sarebbero distratte.

Ricordo che ne avevo parlato anche con Marco al corso: l’importanza di trovare sempre dei metodi diversi, non li puoi pensare sul momento, vanno progettati. Poi ho visto che effettivamente attraverso il metodo, attraverso varie tecniche, le persone vengono coinvolte nuovamente, anche quando si distraggono, e se si distraggono, perché poi usando TBR non ho notato nemmeno troppe distrazioni, le puoi recuperare. Quindi mi ha dato grande fiducia in me stessa perché avevo un po’ paura di non riuscire a tenere sotto controllo l'aula e invece ci sono riuscita alla grande. Quindi devo dire che è questa la cosa di TBR che mi ha influenzato maggiormente.

Anna: per quanto mi riguarda invece si tratta di semplicità e del semplificare le cose, perché alla fine anche nella nostra vita quotidiana siamo sempre pieni di costrutti, anche mentali.
Io per esempio all'università avevo questa cosa che se l'esercizio era troppo facile lo sbagliavo perché dovevo complicarlo altrimenti era troppo semplice. Avevo un po’ questa ossessione per cui se qualcosa era troppo semplice volevo trovare l'inghippo. Invece TBR ti insegna che la semplicità esiste e che le cose a volte sono semplici, oppure semplificarle è la cosa migliore. Per cui il messaggio di TBR, se dovessi riassumerlo in una parola, sarebbe semplicità.

Valentina: chiudo io. TBR mi ha trasmesso tanta energia, come diceva prima Cristina, e tanta voglia di rimettermi in gioco. Non pensavo che potesse esistere una metodologia di questo tipo e averla scoperta mi ha dato l’idea di potermi rimettere in gioco per sperimentare, scoprire delle cose nuove e sperimentarle soprattutto con gli altri.

Avanscoperta: grazie mille a tutti e tutte. Aggiungo una considerazione lato mio perché anche se non ho fatto TBR come partecipante assisto insegnanti e studenti nel percorso formativo lato logistica e organizzazione, e una delle cose che mi porto a casa di TBR, dopo averlo visto diverse volte, sia applicato che insegnato, è il non dare mai le cose per scontate, quindi il momento di connessione che si crea inizialmente lo trovo veramente utile perché aiuta un po' tutti quante le persone presenti ad abbassare la guardia e fare quel minimo di sospensione del giudizio, che ho sentito anche nelle vostre riflessioni, e ci diciamo “oggi ci accettiamo per il fatto che non so tutto, e questo va benissimo, posso imparare insieme agli altri, non devo sempre avere ragione”. Sono tutta una serie di fissazioni, come diceva Anna, che ci imponiamo e che pensiamo sia giusto avere, ma che invece non servono a nulla fondamentalmente.

Il non dare le cose per scontate è uno degli aspetti che preferisco di TBR e di conseguenza questo aumenta la curiosità sia verso gli altri che verso l’argomento di cui si parla, di cui magari pensi di sapere già tutto e non è vero, quindi aiuta un po' smontare tutta una serie di idee che si hanno sull'insegnamento e non solo, anche sugli argomenti stessi.

Grazie mille a tutte e tutti, ci vediamo con il prossimo appuntamento tema TBR con altri alumni.

Cover photo: Foto di Agence Olloweb su Unsplash

Panel Training from the BACK of the Room - Esperimenti ed esperienze: qui il video e il podcast.

Learn with Marco Dussin

Marco è trainer del Training from the BACK of the Room (versione in presenza e in italiano).

Vuoi continuare a leggere le cose che pubblichiamo? Iscriviti alla nostra Newsletter 📩 (disponibile in italiano e in inglese).
Ti faremo compagnia ogni venerdì mattina. ☕️

La lista completa dei nostri corsi: Avanscoperta Workshops.

Abbiamo fatto una scommessa.

Cosa fare se Giulia Tosato del GrUSP ci fa una proposta "indecente"? :)

La proposta: progettare una lineup di workshop il giorno prima della conferenza Product Management Day.

Dopo un paio di iterazioni con Giulia sul formato, sui temi, sulla durata, sui rischi, sui possibili scenari di vendita, e dopo alcune valutazioni e modifiche, abbiamo lanciato questa scommessa: una giornata di workshop, con 5 titoli complessivi, 3 sessioni in parallelo al mattino e 3 in parallelo al pomeriggio.
Una giornata formativa dedicata alle persone attive - interessate, appassionate, curiose, impiegate - nel mondo Product Management.

Grazie alla disponibilità di cinque esperti, già nostri docenti o collaboratori, abbiamo costruito una giornata di attività pratiche su temi imprescindibili quando si parla di Product.

Product Management Day - Workshop è un'occasione unica per approfondire insieme a Francesco Fullone, Hoang Huynh, Ivano Masiero, Jacopo Romei e Luca Sartoni, le competenze necessarie in tutte le fasi del product's lifecycle: dallo sviluppo dell'idea fino al posizionamento, con uno sguardo sul prodotto, sui consumatori, sul mercato e sul team.

Una giornata in cui approfondire strategie innovative e best practice, acquisendo gli strumenti per guidare con successo progetti e prodotti.

I temi che tratteremo:

👭 Team efficaci

💥 Creare Prodotti Memorabili

🚀 Lancio di Prodotti

💯 Dalle Epiche agli MVP

🔢 OKR

Workshop del mattino

🔢 OKR Practical Workshop

Con Francesco Fullone

Gli OKR non sono solo uno strumento, ma un potente motore che fornisce alle persone e alle aziende la visione necessaria per fissare obiettivi ambiziosi e concentrarsi sulla loro realizzazione.
Con obiettivi chiari, concreti e comunicati a tutti i livelli, i team e le aziende di prodotto possono mantenere la giusta attenzione e resistere alle distrazioni di un mercato ricco di opportunità.
In questa sessione da tre ore avrai l’occasione di capire ed esplorare l’essenza degli OKR. Attraverso una sessione interattive acquisirai competenze per cominciare col piede giusto.

👭 Gestire un team efficace

Con Luca Sartoni

Sviluppare competenze di leadership e di gestione di team di prodotto per massimizzare la produttività e il successo organizzativo.
Durante il workshop di 3 ore, verranno affrontati argomenti chiave come la definizione di ruoli e responsabilità all'interno del team, la comunicazione efficace, la motivazione e l'apprezzamento del team, nonché la creazione di un ambiente di lavoro positivo e collaborativo. Attraverso esempi pratici, casi studio e attività interattive, i partecipanti avranno l'opportunità di acquisire le competenze e le strategie necessarie per gestire con successo un team, affrontare i problemi e le sfide quotidiane e promuovere un clima di lavoro che favorisca la crescita e il successo collettivo.

💥 Dal Garage alla Galassia

Con Jacopo Romei

Miscelare Innovazione e Validazione per Creare Prodotti Memorabili.
In questo workshop dinamico di 3 ore, esploreremo come trasformare le idee più audaci in prodotti di successo con un approccio orientato all’innovazione e alla validazione di modelli di business.

Partendo dai fondamenti del Customer Development e del metodo Lean Startup, imparerai a identificare e testare le ipotesi più rischiose, progettare esperimenti efficaci e costruire prodotti che rispondano alle reali esigenze del mercato.

Attraverso casi di studio e attività pratiche, ti forniremo gli strumenti per ridurre i rischi, ottimizzare le risorse e garantire una crescita sostenibile. Unisciti a noi per un viaggio dal garage alla galassia e crea prodotti che lasciano un segno indelebile!

Workshop del pomeriggio

🔢 OKR Practical Workshop - Afternoon session

🚀 Strategie di Value to Market per un Lancio di Successo

Con Hoang Huynh

Impostare una strategia di Value to Market per prodotti e servizi innovativi.
In un mercato sempre più competitivo e in continua evoluzione, il successo di un nuovo prodotto o servizio non dipende solo dalla sua qualità intrinseca, ma dalla strategia con cui viene introdotto e posizionato.

Questo workshop di 3 ore è progettato per fornire una comprensione pratica delle metodologie di Value to Market, fondamentali per pianificare e implementare una strategia di lancio efficace e ad alto impatto.

💯 Morning Game: dalle Epiche agli MVP

Con Ivano Masiero

Hai mai provato a stilare una lista delle azioni che fai ogni mattina, da quando suona la sveglia a quando inizia la tua giornata lavorativa?
In questo workshop pratico e altamente interattivo partiremo proprio dalla nostra routine mattutina per (ri)esplorare alcuni concetti fondamentali dello sviluppo evolutivo di prodotti, servizi ed esperienze, come la distinzione tra Epiche, Storie e Task, la differenza tra value ed effort, tra outcome e output, fino ad arrivare a delineare il concetto di Minimum Viable Product (MVP).

Insieme creeremo un dizionario comune e un set di strumenti per aituarci a co-creare prodotti e servizi di successo. Giocheremo in piccoli gruppi per creare insieme una mappa delle storie che compongono le loro mattinate. Ogni gruppo affronterà diverse tematiche attraverso iterazioni successive, con discussioni guidate e momenti di debrief.

Com'è andata?

La giornata di workshop è andata molto molto bene in termini di partecipazione (65 persone iscritte) e in termini di coinvolgimento. Per farti un'idea, dai un'occhiata alle foto della giornata e ai feedback raccolti a caldo.

Product Management Workshop - Next Steps

Avanscoperta

Avanscoperta è un ecosistema di professionisti con una grande passione per l'apprendimento: amiamo esplorare nuovi territori, scambiare esperienze e idee nel campo del software nel senso più ampio possibile.
Cerca tra i nostri corsi quello giusto per te oppure scopri come aiutiamo le organizzazioni.

Rimani in contatto!
Vuoi continuare a leggere i nostri articoli? Iscriviti alla nostra newsletter 📩.

Imagine a Company whose main operational system still relies on functionalities provided by a COBOL application running on an aging AS/400 system. For years, plans had been made to replace this ancient component, but no one seemed willing to finally pull the plug.
This is a brief account of how we helped this client fulfill this long overdue task.

Challenges

• Legacy AS/400 application, in charge of computing prices for all bookings,
• one single developer able to update the code, already planning for his retirement,
• old hardware, with some components already failing and replacements not available from the vendor.

Scenario

The AS/400 application had long been in the process of being replaced; a new application had been developed revamping the whole UI (the new application UI being web-based, instead of terminal-based like the old one); many of the features had been moved to the new application, and all of the data had already been mirrored for the AS/400 system to the new SQL-Server backend system.
But the old AS/400 system was still the "source of truth" with regard to booking prices and inventory availability.
A new "price engine" had been built, and it was already running on the side of the "official" (legacy) AS/400 code to compute the price of all bookings; some evidence of the differences between the data computed by the two engines were collected, but without any details useful for a deeper analysis. The only data point available was that the two engines were computing the same price around 70% of the time.

Risks

Passive Risks

The legacy AS/400 system was labelled as a "ticking bomb" for many different reasons:

• it was running on old hardware no longer serviceable, nor covered by any effective support agreement,
• a minor hardware component (disk cache card onboard battery) had been failing for some time, and the vendor was not able to source a replacement unit, regardless of the price,
• only one developer was able to apply the regular changes on the legacy codebase needed for guaranteeing business operation continuity (the creation of some inventory required intervention on the code itself, on top of some "regular" configuration activities),
• the single developer able to modify and deploy the COBOL codebase of the legacy application was planning to retire.

Active Risks

Dismissing the legacy system would have required a few changes at the very core of the application architecture. All these changes were very sensitive, but with a different level of risk associated with each of them.

Source of truth

The "source of truth" would have to be moved from the legacy application to the new one; as the legacy data was already synchronized very frequently (there was a job, labelled as "near real-time", running every few seconds) and most of the further data processing was already done using the new database, this concern was labelled as "low risk".

Decommissioning the integration process

In order to keep the legacy application database synchronized with the new application, a set of intermediate structures and processes (stored procedures) had been developed and were constantly running.
To limit the impact of the changes to the system, these structures and processes have been mostly retained, changing just the least amount of code of the procedures to rewire the impacted processes to use the new components (mostly the price engine) instead of the legacy ones.
This means that the legacy flow of information has been retained, even if its presence was no longer needed in the new configuration we were aiming to implement; we have decided to retain some extra complexity in the system (aka "technical debt") in order to limit the amount of changes needed to update the procedures involved into the affected processes.
We have labelled this solution as "medium risk", because it was affecting the final state of the transition to the new application leaving around vestigial structures that were no longer needed; more moving parts meant more options for issues to emerge, and harder times investigating and resolving them.

Price Engine replacement

This was the core component being replaced, with a direct impact on prices computed for the users; the biggest criticality we identified was related to changes to already-booked bookings, as the system would recompute the price even when marginal changes were applied (eg. adding your passport number to the booking information). This extensive re-computation of prices may have exposed differences in the actual price computed by the two "price engines" to the final users, with also the possibility of marking some fully-paid bookings with due amounts (if the new price was higher than what was already settled).
In order to limit this option, we have worked to improve the effectiveness of the data collected during the "parallel run" of the two price engines, in order to let us understand which were the actual components of the final price that differ between the two systems.
When we started planning the decommissioning of the legacy application, the system was only "counting" how many price computations provided different results between the two systems, but without tracking any details; this information did not provide any ability to observe the differences to identify the core issues that would need improvements before the final cut-off date.
One of the very first steps we took in this regard was to greatly increase the details of the prices computed by the two engines when they would provide a different answer.
After having collected these differences for a few days, we could analyze the data and identify a few scenarios worth investigating. This proved to be pretty effective in fixing a few problems, which we then could validate as "fixed" as they stopped showing up in the following reports. These reports used the data collected to compare the two price engines.
We iterated this activity a few times, until all the reported differences were marginal, both in terms of economic value, and also in terms of the scenario triggering the issue.

Interesting finding

A very interesting finding of this activity was that some of the discrepancies between the two price engines were caused by "errors" in the legacy system, and not "bugs" in the new application.
Indeed, there were reports of issues with prices computed by the legacy application that the single developer was never able to address, and that business people were handling adding manual adjustments to the final price of the booking; the new application, having been built providing developers with the "business rules" (and not the legacy code), was able to correctly handle some scenarios that had to be amended previously.

Risk final considerations

After having identified all the major sources of risks, we planned and acted to measure and actively mitigate the major issues for which we had some leverage.
For risks for which we had no leverage (e.g. hardware issues), we regularly monitored the situation to have constant feedback and influence the actual planning of the remaining activities.

Actions

Feature free

We agreed with the business that we had to take a three-month "feature freeze" on the system in order to focus all developers and system administrator energy and attention on the activities needed for decommissioning the legacy application.
We had great help from the support team that handled all the business requests and expectations on our behalf, allowing us to focus on the daring task we were handling.
This caused a relevant piling-up of activities to be done after the switch-over was completed, but we were able to eventually address all the requests, just with some extra latency.

Disabling users' direct access to the legacy application

Some users were still using the legacy application directly (as demonstrated by some evidence collected looking through the logs) and we had to investigate why this was still the case. As the reasons were mostly due to old habits and not actual missing features in the new application, we disabled all direct access to the legacy applications a few weeks before the cutoff date, in order to give users some time to report back potential issues using just the new version of the application they may have forgotten to report. However, after some initial minor complaints due to some old habits being "decommissioned", all users were able to achieve their tasks also with the new application.

Aliased all the legacy system structures

In order to preserve as much as possible of the integration infrastructure, and to avoid breaking all the stored procedures involved, we have created a clone of the database structures managed by the legacy system, and we moved all references to the old structures to the new ones.
This allowed us to avoid having a massive amount of stored procedures failing to compile, with the risk of having the whole system grinding to an halt.
Preserving these –now useless– structures instead of fully removing them dropped the opportunity to streamline the system and do some long overdue maintenance tasks, but allowed us to avoid the headache of having to fix all compilation errors off-the-bat, and allowed us –instead– to monitor who would write to the legacy structures, in order to spot issues early on.

Cut-off date

The activities involved in the actual decommissioning were pretty intense, so we allocated a full weekend to perform all the tasks minimizing the impact on the business operations.
As the US offices mostly generated the activity on the system, we selected the weekend before July 4th (it was on a Monday in 2022), as this provided us an extra day of low business activity where we could monitor the new configuration of the system to validate the success of the operation.

Outcomes

When operations started on Monday morning (July 4th, 2022) everything was apparently working as usual, so much that some users (aware of the massive operations happening during the weekend) asked if the decommissioning had actually happened or had it been rolled-back.
The major issue that was reported was a missing report (an important one though) between the reports that were produced every morning; identifying the issue and generating the missing report took a few hours, and the users eventually received it before the end of the business day, instead of in the early morning as they were used to. Once the missing report was restored, no other issues were reported.
When US operations started on Tuesday morning (5th July 2022, EST), the system was in working order.
Overall performances were slightly improved, but not with the benefits we were hoping to achieve; keeping a lot of the legacy structures in place did not allow to fully streamline the core operations, so the performance benefits were limited.

Celebrations

The decommissioning of this system has been a massive success, allowing the company to neutralize significant risks and remove constraints that had hindered its autonomy in evolving its business system. Unfortunately, the demands of daily operations and processing enqueued tasks quickly took priority. As no major issues emerged in the following weeks, the achievement was soon archived, and we never took the time to celebrate it as deserved.

Conclusions

Decommissioning legacy systems is usually a complex task, especially when it involves extensive change management activities across the company due to the many processes affected by the switch. These activities carry inherent technical risks, but their "blast radius" is much wider when considering business operations. Most of the time, it is not possible to fully address and defuse all potential risks. The best approach is to identify the main risk issues and then constantly monitor, measure, and assess their status in preparation for the migration. This helps inform and adapt necessary actions to achieve the desired outcome. Such clarity is also extremely helpful in managing communications with stakeholders, as keeping everyone informed is paramount to the project's success.

About the Author

Giulio Cesare Solaroli aids teams and organizations in:

• Analyzing business domains through techniques like EventStorming
• Identifying domains, subdomains, and value streams
• Coaching and mentoring business, product, and technical teams.

Designing and developing software solutions. His goal is to steer companies towards a more efficient and competitive digital future, offering expertise and support every step of the way.

More about Avanscoperta

Avanscoperta is an ecosystem of professionals with a great passion for learning: we love exploring new territories, exchanging experiences and ideas in the field of software in its broadest possible sense.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.

Trascrizione dello Small Talk del 14 settembre 2022 con Gianluca Padovani per parlare di uno dei best seller del nostro catalogo corso: Microservices Practical Workshop.

L'intervista è stata leggermente modificata per adattarla al formato scritto.

Avanscoperta: Ciao Gianluca, ben trovato. Siamo a un mese dal tuo corso Microservices Practical Workshop, cosa ci puoi dire al riguardo?

Gianluca: È un argomento che mi appassiona molto perché in realtà mi accompagna dall'inizio, da quando iniziai lavorare nel mondo dell'informatica… è bello come alcune cose nascono e sono già così, anche senza dargli un nome. Poi dopo gli si dà un nome, come appunto nel caso dei microservizi, le cose si formalizzano e a volte diventano molto mainstream e super famose.

Ma io, e chi ha partecipato al mio corso lo sa, vedo le radici dei microservizi anche dentro a UNIX, e il modo in cui UNIX approccia alcune cose, ossia proprio nell’idea della decomposizione fatta da Parnas, quindi nelle radici stesse della buona programmazione.

Poi i microservizi hanno formalizzato tutto, chiaramente: quando vai in un mondo legato ai microservizi, ti entrano in campo tutta un'altra serie di problematiche. Però secondo me c’è questo nocciolo che rappresenta anche qualcosa di piuttosto antico.

Avanscoperta: Iniziano le chicche, che sono la parte più bella di Small Talk: rivelazioni, dietro le quinte, cose che non si leggono nella scheda corso.
Entriamo nel vivo: a chi è rivolto il tuo corso? Per com’è disegnato ora, è un corso da remoto di quattro mezze giornate più due ore di follow-up, che sono un’occasione, dopo esserci sporcati le mani e aver visto tanto codice, di ritrovarci dopo circa due settimane per vedere un po' cosa è successo e come va. Questo perché, come si suol dire, a volte va tutto bene durante il corso, poi si va a casa, si prova a mettere in pratica, si sbatte la testa e dopo due settimane si cerca un po' di fare il punto tutti insieme.

A chi è rivolto Microservices Practical Workshop?

Gianluca: Sicuramente è rivolto a chi ha un minimo, e più che un minimo direi, di esperienza nel mondo dello sviluppo. Quindi a chi si è scontrato contro i classici problemi di applicazioni enterprise enormi diventate ingestibili: chi ha il classico mega monolite a cui, io dico sempre, bisogna voler bene, perché non è il nostro nemico: il monolite è una persona che soffre e che noi dobbiamo aiutare a soffrire meno… parliamo quindi di persone che hanno questa montagna di codice che non si riesce mai a gestire e che vuole trovare un modo per incominciare a sciogliere qualche nodo all’interno del monolite.

Queste persone hanno un certo grado di esperienza nella programmazione e, preferibilmente, anche nel mondo del Domain-Driven Design, e su questo ci torneremo, oppure hanno già iniziato ad approcciare i microservizi, ne sono rimaste in qualche modo scottate perché hanno visto solo la parte dolorosa di questo mondo, quando i conti non tornano (classico problema dei microservizi), difficoltà nel fare le transazioni distribuite, ecc.

Chi li vuole approcciare? Chi è rimasto scottato o, e questo è l'ultimo caso, chi magari li sta già usando e vuole vedere un altro punto di vista nell’uso dei microservizi.

Questo perché quando si parla di microservizi si parla di tutto e il contrario di tutto, nel senso che quando si approccia un’architettura a microservizi ci sono molti modi per farla, ci sono vari drive che ti portano ad usarla, e varie necessità: vuoi perché alcune parti le vuoi isolare perché le devi certificare in maniera formale, vuoi perché alcune parti devono essere più scalabili o più efficienti di altre, o alcune parti sono troppo complesse e non le riesci a gestire… quindi ci sono vari modi, varie necessità e varie problematiche che un'architettura a microservizi può risolvere.

Ci sono anche vari modi di implementarla: dal classico modo completamente basato su http, o comunque su un’architettura più classica in cui microservizi si parlano in stile request-response, ad altri modi, che sono quelli che vediamo nel corso, con architetture basate sugli eventi, molto orientate al mondo del Domain-Driven Design, il che ti porta ad affrontare tutto il percorso verso i microservizi in una determinata maniera.

Tempo fa, su LinkedIn c’è stata una domanda che chiedeva: “è necessario fare DDD per fare microservizi?” La risposta formale è no: non è che se non fai DDD non puoi fare microservizi.
Tuttavia, un approccio che io consiglio è quello DDD-oriented, perché ti permette di analizzare il tuo business in una maniera olistica: in questo modo riesci a osservare il tuo problema in una maniera globale, e non solo dal punto di vista tecnico.

E questo secondo me è uno degli altri problemi relativi ai microservizi: si pensa che siano solo una questione tecnica, il che è un errore. Fare microservizi significa approcciarsi al business in modo diverso.

Provando a riassumere: a chi è rivolto il corso? A chi vuole iniziare, a chi ha iniziato ed è rimasto scottato, e a chi li sta usando e vuole provare a vederli sotto un'altra luce.

Avanscoperta: Quando si parla di microservizi, si tira in ballo una delle buzzwords più abusate degli ultimi tempi. La mia prossima domanda vuole provare a restringere un po’ il campo e andare a capire bene e per davvero: cosa sono i microservizi, volendo dare una definizione che vada bene un po’ in tutti i contesti?

Gianluca: Ne parleremo nel corso, ci sono varie definizioni formali dei microservizi, formalizzate da chi li ha inventati. Una definizione che a me piace molto, e che però è molto da consulente, ossia il classico “it depends”, è: qualcosa che ti deve stare in testa. Questo chiaramente è molto soggettivo, nel senso che è legato alle skill del team e del gruppo di dev che ci lavorano.

Se invece la guardi dal punto di vista del DDD, secondo me è quella più semplice perché ti dà dei naturali punti di taglio, che possono essere o un bounded context o un aggregato, ma diciamo che dal punto di vista più agnostico possibile…

un microservizio dovrebbe essere un servizio auto contenuto,

quindi qualcosa ha una serie di dati di cui solo lui è padrone, e solo lui ha la capacità di modificare quei dati, per cui è l’unico padrone del suo stato interno. In qualche modo poi questo microservizio parla con altri servizi in due modi: o utilizzando una tecnica più request-response, classico http che abbiamo menzionato anche prima, o reagendo a eventi che riceve su un classico broker, e fa cambiare il suo stato interno in quel modo.
Quindi tu lo puoi interrogare per sapere qual è un determinato stato, che mantiene solo lui.

Chiaramente, ed è questo il motivo per cui dico che i microservizi non sono solo una questione tecnica, il microservizio deve essere tagliato rispetto alle esigenze di business, perché

uno dei fattori principali per cui si sceglie un’architettura a microservizi è quello di voler accelerare lo sviluppo di feature legate a un determinato bounded context (termine del DDD) o settore di business, il che significa che deve esserci un certo grado di allineamento.

Per esempio, si può avere il microservizio che si occupa del mondo della finanza, o del marketing, all'interno del tuo business, o si occupa dell’onboarding di nuovi utenti, e dev'essere qualcosa che ha a che fare con quella parte, e quindi rimane contenuto a quella determinata parte.

Il team può crescere e può diventare esperto di dominio, perché uno dei fattori di accelerazione nello sviluppo è quello per cui gli sviluppatori riescono a parlare in maniera sempre più efficace con il business, e di conseguenza quando il business ha una determinata esigenza, i dev l’accolgono, senza doversi preoccupare di tutte le parti del sistema, ma solo della loro parte.

Avanscoperta: Partiamo con le domande dal pubblico: “spesso microservices significa scalabilità e flessibilità al costo di una maggiore complessità gestionale. Quando conviene iniziare a considerare la scalabilità come un fattore?”.

Gianluca: Domanda molto interessante perché dietro la parola scalabilità ci può essere tutto e niente. Quando si dice scalabilità, si pensa a una scalabilità tecnica, quindi il fatto che il tuo microservizio possa rispondere a un maggior numero di richieste esterne.
Ma io sotto al cappello della scalabilità metto anche la capacità di scalare dal punto di vista di sviluppo.

Per esempio, se tu hai il classico monolitone, con un mega repository con dentro tutto il tuo codice, e vuoi accelerare su una certa parte di business (reporting, finance, ecc.), perché sai che il tuo business in quella zona lì deve crescere nei prossimi mesi, e quindi vuoi aumentare i componenti del team, questo diventa complicato, perché se vuoi mettere le mani su quel codice devi conoscere tutto il monolite, e fai fatica a isolare alcune parti.
Di consegneuza non riesci neanche a scalare in termini di sviluppo.

Mentre se hai un team molto dedicato a una determinata zona, ed è allineato col business, questo team ne diventa padrone, cioè ha una conoscenza del dominio molto elevata e può aiutare da un lato il business a trovare soluzioni corrette, dall'altro conosce fortemente la sua codebase ed è sicuramente più efficace nello sviluppare nuove feature.

Quand’è che si deve iniziare a considerare la scalabilità come un fattore? Io dico sempre che la scalabilità nasce dal design che tu fai del tuo microservizio, quindi non è tanto una questione di andare a fare fine tuning, che va fatto ma in un secondo momento.

La scalabilità secondo me deve essere pensata dal punto di vista architetturale, e sicuramente un’architettura microservizi ti aiuta a decidere dove scalare, anche banalmente, perché ti permette di dire: “questo microservizio lo metto in replica 10”, e quindi hai 10 istanze dello stesso microservizio che ti rispondono, mentre un'altra parte del tuo sistema, che viene sollecitata molto meno, la puoi lasciare con un’istanza o due. Quindi già questa scelta ti porta nella direzione della scalabilità.

Poi è chiaro che se tutto dipende da come implementi il tuo microservizio: se non sei poi in grado di gestire in maniera concorrente le richieste, per esempio, il fatto di avere molte repliche non serve poi a tanto. E questa è più una questione di design, che però io ormai tengo in considerazione da subito, sennò stiamo parlando di niente.

E quando si parla di aumentare il numero di richieste in modo considerevole, mi chiedo sempre: “ma di cosa stiamo parlando?”. In ogni caso è sempre il business che guida. E mi chiedo, quindi: “hai effettivamente la necessità di servire 2 milioni di richieste al secondo?”, perché se hai quel tipo di esigenze di business, allora è il design, in primo luogo, che deve andare in quella direzione, e questo deve accadere dall’inizio.

Se per esempio hai una start up, e partiamo da subito dicendo che serve rispondere a 2 milioni di richieste, forse stiamo facendo il passo più lungo della gamba. Magari può anche andar bene partire con un’architettura a microservizi… ma meglio non spoilerare un’altra domanda a cui dobbiamo rispondere tra poco.

Avanscoperta: Infatti ce n'è una di Simone, che ringrazio, e che chiede: “il pattern che si vede spesso è che con la start up si parte semplici, con un bel monolite, poi si vede e in caso, se scali, si passa ai microservizi”. È vero?

Gianluca: In teoria, sì; in pratica, quello che succede, nella mia esperienza, è che si va troppo avanti. Quello che capita nelle startup è che si vuole ottenere un MVP immediatamente, e secondo me scegliere un monolite è la scelta giusta: avere a che fare con un business in continuo movimento, dove non solo hai richieste di nuove features su una determinata zona (e su quello i microservizi sono fantastici)... quando sei una startup, soprattutto in early stage, rischi che il business cambi completamente, cioè all'inizio pensi di vendere delle biciclette e poi scopri che in realtà stai noleggiando un servizio di consegne.
Quindi hai cambiato completamente il tuo business. Su questo fronte i microservizi ti frenano, mentre con un monolite, dove hai tutto sotto controllo, sei in grado di fare cambi di business più forti.

I microservizi dovrebbero entrare in una seconda fase. Quello che io dico sempre è che non c'è un momento x in cui passi dal monolite a 50 microservizi: dovresti essere in grado di vedere che a un certo punto di fianco al tuo primo monolite, che in realtà sarà comunque molto piccolo, puoi fare puoi far emergere un secondo monolite, e quindi muoverti verso un'architettura un po' più a microservizi, ma senza averne subito 50, ok?

Perché nel mondo dei microservizi ci sono alcuni step: da 0 a 10 microservizi hai una serie di problematiche, da 10 a 50 o 100 ne hai delle altre, e dopo ne hai delle altre ancora.
Quando rimani in una certa fase, più o meno hai un certo tipo di problematiche.

Quello che io consiglio di fare alle start up è di partire con un monolite, stando bene attenti che a un certo punto puoi introdurre magari un secondo servizio, o un terzo, senza dover andare a prendere per forza tutti i tool che ti servono quando sei a 200 microservizi.

Questo significa che ci sono varie fasi da tenere in conto a seconda della storia in cui si trova un progetto, che è un po' il punto complicato, e per questo spesso io dico: “fatevi aiutare”, perché è complicato per chi non ha esperienza capire quando è il momento di inserire un altro microservizio e posso ignorare tutte le problematiche che ho quando parlo di 200 microservizi.

Quando si parla di 3 o 10 microservizi, non ho problemi di goverance. Quando ne ho 200, invece, ho problemi di governance del tipo: “ma chi è che fa cosa? Cosa fa quel servizio in particolare?” Cioè ci sono 200 cose da capire ed è complicato ottenere informazioni e documentazione, mentre quando hai 5 o 6 microservizi.

Avanscoperta: Un’altra domanda dal pubblico: “banale ma non banale: meglio repository unico per progetto, o repository separati per ogni microservizio?”

Gianluca: Dipende cosa intendi per progetto, una risposta può essere: per me ogni microservizio ha il suo database, e nessun altro microservizio può farvi accesso, è blindato. Il suo stato è quello.
Se vuoi interrogare quel microservizio ci sono altre mille modi, come la chiamata http, mandare un messaggio e così via, ma ogni microservizio ha il suo database, inteso come database logico.

Quindi diciamo che ogni microservizio ha il suo stato interno e ha il suo database, tant'è che dovrebbe essere libero anche di scegliere il tipo di database: il microservizio A ha bisogno del database relazionale, il microservizio B quello documentale, e il C un grafo, perché deve fare relazioni di amicizia o fare determinate cose… e quindi dopo lì si entra nel mondo della governance, dove va stabilito che libertà dare a ciascun microservizio, però diciamo ogni microservizio dovrebbe avere il suo stato, e quindi più repository separate.

Avanscoperta: Ancora una domanda da parte di Simone, a cui forse hai già risposto: “avere sotto un database unico è una bad practice o è plausibile?”.

Gianluca: Dipende. Se creiamo da zero un'architettura a microservizi e quindi stiamo trovando una soluzione a un problema greenfield, avere un database condiviso secondo me è male, ma proprio male male, tra le cose che in assoluto non si fanno.

Discorso diverso se sei in una fase di migrazione, ossia: hai il monolite, sta tirando fuori microservizi, sei in una fase di immigrazione, allora può essere che un microservizio va ad accedere ai dati del database del monolite, o delle due anche viceversa: una parte del monolite va ad accedere ai dati dei microservizi.

Ma deve essere un momento transitorio che col passare del tempo va eliminato. A livello architetturale i database devono essere completamente separati, tranne rari casi particolari in cui un database in realtà è una cache… però come regola generale i database devono essere assolutamente separati.
Questo, ossia il voler condividere il database come scelta architetturale e non come fase transitoria, è uno dei motivi per cui vedo spesso fare del casino, e consiglio vivamente di non farlo.

Avanscoperta: Torniamo a parlare del tuo corso nello specifico. Quattro mezze giornate da remoto, un sacco di pratica ed esercitazioni, non sarà un corso in cui sedersi e guardare una carrellata di slide. Esercizi di gruppo, dicevamo, e da soli. Come bilanciamo teoria e pratica?

Gianluca: C'è un po' di teoria, anche perché col nome “microservizi”... non può mancare. Ma in realtà si poggiano su due grandi pilastri:

1) uno è il poter dividere il problema in sotto problemi, classico della programmazione UNIX, in cui l’esempio più lampante è quando hai cat, che lo metti in pipe (|) con un grep e il risultato lo metti ancora in pipe con un sort, ciò che ottieni è qualcosa dove il risultato è maggiore della semplice somma delle parti:

2) e l’altro è il fatto che un’architettura a microservizi non è altro che un sistema distribuito, e di nuovo ci sono caterve di teoria sui sistemi distribuiti. Chiaramente, in un corso come il nostro non si può fare tutta questa teoria, ma un po di basi su questi due aspetti c’è.

Ma c’è anche molta pratica: partiremo dal cercare questi microservizi, ed è uno degli aspetti più complicati di quando si crea un’architettura microservizi, partendo da una domanda come: “che microservizio devo creare? Come li trovo, questi microservizi? Come faccio a trovarli all’interno del mio business e del problema che devo risolvere?”, che è anche uno dei punti in cui sorgono problemi, perché si tende a riapplicare alcuni pattern mentali che abbiamo, come il classico three-tier architecture, in cui un microservizio si occupa della parte di salvataggio dati, un altro della business logic e un altro ancora si occupa della presentation.

In generale questo approccio è molto complicato secondo me, e anche pericoloso, e di nuovo entra in gioco il Domain-Driven Design, in cui tagliare il business seguendo i suoi naturali confini, che sono classicamente boundaries, bounded contexts e aggregati, dà grande valore.

Per cui uno dei primi esercizi che faremo è sul trovare questi microservizi. Poi incominceremo a fare un po' di esercizi di analisi su come questi microservizi si parlano: ci sono vari modi per far parlare questi servizi.
Se lavorate con me e un po' mi conoscete sapete che io odio il “giusto o sbagliato”, e cerco sempre pro e contro: ogni cosa che si fa ha i suoi pro e sui contro.

Ogni tipo di comunicazione tra microservizi ha i suoi pro e i suoi contro. C’è stata un’ondata di discussioni in cui si diceva che non fosse giusto far parlare i microservizi con http… non è vero: si può fare, e se lo fai ti esponi a determinate problematiche ma hai anche determinati vantaggi. Se scegli un approccio completamente basato sugli eventi, avrai altre problematiche.
Nel corso quindi ci saranno un po’ di esercizi su questa parte.

Proveremo anche a entrare e scrivere un piccolo microservizio, quindi una volta trovato proveremo a implementarlo. L’esempio durante il corso sarà fatto con TypeScript, ma siamo a un livello abbastanza generale, per cui quindi chiunque abbia un minimo di conoscenza dello sviluppo può metterci mano, e da lì proveremo a farlo evolvere rispetto tutte le problematiche che poi capitano nella realtà.

Per esempio: quando hai tutti i microservizi, come fai a ottenere uno stato globale del sistema? Come fare a rendere alcune parti più performanti (perché magari quella parte del sistema deve andare un po’ più forte)? Cosa succede una volta che ho trovato un numero crescente di microservizi? Come ne gestisco le problematiche?

Ci saranno varie parti sia di teoria che di pratica. Spero di aver trovato il giusto mix perché odio un po' le ricette e gli approcci prescrittivi, preferisco dare una ricetta in meno ma spiegare perché quella ricetta lì funziona, o meglio: quando quella ricetta funziona, e quindi presentare anche scenari e use case, in modo che dopo ognuno possa calarla nel proprio dominio e nella propria quotidianità.
È fondamentale capire le basi e perché si è fatta una certa scelta, e non solo “mi han detto di fare così”.

Avanscoperta: Nel corso di questa intervista abbiamo parlato di microservizi e Domain-Driven Design, un connubio di cui hai parlato anche in un capitolo del libro corale Cronache di DDD, pubblicato da Avanscoperta e uscito da qualche mese in digitale e cartaceo.
Oggi ho sentito spesso parlare di esigenze di business e codice che devono andare a braccetto e in questo sappiamo che DDD è fondamentale.
Ci puoi dire qualcosa di più sul rapporto tra DDD e microservizi?

Gianluca:

DDD offre tutta una serie di strumenti che facilitano l’entrata nel mondo dei microservizi per i neofiti: c’è tutta una serie di concetti che puoi prendere quasi così come sono, se li consideri in maniera astratta, e riportarli nel mondo dei microservices, ed è tutto molto naturale.

E questo è uno dei primi vantaggi che io vedo. Concetti come aggregati, entity, bounded context, e anche il DDD nella versione CQRS ed event sourcing, secondo me ti aiutano ad analizzare e a sviluppare i tuoi microservizi.

Una cosa non fondamentale ma secondo me di grande valore nel Domain-Driven Design è che ti dice dove potresti avere problemi, cioè: se il DDD ti dice che questo è un aggregato, significa che a livello di business quella parte lì deve cambiare in maniera atomica, transazionale. Se tu a livello di microservizi la vai a spezzare, ogni microservizio avrà il suo boundary transazionale.
Quindi tu stai dividendo una cosa che a livello di business dovrebbe stare insieme, e quindi questo è già un segnale di allarme molto importante.

DDD ti dà tutta una serie di indizi su come andare a trovare i tuoi microservizi e su dove ci potrebbero essere dei pain point, quindi le zone un po' più dolorose cui devi sempre fare molta attenzione.

E di nuovo, DDD allinea il business con la parte tecnica, che è uno dei suoi cavalli di battaglia, nonché una delle cose che spesso nel mondo dei microservizi si sottovaluta, ma che è assolutamente necessaria.

Se un'azienda vuole abbracciare i microservizi deve fare anche un minimo di riorganizzazione aziendale. Non puoi avere 50 microservizi e 10 team e tutti possono toccare tutti i microservizi: così stai facendo un mezzo monolite cammuffato.

Serve invece che conoscenza e ownership di determinati microservizi siano affidate a determinati team, e in questo DDD è fondamentale, perché allinea esigenze di business a esigenze tecniche.

Avanscoperta: Abbiamo accennato poco fa al nostro libro, pubblicato su Leanpub (digitale) e Amazon (cartaceo), chiamato Cronache di Domain-Driven Design, un libro corale nato anche dall'esperienza con le conferenze on-line organizzate da DDD Open, dove Gianluca ha contribuito con un capitolo intitolato “Microservizi e DDD”.
Ci vuoi raccontare qualcosa su questa esperienza di scrittura?

Gianluca: Volentieri. Avevo esperienza di scrittura di qualche blog, articoli, ma non ho mai affrontato la stesura del capitolo di un libro. È stato molto interessante, anche perché comunque è stata una scrittura corale, guidata da Avanscoperta, quindi ci avete messi tutti insieme, e il bello è stato sviluppare uno stesso argomento ma da diversi punti di vista.

Io ho portato quello dei microservizi perché c'ho lavorato e ci sto lavorando tanto e ci trovo un grande valore. Consiglio la lettura del libro o dall'inizio alla fine, perché veramente vedi tante storie, oppure anche semplicemente a spizzichi e bocconi, perché ogni storia e ogni capitolo rappresenta un punto di vista diverso su DDD, inizia e finisce, quindi potete trovare grande valore da ogni capitolo, a seconda delle esigenze e interessi.

Il capitolo iniziale di Alberto Brandolini è molto interessante, si parte dalle basi su terminologia e altri aspetti fondanti di DDD e di ciò che si parla nei capitoli successivi.

Nel mio capitolo parlo di come DDD può essere usato in vari modi nel mondo dei microservizi. C’è un esempio in cui DDD non è usato in modo consistente, ma come feedback per non aaver fatto troppi errori: c’erano forze che spingevano a separare alcune cose, e DDD è stato usato un po’ come cartina tornasole per fare emergere eventuali problemi…
Oltre al mio capitolo ci sono tante altre storie, per cui vale davvero la pena leggerlo!

Avanscoperta: Sono sette storie più una bonus track di Matteo Baglini su DDD e Functional Programming, oltre al già citato capitolo introduttivo di Alberto Brandolini… un libro corale con varie storie e punti di vista diversi su DDD.
Un grazie enorme da parte di Avanscoperta per aver contribuito a un libro che non contiene dogmi, ma piuttosto storie di vita, casi reali di come avete fatto a usare DDD nel vostro lavoro.

Due domande per chiudere: “microservizi può voler dire anche anche possibilità di eterogeneità dello stack, come dire: scelgo il linguaggio o il framework giusto nel posto giusto… ma spesso i CTO vedono in questa eterogeneità il male. È vero?”.

Gianluca: La risposta è “dipende”. O meglio: sì e no.
Io sono CTO di un’azienda, e avere all'interno della propria azienda 18 linguaggi diversi è chiaramente un problema, perché non puoi avere tutte le persone fluenti su tutti i linguaggi, quindi entrano in gioco tutta un'altra serie di problematiche molto forti.

Per esempio, capita che hai un microservizio scritto con un linguaggio X dove solo due persone possono metterci le mani. In questo modo stai perdendo tutto il valore di scalabilità in termini di feature di cui parlavamo prima, quindi ti chiedo: dov'è il valore di fare microservizi?

Secondo me il punto di eterogeneità sullo stack va visto in quest’ottica: all'interno di un'azienda sana, ci dovrebbero essere sempre tre linguaggi. Il linguaggio vecchio, che nessuno vuole più usare e che si sta dismettendo; poi c'è il linguaggio attuale, quello che usi per affrontare qualsiasi problema incontri; e poi c'è il linguaggio nuovo, che è quello che il team o l'azienda sta sperimentando, ed è quello che probabilmente in futuro diventerà il linguaggio dominante (il secondo, in questo esempio), e così via.

Questo dovrebbe essere sempre come una ruota che gira in un'azienda sana, o in un reparto sano, diciamo così, poi dipende dalle dimensioni di un'azienda.

Se tu hai un unico monolitone, fare quest'operazione diventa piuttosto complicato. In un mondo a microservizi, questa operazione diventa molto più semplice, perché hai magari un numero di microservizi nel linguaggio vecchio, e questo numero deve essere sempre basso, la maggior parte dei microservizi nel linguaggio dominante, e alcuni microservizi nel linguaggio nuovo.

Sperimentare un nuovo linguaggio o una nuova tecnologia in un mondo a microservizi è molto più semplice. Puoi provarlo in uno o più microservizi e se non ti piace è molto più facile fare rollback. Anche l’aggiornamento di una libreria o della versione stessa linguaggio risulta molto più semplice e graduale. In un monolite l’operazione è globale e spesso non è così semplice.

Un altro esempio che facevamo prima era quello dei database: ogni microservizio può avere il database che gli serve, però se il database relazionale di riferimento è sempre diverso, averli tutti diversi ti crea molti problemi. Meglio scegliere un database relazionale di riferimento. Idem per il documentale.

Se stai introducendo i microservizi in azienda, non aggiungere anche un nuovo linguaggio. Parti da quello che conosci già: prima ti occupi dei microservizi, poi pensi al resto. Se invece già li usi, introdurre un nuovo linguaggio sarà facile.

Avanscoperta: Ultima domanda da parte di Simone, che ringraziamo: “framework consigliati per microservizi node.js?”.

Gianluca: Ne ho visti alcuni ma sinceramente non me la sento di consigliarne perché non li ho mai provati in produzione.

In generale non sono un grande amante dei framework, preferisco le librerie, e qui si potrebbe aprire un dibattito su cosa è un framework e cosa è una libreria… sinceramente non saprei cosa consigliarti.

Uno dei vantaggi dei microservizi e DDD è che se conosci la teoria poi implementarla diventa abbastanza abbastanza semplice e forse un preframework non ti aiuta più di tanto.

Imparare i microservizi avendo un framework e non conoscendo la teoria secondo me è pericoloso, perché i microservizi sono pronti a morderti in ogni istante. Quindi è meglio prima conoscere la teoria e poi dopo magari decidere se quel framework li fa bene ed è in linea con le tue esigenze.

Cover photo: Colin Lloyd su Unsplash

Small Talk con Gianluca Padovani: il video - il podcast.

Learn with Gianluca Padovani

Gianluca è il trainer di Microservices Practical Workshop.

Vuoi continuare a leggerci? Iscriviti alla nostra Newsletter 📩 (disponibile in italiano e in inglese).
Ti faremo compagnia ogni venerdì mattina. ☕️

La lista completa dei nostri corsi: Avanscoperta Workshops.

Trascrizione dello Small Talk del 10 gennaio 2024 con Hoang Huynh - si parla del suo nuovo corso, chiamato Value Proposition Strategy Workshop.

L'intervista è stata leggermente modificata per adattarla al formato scritto.

Avanscoperta: Il tuo corso che faremo a Marzo 2024 si chiama Value Proposition Strategy. Di cosa si tratta? A chi è rivolto? Facciamo una panoramica, presentaci il corso.

Hoang: Il workshop è rivolto a tutte quelle persone che sono a cavallo fra il business, il prodotto e il marketing.
Che cosa vuol dire? Oggi, in un contesto così complicato, lanciare un prodotto, lanciare una nuova linea di business, lanciare qualsiasi cosa, non è così semplice come era qualche anno fa, perché il mercato è super affollato e chiaramente essere distintivi, che è la cosa che ci raccontiamo da tanti anni, non è così semplice.

Ora, perché parliamo di Value Proposition e parliamo di Value Proposition Strategy? Lo racconto in modo semplice: io vengo da ormai quasi 7 anni di consulenza, in questi anni ho avuto il privilegio e l'onore di lanciare tantissime nuove linee di business all'interno del corporate. Quando parlo di una corporate parlo anche di un brand che può essere più o meno grosso, ma in ogni caso è qualcosa che la gente sposa o comunque ama. Quindi non è solo semplicemente l’esempio della classica startup che lancia nuovi prodotti o tecnologie strettamente innovative.

Cosa accade in questo mondo? Il concetto classico di Value Proposition, che nasce dal marketing, ossia quella cosa per cui questo concetto è molto vicino al motivo per cui la gente ci vorrebbe comprare, non è più sufficiente. E questo accade perché il mercato evolve, i competitor si muovono sulla base di quello che facciamo noi, e noi all'interno di questo favoloso contesto in realtà abbiamo un tempo per prendere le decisioni all'interno delle corporation che è estremamente lungo, e relativamente lungo se si ha una startup.

Quindi di fatto quella barriera che di solito è nella testa del product owner, ossia tra marketing, business e prodotto, in realtà è estremamente labile quanto si parla di confini di distinzione: capire cosa è business e capire cosa è marketing diventa molto complicato.
In questo contesto, quando parliamo di strategie legate alla Value Proposition, non parliamo esclusivamente l'offerta che noi facciamo quando entriamo sul mercato, ma di tutta la strategia che noi mettiamo in piedi per fare il Go-To-Market, e quindi quello che oggi si preferisce dire Value-To-Market, perché non c'è semplicemente il lancio di qualcosa e poi preghiamo che le cose vadano bene, ma è un costo di erogare il massimo valore possibile per un intero ciclo di vita.

Quindi se le condizioni del mercato cambiano, se il tuo prodotto evolve perché magari stai imparando cose, immaginiamo un contesto agile dove in realtà riesci a costruire il tuo razzo mentre stai precipitando, e quindi il tuo prodotto evolve… In tutto questo scenario però ci sono alcuni capisaldi che bisogna, da manuale, tenere saldi, perché sennò il tuo attuale mercato rischi di alienarlo, oppure rischi di inseguire tutta una serie di stimoli e di cose che qualitativamente sembrano molto interessanti, ma di fatto sono un po' delle chimere che tu, in qualità di AD, dirigente, direttore o direttrice marketing o altro, tendi a seguire perché sei guidato o guidata da quelli che sono obiettivi di breve periodo.

Ora, questa struttura strategica, in termini di valore, corrisponde a tutta una serie di metodologie tecniche e modalità di vedere le cose da punti di vista completamente nuovi che ti permettono di tenere un po' fermo il timone, almeno fino a raggiungere quei punti chiave in cui effettivamente riesci a misurare qualcosa che abbia un senso e quindi sia rilevante, oppure effettivamente riesci a creare quel cambiamento sul mercato che crea dei benefici o comunque un contesto a te favorevole.

Quindi non è una roba tecnicamente nuova rispetto a quello che è sempre successo sul mercato: il Go-To-Market si fa da quando esistono i prodotti. È diversa tutta una serie di obiettivi e di risultati che vogliamo ottenere in termini di outcome, che non è più semplicemente legato solo alla vendita:

si tratta di far amare qualcosa e andare a rompere le regole che oggi sono consolidate, perché semplicemente il nostro prodotto merita un contesto nel quale essere compreso e quindi diventa rilevante anche in contesti che oggi non esistono, ma che devo essere in grado di progettare.

Avanscoperta: Il focus non è tanto sul lancio del prodotto o servizio ma su tutto il ciclo, perché il mercato evolve, così come le esigenze dei consumatori. In questo senso quello che tu proponi può aiutarci.
Hai fatto riferimento ad alcuni capisaldi da tenere sempre in mente, puoi dirci qualcosa di più?

Hoang: Sì, sono tutta una serie di considerazioni che quando parliamo di Go-To-Market, come ti dicevo prima, pensiamo solo al lancio. In realtà quando parliamo di Value Proposition e Value-To-market è forse un po' la parte strategica del Go-To-Market. Questo perché di fatto quando si pensa a qualcosa di tattico noi vogliamo risultati subito.
È un po' come giocare a scacchi: la differenza tra tattica e strategia in realtà è molto sfumata.

Storicamente, in termini economici, quando parliamo di strategia ci aspettiamo dei risultati sul lungo periodo, mentre sul tattico in maniera breve. Questo non è sempre vero perché, come negli scacchi, non è che domani devo piazzare un prodotto e venderlo tutti i costi, ma c'è un discorso di posizionarsi, fare engagement, evitare che i competitor facciano la stessa cosa, e quindi andare a disinnescare certe dinamiche.

Gli obiettivi di un’azienda o comunque di una linea di business in generale devono essere un pochino più ampi, quindi non solo attaccare il mercato in maniera figurativa, ma anche difendere questo mercato sul medio-lungo periodo. Per fare questo hai bisogno di ipotizzare e pensare tutta una serie di operazioni, quelli che prima chiamavamo capisaldi, che di fatto possono diventare anche degli asset o comunque delle cose, come dei mattoncini LEGO, che io posso utilizzare nel ciclo di vita del prodotto per poter essere comunque sempre riconoscibile e distintivo.

Avanscoperta: Come si inserisce in questo discorso uno strumento come il Business Model Canvas, di cui naturalmente si parla tantissimo, e che possiamo a buon diritto annoverare tra i capisaldi di cui si parlava?

Hoang: Adoro il Business Model Canvas: è uno strumento di semplificazione e comunicazione estremamente efficace ed è incredibile come è stato pensato, è davvero molto utile. Non amo tantissimo le sue varianti, anche se di fatto Vanilla è la versione più potente dal mio punto di vista, ma in generale le sue estensioni sono un po’ mancanti. Per esempio il Value Proposition Canvas e tutto ciò che gli gira attorno.

Senza togliere nulla al lavoro di Osterwalder, il tema è che alcuni argomenti vengono affrontati da un punto di vista monodirezionale. Quando parliamo di Value Proposition Canvas, per esempio, il punto di vista è solo ed esclusivamente quello del cliente.
Ora, in una struttura classica, dove se vogliamo, da manuale, cerchiamo il Problem-Solution Fit e poi il Market-Fit, questa cosa sta assolutamente in piedi perché nessuno vorrebbe pagare per un problema che non viene risolto, giustamente.

Il tema è che oggi il mercato non è fatto solo di queste componenti: se io penso a un power brand, come può essere un brand food, di elettronica, di tecnologia o anche di automotive, sono tutta una serie di oggetti, di elementi che noi acquistiamo anche senza avere un problema.

Utilizzare un punto di vista esclusivamente senza avere il complementare punto di vista di branding e di compagnia, ma solo ed esclusivamente legato al mondo del cliente/consumatore, rischia di perdere quella intenzionalità che un power brand dovrebbe avere.

Andare a costruire una strategia non vuol dire solo andare a intercettare un problema o un contesto di utilizzo: è anche cercare di crearsi delle opportunità dove magari queste non esistono.

Ti faccio un esempio stupido. Guardo sulla mia scrivania che è piena di roba da niente. Questo Natale mi sono regalato un flipper zero, che è un giochino tecnologico che ti permette un po' di fare tante cose inutili. Non mi risolve nessun problema, ma io lo adoro.
Questa dinamica è una una dinamica di business/marketing, anche perché questo non spiegherebbe il motivo per cui se mi serve un pennarello perché devo diventare scemo per trovare degli sharpies invece di un qualsiasi pennarello della cartoleria?

Perché c'è la questione puramente di amore per un qualcosa, di emozionale e veramente valoriale, che di fatto deve essere costruito e fa parte dell'esperienza, e se ne deve occupare chi si occupa del progetto in qualità di progettista, chi fa business.

Queste cose devono essere messe in campo. In un mondo dove il Problem-Solution Fit non è abbastanza, il Value Proposition Canvas, che per definizione va a cercare problemi e cerca di fare fit col prodotto, il prodotto è solo un pezzo del ciclo, non è tutto quanto.

C’è tutta una serie di tematiche completamente inesplorate che finché guardiamo alla cosa semplice forse va anche bene così, ma pensate a un grande gruppo bancario o assicurativo, come quelli con cui ho avuto la fortuna di lavorare per anni…

ci dev'essere quella parte di intenzionalità, perché magari quello che tu vai a costruire va a cambiare il mercato, e a sua volta va a creare nuove opportunità e va a cambiare abitudini e aspettative dei consumatori verso un qualcosa che magari oggi non c'è e che domani ci sarà.

Non parliamo qui solo di qualcosa che sia legato alla tecnologia: ci sono alcune cose che non hanno alcun senso, sul mercato, ma di fatto le abbiamo.

Avanscoperta: Ti viene in mente qualche prodotto dove questo ragionamento non è stato fatto, e si è tradotto in un grande buco nell’acqua, dal punto di vista della progettazione. Non tanto quindi il lancio, ma la prosecuzione della vita di qualcosa.

Hoang: Ci stavo pensando proprio l'altro giorno perché da poco a Las Vegas stavano facendo vedere tutta una marea di nuove tecnologie, e pensa che una delle tematiche più interessanti di questo mese sarà sicuramente il mondo dei visori, AR, VR e quant’altro.

A livello di marketing, c'è una teoria che dice che per essere definito un category king, quindi un player assolutamente bulgaro sul mercato in una categoria specifica, devi raggiungere in 6 anni il 70% della quota di mercato. Quindi tutti quelli che in 6 anni non riescono a fare questa operazione sono destinati quantomeno a correre rischi.

E proprio qualche giorno fa ero lì come un avvoltoio ad aspettare il lancio di un nuovo paio di occhiali/visori della Xreal che è un prodotto non scadente ma neanche top di gamma, un buon prodotto ma molto costoso per quello che offre, che sta raggiungendo delle quote di mercato incredibili.

Ora: dov’è che vedremo, come dicevi tu, una possibile disruption o un fallimento? Questo accadrà a febbraio, quando arriveranno gli occhiali di Apple, gli Apple Vision, quindi in quel momento lì allora questo clash fra due prodotti che hanno due posizionamenti completamente diversi ma che vanno a risolvere questo contesto d'uso… vedremo chi vincerà e chi perderà.

Da un lato sappiamo che Apple non lancia prodotti ma lancia ecosistemi, quindi al lancio di quel prodotto si aprirà un nuovo mondo. E l’abbiamo visto tutti, che quando Apple lancia un prodotto e fa posizionamento, non parlano mai delle caratteristiche del prodotto in sé e di quanto è figo. Ti fanno vedere 5 miliardi di contesti d'uso: la famiglia, l'isolamento, lo studio, la musica, i ricordi.
È quello ciò che vendono, e il valore è chiaro, mentre di qua abbiamo solo ed esclusivamente un prodotto che oggi sta facendo numeri incredibili, ma perché non c'è un'alternativa. O meglio: le alternative sono solo ed esclusivamente in termini tecnologici.

Avanscoperta: Apple sono sempre stati maestri nel creare questo tipo di mondi…

Hoang: Sì, e infatti in consulenza faccio sempre l’esempio di Apple, perché sono bravi. E purtroppo sono talmente bravi che, al di là di fare scuola, sono cose che anche su un breve-medio periodo, riesci a vederne gli effetti, e riesci a vedere come alcune piccole iniziative che loro fanno, che siano di marketing, che siano di struttura, che siano di scelte strategiche, cambiano totalmente le abitudini delle persone.

Senza entrare nel mondo della UX, faccio sempre questo esempio a ogni cliente: un iPad non è una calcolatrice. Non c'è una calcolatrice Apple ufficiale sull’iPad, ed è una scelta strategica, non di design e non è un limite tecnologico.
Vuoi fare due conti? Perfetto, ti compri un iPhone, la cosa più bella del mondo, perché ti convincono che sia una scelta tua.

Avanscoperta: Grazie mille Hoang, torniamo al corso che, come tutti quelli di Avanscoperta, avrà una forte componente pratica. Puoi anticiparci qualcosa al riguardo?

Hoang: Sarà facilissimo bilanciare teoria e pratica, nel senso che utilizzeremo un 50% di strumenti già esistenti e un 50% di strumenti completamente nuovi, e l’unico modo di vedere come funziona una Value Proposition è vederne diverse, farne, crearne un sacco.
Quello che faremo è sicuramente produrne, con brief che fornirò in aula, ma anche con quelli portati dai partecipanti, e soprattutto vedremo cose che sul mercato sono state fatte molto bene, e da questo punto di vista, applicando i vari strumenti, andremo a capire perché alcune cose funzionano e altre no dal punto vista formale.

È importantissimo capire la teoria che c'è dietro a uno strumento, nel senso che lo strumento serve a spiegare la dinamica con la quale quella cosa è stata pensata. Non è detto che il processo porti a un risultato sicuro, ma è sicuro in realtà che andiamo a minimizzare i rischi.

Tutto quello che vedremo durante il corso nasce dai 7 anni di consulenza, dove ho lanciato moltissimi nuovi prodotti servizi, e so benissimo dove sono andato a schiantare, non perché il prodotto non fosse buono, non perché le condizioni non fossero eccellenti, non perché non ci fosse mercato, ma perché semplicemente magari all’intero della struttura organizzativa qualcuno non è riuscito a giustificare il perché certe scelte sono state fatte, e questo ha portato a disfunzioni che hanno fatto saltare magari un intero progetto.

Avanscoperta: Ottimo aggancio per chiederti qual è stato il più grande successo e il più grande flop.

Hoang: Partiamo dai flop, o fallimenti: ce ne sono una marea. Il problema è che quando uno fallisce non lo puoi imputare solo alla mancanza di visione strategica o Value Proposition.

Se dovessimo invece individuare un fil rouge nei progetti che hanno avuto successo, e con successo intendo magari intere nuove banche che sono state lanciate sul mercato, sono ancora in piedi e sono cresciute, o nuovi servizi all’interno di assicurazioni storiche tradizionali, servizi completamente lontani dal loro core business, parlo di tutto un insieme di elementi che ti fanno capire come la persona al vertice, ossia quella che deve avere la visione, non necessariamente deve essere quella che ha anche il polso della strategia.

La persona al vertice deve essere in grado di comprenderla, di approvarla e di portarla avanti, ma deve essere supportata da diversi punti di vista perché una visione strategica in realtà non è solo ed esclusivamente la strada che ci porta a un possibile risultato perché l'obiettivo ci è dato dal piano industriale, ma capire, tra tutte queste strade, quante sono a nostra disposizione, quali possiamo percorrere, quali sono quelle che siamo in grado di percorrere con i nostri asset e soprattutto quelle che effettivamente non ci porteranno risultato, ma ce ne porteranno altri 1000, dopo il primo risultato.

Questo ragionamento secondo cui più si va in alto e meno le persone possono fare da sole deve essere capito e applicato da un'intera struttura e da un’intera classe dirigente che deve essere in grado di fare questi ragionamenti in maniera quantomeno simile, perché di fatto una volta che applichiamo lo stesso mindset è molto difficile che persone con estrazioni diverse arrivano a risultati completamente diversi.

Avanscoperta: Quanto è importante la collaborazione, e come facciamo in modo che questo modo di lavorare si rifletta in tutta l’azienda e nei suoi dipartimenti?

Hoang: La collaborazione è fondamentale. Non tutti sono owner delle decisioni di un certo tipo.
È chiaro che una volta che una decisione viene presa, le ragioni devono essere chiare per tutti.

Ti faccio un esempio. Se io prendo una figura di spicco, di punta, è normale che con tutto quello che rientra nelle sue competenze, questa persona magari viene spintonata e spinta a inseguire certe cose senza di fatto avere diciamo chiarezza delle priorità.
Quindi in questi termini questo tipo di ruoli deve essere aiutato da un processo che permetta loro di tenere il timone stretto.
Perché nel momento in cui rischiamo di girare in tondo, rischiamo di sprecare effort e risorse, e rischiamo che le persone che lavorano per noi perdano la motivazione velocemente…

L’unico errore che vedo è che spesso, quando parliamo di Value Proposition, ci si aspetta che alcune funzioni vengano dall'alto. In realtà non è un'opportunità che si scopre dal mercato o qualcosa che si vuole intercettare: è una scelta deliberata, e questa scelta deliberata deve essere fatta da tutto il management in maniera consapevole.

Poi può essere non coordinata o non condivisa, ma deve essere consapevole perché sennò è impossibile cambiare direzione, perché non puoi capire cosa funziona e cosa non funziona.

Avanscoperta: Quando si parla di collaborazione, sappiamo che si parla di un mondo fatto di persone più o meno tecniche, con background diversi, e con priorità e obiettivi apparentemente diversi. Come si fa a far coesistere e far andare in una stessa direzione tutto questo universo?

Hoang: È a questo che servono i modelli, che sono astrazioni della realtà e sono tutti sbagliati, anche se alcuni sono utili, come diceva George Box. Il fatto è che i modelli servono per comunicare e facilitare la trasmissione di conoscenza.

Quindi il motivo qui spingiamo sempre su framework e processi è perché è chiaro che se non riusciamo a costruire il ragionamento dietro questi razionali è anche difficile argomentare quello che vogliamo comunicare. Quindi un framework o un processo sono quelle cose che ti permettono di argomentare meglio un pensiero. Non devono però diventare la motivazione che ci guida a fare le cose, anzi: è il contrario.
È chiaro che quel minimo di struttura ti permette di livellare il lower bound del ragionamento a un livello di qualità minima accettabile.

Avanscoperta: È un tema ricorrente, anche quando trattiamo di temi tecnici: non bisogna usare un linguaggio e framework perché guidati dall’hype ma in base a quello che quel linguaggio o framework può aiutarti a risolvere.

La mia prossima domanda è: qual è il pain point più grande, cioè quale problema enorme vogliamo andare a risolvere con un approccio come quello che proponi tu con la Value Proposition Strategy?

Hoang: In maniera semplice: sapere cosa fare e saper spiegare a qualcuno perché l’abbiamo fatto in quella maniera.
Se noi decidiamo che una proposta di valore, quindi la promessa che facciamo al consumatore, deve evolvere a tempo X, a tempo X+1, eccetera, devo avere dei razionali, non può essere una scelta di pancia.

Quindi poter argomentare il perché abbiamo preso certe scelte e perché prenderemo certe scelte a fronte di certe condizioni è esattamente il motivo per cui questa parte, in questo momento, non è governata e non è adeguatamente gestita con gli strumenti di oggi. Non che non serva, per carità, servirà sempre nel momento in cui c’è un momento di crisi e hai bisogno sempre di avere una direzione chiara e un faro… è che siamo sempre stati occupati da tantissimi altri problemi, abbiamo sempre tralasciato questo aspetto e ci siamo fatti un po' guidare. Questo è quello che ho visto oggi.

Avanscoperta: Il primo workshop che abbiamo fatto con Hoang risale al 2017, quando eravamo in aula a Milano per UX Hero.
Da allora cosa e quanto è cambiato nel mondo UX?

Hoang: Il mercato ha una consapevolezza più ampia del ruolo di chi si occupa di UX. Magari nel 2015-17 questa persona era un po' a cavallo fra quello che poteva essere un product owner, una po’ una one-man band, occupandosi più o meno di tutto, ed effettivamente quello che era il ruolo reale di chi si occupava di UX e Service Design.

Oggi il mercato è più consapevole delle varie caselle nelle quali inserire le persone, ma anche perché con le nuove generazioni il set di competenze è cambiato.
Quindi quella che era la User Experience di qualche anno fa, oggi chiaramente è un po’ più relegata alla parte esecutiva: quando parliamo di touch point e dell’artefatto fisico che andiamo a progettare. Chi si occupa di Service Design si è sempre occupato della parte di servizio, quindi del customer journey, e c’è stato il periodo in cui chi si occupava di Service Design veniva chiamato ai tavoli di strategy e di business.

Oggi ci stiamo un po' raffinando da questo punto di vista, anche perché le competenze che stiamo chiedendo a questi ruoli ormai si stanno molto specializzando, quindi accade che alcuni ruoli trasversali, come può essere quello del product owner, è un ruolo estremamente versatile che può accomodare diversi tipi di ruoli al suo interno.
In questo specifico momento il mercato è cambiato. Molto spesso chi fa parte di un team di innovazione, che per esempio deve lanciare nuovi prodotti o nuove linee di business, deve essere in grado di avere una visione a 360° di tutte queste discipline. Che poi queste vengano racchiuse sotto un certo cappello o figura professionale piuttosto che un’altra, questo è irrilevante.

Ciò che è certo è che non possiamo più permetterci di avere angoli ciechi su certe tematiche.
E se ti ricordi, ai tempi, quando parlavamo di UX, era un termine ombrello che racchiudeva una marea di altre discipline: dall'accessibilità all'usabilità alla ricerca… un po’ di tutto. Per fortuna il mercato si è evoluto.

Avanscoperta: Torniamo un attimo sulle persone a cui vogliamo rivolgerci con questo workshop. Ne abbiamo parlato brevemente all’inizio ma forse alla luce della discussione che abbiamo avuto vale la pena tornarci brevemente.

Hoang: Sicuramente tutti coloro che per un motivo o per un altro si sono innamorati del Business Model Canvas come strumento, quindi hanno capito il perché un certo tipo di strumenti esiste.
Queste persone sicuramente vanno a disegnare modelli di business, una parte iniziale della strategia o del customer journey.

Quando penso a queste figure, che sono figure di gestione, di management di prodotto o di marketing, sono tutte persone  che devono in qualche modo gestire, progettare e razionalizzare le evoluzioni di qualcosa che hanno creato.

Quindi una Value Proposition Strategy ha poco senso magari per un brand che ha 30 anni, perché già consolidato. Ma se penso a tutti i brand devono essere riconvertiti, per cui si aprono nuove linee di business su nuove industrie, oppure se penso a spin-off o servizi correlati a qualcosa che magari già esiste ma che di fatto si sta espandendo, su un nuovo tipo di prodotti o di target… Anche perché i messaggi che noi mandiamo a me e te, che in realtà siamo super boomer rispetto a quelli che hanno oggi quindici o vent'anni, sono talmente differenti, quindi non avere un pensiero dietro e sperare nel seguire il mercato non è il male… è semplicemente la cosa più rischiosa che possiamo fare oggi sul mercato.
E oggi prendersi il rischio di farsi male ovviamente non aiuta la cultura del fallimento che abbiamo in questo paese.

Avanscoperta: Un mondo molto diverso da quello in cui siamo cresciuti, pre globalizzazione, in cui bastava davvero solo un’idea vincente. Chiaramente non è più così.

Hoang: Prima o poi tutte le cose innovative diventano commodity. Oggi abbiamo il boom dell’intelligenza artificiale che tra qualche anno sarà commodity, così come abbiamo tantissime banche, app di pedaggio, app di pagamenti… tutte le cose che sono innovative sono destinate a diventare commodity.
Quindi questo tipo di transizione è un tipo di transizione che deve essere governato, non può essere il mercato a decidere per noi al 100%.

Avanscoperta: Vogliamo salutarci con qualche spunto extra per i nostri spettatori e spettatrici?

Hoang: Un video e un libro. Il video, un classico, è di Daniel Kahneman il guru massimo, chiamato Experiencing Self and Remembering Self. Si parla della differenza tra esperienza vissuta ed esperienza ricordata. Questo è uno dei punti fondamentali, sui quali giochiamo sul valore. Il valore del momento è puramente utilitaristico, ma è con la memoria che queste cose diventano veramente interessanti e rilevanti per noi, quindi è questo lo spazio di progettazione dove andiamo a lavorare.

Il libro, invece, se vi interessa qualcosa di abbastanza nuovo, mi è piaciuto moltissimo questo libro di Felix Oberholzer-Gee, professore di Harvard, chiamato Better Simpler Strategy. Parla di come fare strategia in maniera semplice e veloce nel mondo di oggi con quattro-cinque principi che sono estremamente di valore.

Cover photo: Lucas K su Unsplash

Small Talk con Hoang Huynh: il video - il podcast.

Learn with Hoang Huynh

Hoang è il trainer di Value Proposition Strategy Workshop.

Vuoi continuare a leggerci? Iscriviti alla nostra Newsletter 📩 (disponibile in italiano e in inglese).
Ti faremo compagnia ogni venerdì mattina. ☕️

La lista completa dei nostri corsi: Avanscoperta Workshops.