Eventstorming as a cultural probe

Eventstorming is an amazing technique/tool invented by Alberto ‘Zio Brando’ Brandolini to investigate a software process, which I also use to investigate an organization’s culture. I wrote this article to introduce a video in which I describe some Eventstorming nuances I had the chance to play with on a few real customer projects.

Event what?

Eventstorming was born as a workshop-based method to quickly find out what is happening in the domain of a software program. Compared to other methods it is extremely lightweight and requires intentionally no support from a computer. It drives the participants into representing with post-its all the events that one can see happening in a process—in an organization, in a team or in a software—and then play with them, by adding all the commands, the systems and the policies that are in between.

For the sake of brevity, here it’s just important to focus on the importance of policies, as they are the reason-why behind any action performed in a process after an event occurs. E.g. event: “I received an invoice”; policy: “happy suppliers”; action/command: “I order a bank transfer”.

A growing community

In July 2018 I had the privilege to attend the first Eventstorming Summit organized by Avanscoperta, meant to gather all key Eventstorming practitioners from any corner of the world, in order to discuss and exchange ideas on how to use this amazing technique/tool.

During those few days, a lot of different Eventstorming ‘flavors’ emerged. It was very interesting to listen to all those very skilled professionals and understand how subtle differences in their context could result in such a deeply different interpretation of the tool itself.

In this video, I share my 2 cents about one Eventstorming aspect I find very powerful.


My best Eventstorming ever

Last spring I worked with Zanichelli, one of the biggest Italian publishing companies in collaboration with Raffaele Boiano and a few friends from Fifth Beat. Zanichelli’s need was to map, analyze and improve the publishing process that brings the abstract idea of a new book to its tangible printing.

Many people, with a diverse skill set, lots of experience and several decision scopes, working together to pursue a common goal, all looking for some clarity in the tangled mess of their workflow. Potentially a mess to understand, but it was a perfect job for Evenstorming!

People participating in Jacopo's eventstorming workshops

With Raffaele, we set up a row of Eventstorming-based workshops to extract all the pain points, so that it could be possible to spot, share and fix them.

We saw people who had begun the day with a “this is not my job” attitude turning into team players aiming to better involve colleagues with other roles in their own decision making. None of the six teams we met was like the other, but Eventstorming fitted all of them, at the same time helping to disrupt a silo-based mindset.

Join the community!

This is just a short article by which I aim to raise more questions rather than giving answers. I hope it triggered your curiosity! Feel free to contact me to know more about it. You could be the next practitioner to join the summit and explain your Eventstorming flavor! This is just the beginning. Eventstorming is still young: who knows what we will find down the road?


Late acknowledgement of a late acknowledgement

In last Steve Denning’s article on Forbes titled “Can The 21st Century Corporation Operate Without Agile?” we read:

The new industrial revolution may be enabled by technology, but it is not being driven by it.


Trying to exploit digital technology or the Internet with the management practices of hierarchical bureaucracy that is pervasive in big corporations today is like driving a horse and buggy on the freeway. To get beyond this horse-and-buggy management, and into something more relevant, managers need Agile.


These are however the results of Agile management, not the drivers of the new industrial revolution.


The new mindset begins with a focus on continuous innovation and the future. It believes in banking, not necessarily banks. It believes in accommodation, not necessarily hotels. It believes in transport, not necessarily cars. It believes in health, not necessarily hospitals. It believes in education, not necessarily schools.


What is lacking is a recognition that the Agile way of running an organization constitutes, not just a random potpourri of management practices being driven by technology. It’s a coherent self-reinforcing system of leadership and management thinking that is driving the technology for the benefit of the customer.

It has been already years since the world of mainstream management realized agile is not just a tree-hugging bandwagon – assuming we don’t really need to hug more trees to solve a bunch of real problems – and this blogpost doesn’t have the aim to show you anything unexpected. But still I have been beating the agile track since 2003 and it is so rewarding to see Forbes acknowledge the value of a path that, well… was mine too.

Ad maiora.

How loss aversion killed the turkey

Do you create new products and services under conditions of extreme uncertainty? Do you think any contract will make the project more likely to succeed? Are you even an employee? C’mon, don’t be a turkey! Yes, a turkey!

I had this blogpost in progress for a long time. A few weeks ago a tweet by Nassim Taleb – along with the essay attached – made me think of it and so… here it is.

You shouldn’t feel too safe

You know how turkeys’ life is in the USA: they get fed for months, they get every attention throughout the summer. They feel care, trust and don’t even suspect what is going to happen by the end of October! Their expectation about a life of luxury and obsequious homages gets ruined by an unexpected event: Thanksgiving Day. And the hand that fed them now kills them. That may sound sad for humans, especially for vegans, but sure that sounds tragic to the turkeys. What’s even worse is that they get no clue about their own destiny by the evidences that were available throughout their life: the story told by the past has nothing to do with how the story ends. Unknown unknowns kick in.

Would you really trust someone feeding you for free everyday of your life not killing you in the end? I wouldn’t! As humans, though, we don’t usually perform better than turkeys! Despite our intellectual advantage over turkeys, we still tend to overestimate losses while underestimating potential gains of the same value. That is called loss aversion bias. As a species, humans have developed this bias to better cope with an environment characterized by scarcity. It must have been very hard for our ancestors to get their goods, so preserving them must have been more valuable than the willingness of accepting the risk of getting new goods.

That loss aversion, sometimes, makes us stick to a warm safety feeling instead of exploring new chances for better gains.

Valueable value

Turkeys put aside for a moment, now please consider lean thinking and lean management and their very aggressive definition of value. According to those mindsets value is what is worth the customer’s money or the user’s time. All the rest is waste. If you start thinking out of the box, wondering what elements of your job truly add value, the least that you can find out is that many of them just don’t. Are you moving partial deliveries around? Are you reprocessing deliverables to correct defects? Are you waiting for a contract to be signed off? That’s waste, not value. Simple as that.

I decided to write this post when I asked this very easy question to the people I am in touch with on Twitter and Facebook:

Do you think a contract can raise your chances to succeed in a project?

For the sake of simplicity I just meant a project “successful” if all the stakeholders, the users, the sponsors and – last but not least – the suppliers are happy for what they get in exchange for they give. It doesn’t necessarily relate to deadlines, but it could. It doesn’t necessarily relates to clarity of requirements, but it could. It doesn’t necessarily relates to money, but well… usually it does! 🙂 All in all, I don’t even mind having a perfect definition of a “successful project” here. Whatever your definition, I was asking myself if a contract may add value to the development of a product or a service as much as the time we spend every time in thinking, writing, agreeing on, signing and sueing around it.

I received a lot of replies.

Don’t be a turkey!

Not surprisingly, most of the people blatantly ignored the true question, replying about the safety feeling provided by a contract.

It can raise my chance to get a meal.

was the first open-hearted and sincere reply. To tell the truth, though, my question was about how a contract may help making things go better and not how it may undoubtely help in case everything goes so wrong that we need to call the lawyer. Still the success of a start-up has nothing to do with how we’ll manage its final failure.

Back to the definition of value used in lean thinking, if we were in the F1 racing business, it’s as if we cared more about the pilot’s helmet than the engine’s power. The story of car racing shows that safety is a compliancy issue, not a performance one: no car racing team ever won a race because of the helmet. Also, and that is very important, when working for a start-up we aren’t likely risking our life but just a finite amount of time/money.

“That amount of time/money is what I live by!” I hear you say. Sure! You are right! But only a turkey would go on working until the day of its death with no real feedback about the true quality of its working relationship. And usual contracts provide no feedback at all! They just help you minimizing damage when you are already in a mess or at best when more or less expected problems start popping out of the horizon! A contract provides no defence against unknown unknows! As Francesco perfectly stated replying to my question:

A contract may save you […] if the projects fails the way you had planned.

Among the best replies, Memi’s one pointed out how safety creates room in his mind to focus on his customers and their projects, thus – in a sense – creating indirect value. I may agree with him, since knowledge work is a tricky one, depending on many soft variables. But still this is indirect value. We are still assuming here that the helmet will primarily make the racer win, by making him feel safe, while drivi… well… I’d invest more in the engine, you know?

There is more. If we accept that we need safety to create an environment in which we can foster value creation, then why don’t we find better ways to provide that safety both to ourselves and our customers instead of just a piece of paper?

How can a contract reduce the need for estimates?

You are going to meet a customer tomorrow. You will discuss about developing a new product. You know she will ask for a bunch of features, a deadline and a budget. She will ask for estimates.

You have developed products since many years ago, maybe 5, maybe 10, maybe even 15 or 20 years ago! Through all this time you have learned many things and one keeps on popping up into your mind every time you are preparing a meeting like this: estimates are a loss of time.

  • You know they won’t add any value up, because no product will ever generate value out of an estimation rather than out of the best set of features and an amazing user experience.
  • You know you will have to spend precious hours – usually days – to complete a full estimation round, because details will keep on emerging and it will be hard to know which ones are worth the attention they ask for and which are not.
  • You know you could generate more money if you could spend those days working on the product itself, to get to deep insights and learning as fast as you can.
  • You know you could spend those days working for other costumers, which are now foregone opportunities.
  • You know the request for estimates will lead to positional bargaining. Trust and chances of an healthy collaboration will fade away while the customer defends her capital of money – trying to depreciate the value of your effort – and you defend your capital of skills – trying to raise the estimate with a safety buffer.
  • Last but not least, reality will just… change, invalidating your estimation.

All in all, there is no other chance with fixed price or time & materials contracts: both parties have to agree on an estimate to fill in the gap of trust existing at the beginning of a collaboration. In the traditional context, contracts relying on estimates are a replacement for true trust.

It would be lovely if we could build a climate of collaboration and test it very fast. It would be even better to have some value – some real value – delivered to the customer in the same amount of time we would burn to estimate and quote the whole project. It would be perfect to have the customer say: “hey, you delivered more value than I expected and I can pay for it after this trial”.

Consider the typical conversation:

  • Customer: “Hello, I need this”.
  • Vendor: “What do you mean with ‘this’?”
  • C: “I mean this, this and that”.
  • V: “Uhm… we need to talk about the details for the next 5 days.”

Now imagine if we could turn that conversation into the following one:

  • Customer: “Hello, I need this”.
  • Vendor: “What do you mean with ‘this’?”
  • C: “I mean this, this and that”.
  • V: “Uhm… let’s talk one hour now. I will build something to start validating your needs and be back to you in 5 days.”

We could then start working for no money for a few days, deliver something and then check with the customer if our delivery is truly valuable. If it was, we could be paid and just… restart again: discuss needs, build something, validate the assumptions, get paid.

In high volatility scenarios this would allow for knowledge to build up, with a great momentum and minimum commitment for both customer and supplier. This would allow to allocate the budget

  • only on the next learning step
  • only a posteriori, having already learned something

The customer’s only rule would then be: if I only pay for the (n-1)th step, it is perfectly fine to wait for the n-th step to be completed for free!

Should we get rid of planning then? Well… maybe not, maybe yes. It depends on the value it delivers. As long as it helps the team anticipating known unknowns thus preparing the team to react to unknown unknowns, it may keep some value. Sure though we could ease the dependency of any collaboration from any upfront estimation. If we became able to release value frequently then we could experiment and learn with some tactic to get rid of the need for estimations.

Extreme Contracts were also meant for this. Check them out.

Make yourself a valuable employee by measuring your Net Promoter Score

As a freelance I often face the request to report about my delivery, to assess the effect of my actions and suggestions. During my years spent as an employee though, I learned to ask my colleagues for an assesment with the aim to become more valuable to them. If we all agree business must be user-centred, then why not being user-centred when working as an employee too?

Feedback is paramount

I have been a developer and then an entrepreneur well fond of agile methods since 2004. Through the practices described in Extreme Programming I have learned that feedback is a value. All the agile body of knowledge is based on this: no matter where you want to go, to get there you need to know where you are. Without exception.

Net Promoter Score

A few years ago I started a pleasant working experience in eBay Classifieds, working with the regional italian team based in Milan. During those years I have learned a user research technique called Net Promoter Score (NPS), a surveying technique which I ended up appreciating a lot.

Basically the NPS is one single end-to-end strongly value-oriented question asked the customers about the service or the product you are selling to them:

How likely are you going to suggest [our product/service] to friends and relatives?

Katia, the product manager which was at that time on her way to move and join the canadian eBay Classifieds team in Toronto, left her handbook about NPS to me and I got the chance to deepen my understanding of the technique. I immediately loved it because it doesn’t start the analysis of the user experience through a pre-packaged mindset – embedded in a number of questions. It leaves instead the first feedback to be gathered by a single, all-comprehensive, all-round question which allows for structures, for the mindset of customers to emerge.

Performance appraisal

When I started working as an employee I expected to meet some yearly performance appraisal procedure and I was not wrong. Neither was I wrong about one thing I already thought: performance appraisal is flawed.

Assuming that it should be measured at all, individual performance always ends up being measured on a subjective basis. Everywhere I saw it measured, I regularly saw rational and objective criteria being spoiled by subjective and personal judgement. Let me be clear: I am not saying it was sistematically intentionally spoiled by evil managers. I am just saying that even the best intentions of the mildest person fail to deliver a good evaluation if they are just driven by an evaluation grid, no matter how sophisticated the grid.

  • A grid must be decided upfront, which is hard to do, especially with newcomers.
  • A grid hardly fits all the profiles a company has to cope with, no matter how fine is the grain of its parameters.
  • A grid defined upfront is not robust against reality checks: what if an employee starts delivering lots of value in a direction and in a way initially not expected?

These flaws, no matter the company, no matter the good intentions of managers involved, always lead back to a late guts-based reshaping of the performance appraisal parameters, goals and procedure. What was built to describe people’s performance with distance and democratic coolness becomes dominated by gossip, confirmation bias and backward looking metrics again. Fail.

Working around performance appraisal

Flash forward, left eBay but still working as an employee, during the spring 2014 I asked myself: “Do I want to know more about how my value is perceived by my colleagues?”. Yes. “May I consider myself a service provider within a company? Do I know any nice way to evaluate the value perceived by service or product users?” Yes and yes. If my performance appraisal must be necessarily biased, I thought, then why not to include and integrate those biases once and for all in a single end-to-end user-oriented question meant to catch all the nuances of my value delivery within the company? Sure the answers will still be subjective, tainted by prejudice and altered by fondness but at least they will be cheap to get, open to unknown serendipitous implications and continuously matching the shape of the real value delivery.

Asking THE question to your colleagues

All in all how much could I be sure of being of any real value to all the colleagues I was working with month by month? This is was the question, the only one worth asking for, and I decided to ask it every 30 days to all the people I had worked with.

First release

I created a Google Form with the very basic question:

How likely are you to recommend me as a person to work with?

and I started sending the link to the form every month to all the people who I had had the chance to work with during the previous month, no matter the role, no matter the task. The people contributing with their answers were asked no name, no further data, no further details. They could sharply assess my value contribution with a very short question, while protected by anonymity.

At first it was only the bare minimal question but very soon I added an optional second question only asked in case the main rating was below 7. This question was expressed more or less this way:

What could I do differently to bring your answer to 10?

My aim was to play a perfection game upon myself. Being focused on my “customers and users’” feedback, I decided to shape my improvement as an employee around the feedback coming from my colleagues. Later on I realized that giving them no chance to provide me with an open feedback in case of high rating was keeping an important set of information hidden from my eyes. I realized I needed to know what I was doing right as well as what I was doing wrong. So I made the second open question available to all the people who answered the first one, no matter the rating given. The second question became:

What’s the rationale for your rating?

[Here you find all the ratings and comments, except for confidential excerpts and data.]

What I learned

I have run this exercise for almost one year and I learned a lot, about my colleagues, about organizations and, you guessed it, about myself.

Continous improvement of value delivery

Every month I had the chance to question my own status quo, assessing in a very simple way whether I was truly helping people around me. Simple requests like:

more concreteness in the followup after being engaged in some activities

or like

Help me to receive the strategies of the company, decisions, and be more involved not only if I ask […]

were very helpful in shaping my work, month by month, day by day.

I came to love the end-to-end nature of the question. It encapsulates all the aspects of value delivery: was I using the right skill in the right place? Maybe. Was I skilled enough to be helpful? Maybe. Was I communicating achievements thoroughly and clearly? Maybe. Was I conceiving value itself in a way compatible with company’s values? Maybe. The assessment I was performing more or less every four weeks was taking care of the whole pipeline and this was returning a dramatic insight.

Walking the talk

I have developed software for years, for more than 2 decades. Since 2004 I have practiced agile software development and I have always faced the problem of bringing people with me along this path: friends, business partners, colleagues, audiences, not to mention coachees and customers. As always, trying to change people’s behaviour induces some amount of resistance and I learned that doing in first person what you ask to do is one of the key change enabler. Thus I have always asked people to start writing automated tests, but I wrote them first. I proposed to practice Test Driven Development, but I have always coded this way on my own. I started questioning the way we write contracts and in the face of skepticism I experimented with my own company first.

So it felt perfectly natural to me now to start asking for a different feedback about myself as an employee, to directly challenge the status quo of performance appraisal. Once privately deployed this kind of informal, anonymous and comprehensive assessment about myself, no one anymore could argue it was a request made with no skin in the game. Performance appraisal could suddenly be discussed on a wider level with no protections from ivory towers.

Improved peer-to-peer reputation

When I started and continued to ask for my NPS, people saw I was exposing myself to their own judgement. I had everything to lose. My reputation could be vandalised by anonymous colleagues on the mere basis of aversion but this simply didn’t happen. All the colleagues participating month by month provided me with honest feedback, not always positive, but never violent and never unnecessary.

It is amazing how raising the stakes about yourself and showing that you are playing with your skin in the game makes everyone more respectful and explicitely aware of your presence in the same company. That made me feel good for sure, relying on a network of ongoing real human relationships, instead of being just a set of numbers in a goal grid. Even my boss, who would have later expressed doubts about the value of our collaboration, had to score this as a point on my side. This leads to my next point.

Stronger position in negotiations

When the first six months had passed, I could rely on the first bunch of collected feedbacks to extract some information about my trend. Was I improving? Was I not? Along with my personal NPS data, the company was going on evaluating my performance as usual and everything was under control, with a clear demand of value and a “good” performance – according to their metrics.

After other six months things had changed. The layout of the organizations had changed and my role became less defined, spread on too many fronts and my value less evident to my boss and his boss. It was not clear what the demand from the higher levels of the hierarchy was and I started to feel uncomfortable with the situation. I eventually decided to negotiate an exit from the company.

Still though, my NPS kept on rocking, stating loud and clear that people working with me side by side, no matter the formal hierarchy, they were all acknowledging the benefit of working together. Sometimes they were expressing some legitimate critics, but not absolutely denying I was a valuable colleague. Indeed, those real time critics were validating my whole NPS thing.

That result, more than the official appraisal metrics – according to which, by the way, I was still a good performer – was the key for negotiating a good exit from the company. Once again collecting data, even just gathering opinions in some structured and continued way, proved its amazing effectiveness for providing arguments in tricky times.

What I’d do differently now

I have asked myself what I’d do differently if I was to repeat this experience, or better, when I will repeat this experience. This is what I thought:

  • Maybe I’d let the chance to sign the feedback. Sometimes I would have loved to ask to someone for deeper insight, for a more articulated opinion, to make me better understand their point of view. I don’t know what I would exactly lose with this. Maybe people would feel forced to provide their name anyway, in spite of the optional choice, and this would cause a drop in participation. Maybe people would be afraid to be the only one not signing, eventually exposing them anyway. I don’t know and I wouldn’t without trying for real. If I will ever do it I will let you know 🙂
  • I would publish the collected answers month by month, in order to raise the awareness of this operation as a whole team. I think it would have induced more people to join me and would also have reinforced the open culture I was instead fostering alone this way.
  • Public or not, I would allow my boss to read my NPS data, maybe even upper managers. I think it would have provided them with some real time idea on how to fine-tune their demand instead of waiting for an entire six months before starting discussing my delivery. When official appraisal arrived, it was too late. Having had my colleagues’ feedback in their hands would not have necessarily meant they agreed, but at least it would have triggered the meaningful conversation that were needed to fix the collaboration before it was too late.

In the end

Please beware: I am not saying that NPS is enough to prove the absolute quality of your work. I am just saying that it is cheaper and better shaped than any other mainstream performance appraisal technique I met. It triggers good conversations because it focuses on the way you contribute to the team action with least assumptions upfront. When proper conversations are in place, the need for assessing performance vanishes away. If you really can’t stay away from performance review, ifyou really have to perform regular appraisal, this is my proposal for a better way.

What I would not do any differently? Gathering feedback. A lot. Always.

Whenever I talk about feedback systems with a new team, usually someone exposes her concern about two aspects:

  • Won’t the feedback gathered be too much and overwhelming us?
  • Won’t gathering feedback be too costly?

Both concerns deserve the same answer: if you try and learn from your experiment, you also learn how to keep the feedback data cheap to collect and meaningful to read. If feedback is cheap, then it will never be too much.

How are you going to improve the feedback about yourself starting from tomorrow morning?

LEGO Serious Play facilitation training: mission accomplished.

On May 8 I joined Juego Serio, Sparkling Strategies and Cocoon Projects in Barcelona to attend a LEGO Serious Play (LSP) Facilitation training. I had been waiting that moment a lot.

I met the method in 2013 when I had the chance to help my friend Stelio facilitating some LSP- based workshops designed by him. With those few kickstarting experiences the power of LSP had just shown a part of its potential, but definitely enough for making me eager to know more about it. I had been facilitating meetings and workshops for 10 years at the time and this looked like the most powerful facilitation method ever met.

Release early, release often. #wip #wiplimit #sagradafamilia #barcelona #españa #trip

A photo posted by Jacopo Romei (@jacoporomei) on

A versatile technique

LSP is a great envisioning method and I loved the way the facilitation training was held: we mainly ran LSP sessions with Lucio Margulis, one of the few LSP facilitation trainers in the world. He gave us a strong theorical background while using LEGO Serious Play to outline all the main LSP facilitation concerns and showing us both usual facilitation patterns and his own skill in action. He proved to be able to ask very powerful questions. It was amazing to stare in silence at how deep the analysis of an apparently easy subject could become. I saw people talking of their aspirations, their assumptions about the context we were working in, their tentative solutions and I even saw people break out in tears.

Squeezing value out of people

The best feature of LEGO Serious Play by the way is not just using LEGO on job – which is actually the very reason why most of the people are curious about it at first. The best of LSP is gracefully forcing each person attending a meeting to formulate, express and share her thoughts on the meeting’s subject. All of her thoughts about the subject. Even the least fair, the most uncomfortable ones.

Have you ever been in a meeting? Sure.
Have you ever seen a meeting in which 2 people out of ten talk all the time? Sure.
Have you ever seen a meeting in which, while 2 people don’t stop talking, other 4 just nod (?) and 4 chat on their smartphones? Sure.
LSP puts an end to this.

What does that mean for an enterprise? For a team? For a non-profit org? For a board?

Mainly two things:

  1. Serendipity is a powerful mode which to let happen things by. Exploring the deep thoughts about a strategical issue in each single head is going to surprise you. Moreover, those surprises will be very focused on the whole team goal.
  2. Making everyone’s ideas about a topic is an investment in clarity. No one will be honestly in condition to say ‘I didn’t understand we were about to do this’ or ‘I did not agree. This was your decision, not mine’. No one anymore. The range of alibis in use in a team using LEGO Serious Play is mercilessly destined to narrow down to zero.

I am already using LSP in my workshops and coaching sessions. I just started to walk along my path to LSP mastery. Will I meet you along the road?

I grandi consulenti secondo @meedabyte: squali, morti e sciacalli. #epicwin #LSP #barcelona #españa @LSPMed

A photo posted by Jacopo Romei (@jacoporomei) on

#NoEstimates: knowing the difference between an estimate, a forecast and a promise

A few weeks ago I attended a NoEstimates workshop held by Woody Zuill and Vasco Duarte in Helsinki. It has been an intense and fruitful day and here is the main insight I brought back home.

The day was led with a very nice pace, the two speakers showing a very different style in explaining their ideas. Their continuous turnover on stage made the workshop very light to follow though packed-up with contents.

The concepts explained during the workshop resonated a lot with what I have discovered through the years about planning product or software development: an estimate is not a promise and both are not a forecast. The first two are quite unhandy too.

According to Merriam-Webster, an estimate is

an opinion on the nature, character, or quality of something.

forecasting is

to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data predict

while a promise is

a statement telling someone that you will definitely do something or that something will definitely happen in the future

Well, that’s enough to spot a linguistic abuse: we are always asked for an estimate, thus for an opinion, while we are committing to a promise and no one cares enough about forecasting – if any useful at all.

I would recommend this workshop to anyone willing to get out of the big bubble lie “sharp estimation is the key factor for success”.

The whole IT thing is about talking to humans

It was only yesterday that I incurred into this old tweet by Kent Beck:

This message resonates with many reflections I have been through lately.

Tree huggers

First, this made me think of all the comments hard core programmers do about the people trying to fix dysfunctional teams, or better: trying to fix dysfunctional IT teams. “What is this? Psychotherapy? We just need more unit tests!” is just an example of the comments I read and heard about people trying to address the problems of a failing team.

Unfortunately, if we agree on solving problems with the right tools, people problems can’t be solved with solutions meant to fix programming problems. That’s easy like that.

Sure, adopted solutions must be evaluated too and it may happen that some get a bit over the line. Sure, we don’t need – and can’t afford – 10 years of psychoanalysis to deliver our next project. Sure, many are trying to oversell the tools they just know about to fix a broad range of problems which may just be too broad.

But please do remember: people problems are to be addressed with people solutions, be it a user requirement, a collaboration issue or a learning resistance.

Programming languages are for human beings

This is a topic which once in a while brings the teams I am working with to an a-ha moment: programming languages were not invented to talk effectively to machines. Programming languages are meant to bring people on the same page in the cheapest way when facing a programming problem.

Amazingly enough the tweet by Beck is a perfect brief reminder for all of us. Programming:

  1. Starts with understanding a set of requirements (people’s needs)
  2. Making them clear to a bunch of developers (people needs!)
  3. Turning them into working software crafted by a group of professionals (OMG people again!)
  4. Validating the deliverable with all the stakeholders (I. Can’t. Believe. It. This is people again.)
  5. Finally satisfying the needs we were starting from, by making our tool clear and easy to use to users (peo… ouch!).

Programming languages are a tool to help with step 3. Sometimes with steps 2 and 4 too.

If programming languages were optimized on the machine side of the human-machine relationship we would all be writing assembly code today, OK?

Linguistic skills are the key skill for a team worker

The third thought triggered by Beck’s tweet is about linguistic skills in developers and, more in general to all team workers.

If we understand that innovation bottleneck is learning, then we must agree that talking and communicating the slightest nuance of meaning is a key factor when learning together with a group of co-workers.

If we agree that a team is built around a goal – and maintained around a vision, then we must agree that fostering cohesion with the right conversations is a key skill for all the people belonging to the team.

Thus, if we want our conversations to be effective, we must recruit people with good linguistic skills. If we want our conversations to even be efficient, we must recruit people with great linguistic skills.

I have no doubt on this: when hiring a new coder I am willing to trade some of their hard skill for a very good linguistic skill. You think what you talk, you talk what you think.

I am back from XP2015

It has been an intense May and among the several nice things happened to me I had the chance to attend XP2015, in Helsinki, to talk about LiquidO, the open governance model shaped within Cocoon Projects.

The XP conference series is among the top conferences worldwide about agile methods and lean thinking. What do I bring back home from this event? Mainly two impressions.

Split community

The first one is about the paths agile methods have followed along the years. I wrote “paths”, plural, because I see more than one.

On one hand I see people involved in a grassroots movement made of user groups, code katas and code retreats but also made of non-coding communities of practice: agile coach camps, agile UX events, lean management gatherings and so on.

On the other hand I see an academic world trying to formalise the whole agile body of knowledge, still looking for the ultimate metric, for the one-size-fits-all step-by-step handbook or for the finally business-agnostic way to analyse the dynamics of a team leading you to a guaranteed success.

While talking with an academic who had just presented his paper about refactoring automated analysis tools, he asked me: “what do you mean with ‘code kata’?”. I don’t have an exact idea of what it is right or wrong, but the impression here is that we have a split community: those who are learning to surf by surfing and those who are trying to learn surfing by describing the whole physic model of a wave with a surfer on top.

How many papers about surfing can you write before becoming able to surf?

Sorry. Agile processes are not formal. But do read Kent’s book, mines, and Jim Shore’s.

— Ron Jeffries, June 2010 [1]

One community

The second and best impression I bring home with me is the one about the community I am in. Actually, the community I am the centre of.

This is not to say I am any important, indeed this is to say I love my network of contacts, made of people who listen from and explain to me. Year by year this network grows stronger and larger – which are not the same attribute – generating opportunities and providing crucial validity checks.

It was amazing to meet good old friends, to meet new ones and consider the chance for new collaborations across geographical and cultural borders. From India to USA, from Finland to Italy, we are all trying to uncover better ways to deliver value with one final aim: happiness.

For taking part of this endeavour I feel grateful to each one of you. Thanks!

[1] Source, my first comment [ITA] and a comment about my comment.

Agile Contracts workshop in Bologna on June 23 2015

After the rewarding premiere held in last March, on June 23rd I will be holding again a full-day session about agile contracts in collaboration with Alberto ‘Zio Brando’ Brandolini’s Avanscoperta.

It is going to be a very important day for me, considering the chance I am having to re-think the workshop based on the super precious feedback I got after the debut. On one hand I have a better feeling as the date approaches by, considering the positive feedback I received. I was pretty nervous that morning, I had waited that day for years. On the other hand I will strive to treasure the negative feedback I got, mainly about the expectation for even more games! 🙂

I will do my best. Good news already: I will introduce LEGO Serious Play in the workshop after having completed the facilitation training in Barcelona on May 11th!

I. Can’t. Wait.

People talking extreme contracts, people using extreme contracts

After the chat I recently had with Greger Wikstrand about Extreme Contracts, another nice video was made by Greger with Joakim Lindbom, both Enterprise Architects from Capgemini. In the video they discuss the nice behavioral and economical patterns emerging with the use of such contracts which I forged a few years ago when I was coaching e-xtrategy‘s team.

It is rewarding to see how e-xtrategy still keeps on using those contracts after years and, at the same time, seeing Greger, such an experienced person in enterprise software development, being so interested in them along the years.

e-xtrategy, Greger, thank you all: you are the best incentive to look for better solutions everyday.

I will also be talking of Extreme Contracts in Bologna next June, during the Agile Contracts workshop.

Now sit back, relax and enjoy the show! 🙂

Extreme contracts and immediate rewards – Architecture Corner, episode #13 from Casimir Artmann on Vimeo.

Extreme Contracts

The goal

As I wrote some time ago, we want our deals to be compliant with three main criteria:

  • We want to reach a wise agreement, in order to generate value for all the parties involved.
  • We want the deal to be efficient, because time spent searching for a good deal is not generating value: it is pure waste. This implies simplicity. We want the rules to be simple.
  • We want to keep a good relationship with our counterpart over time. Exploiting agreements are fragile, with those people continuously trying to escape towards better conditions if not trying to cheat in first place.

The rules

Extreme contracts are meant to be simple and address all the criteria we want to use to define a good deal among all the parties involved.

Just three rules, everything follows as a side effect:

  • Very short iterations, usually one week.
  • A flat fee for every iteration.
  • Money back guarantee.

That’s all.

The (short) story.

The customer express her needs. A team is set up to address those needs. The team starts working on analysing those needs and one week after delivers anything they think worth the fee. The customer evaluates the deliverable and has two options: accept the delivery and pay the flat fee; reject the delivery and keep the money.

If the customer accepts we repeat this short story one more time. If the customer rejects we can either stop the collaboration or try to run another iteration, maybe – but rarely – after having agreed on a different deal about iteration length or price.

The chat with Greger Wikstrand

On Apr 07 2015 I had a Google Hangout with Greger about this kind of contracts, willing to get his raw feedback. Enjoy our video!

Dream of your build & build your dreams

Tonight I dreamt of Giorgio and Danilo. They were ticking me off. They were upset. The build was broken and they had just found a bug, introduced months before by me while refactoring some remote legacy area of our codebase. They were speaking words of reproach about how hard it would be to fix the bug now, being that code as legacy as untested code can be. They were blaming on me because I had introduced a bug in a hard-to-manipulate area of the code. How hard would the fix be now? Why, should I have ever refactor that untested code at all?

Just a few moments before waking up – or so it seemed – that apparent nightmare turned back into a dream: I had just committed very few lines of code at once throughout my refactoring thus it was very easy to backtrack my code change, get a very clear view of it and revert it. I got the solution, we learned a bit about our legacy code, thought I still kept my reproach.

Flashback to a few years ago.

I was refactoring a huge legacy codebase. The company I was working for had very very very very high maintenance costs due to the age of their codebase and the proud absence of automated tests. I wrote ‘proud’ because everyone was aware of the mere existence of automated testing technology but no one was even trying to introduce the benefits of automated testing in their daily life: “eh”, they kept on saying, “someone should do it sooner or later”.

I decided to do it.


The problem with nasty legacy code is that often you have to refactor it before you may even consider introducing automated tests. That requires developers to be very careful performing very small step-by-step refactoring to work their way to the first automated tests. In that case it was even worse. (Legacy) security measures used to prevent bots to hijack the (legacy) web interface was making my job harder than hard: it was impossible to put some end-to-end testing in place, my usual first step to secure a legacy codebase.

I was not wise enough and I “broke the build”, though actually there was no automated build to break yet! The editing step was too big to be easily reverted and I disrupted the whole team activity. For 2 or 3 days the team has been complaining about my “refactoring fixation” and – as per standard policy – I was punished: I had to bring croissants for everybody the day after and I got a refactoring embargo, forbidding me any further refactoring for months.

Compare my past experience and my dream of today. What changed? What has still to change? I think I learned two main lessons, at least.

Continuous integration as an individual policy

Continuous integration is a personal policy first, then a team one, last an automated one. Keep it small, baby steps, allow for some observation time after pushing some virtually dangerous code into production. Nasty side effects could arise and you want to understand their root cause in a few seconds. Small meaningful commits are paramount and I really mean them:

  • Small so that is easy to scope them into your brain.
  • Meaningful so that their abstract consistency is kept high. It makes no sense committing half of a bug fix together with half of a refactoring.

Limit your work in progress, reduce the scope of your action. You don’t pay a per-commit fee so commit profusely! Also, being able to split your big problem into smaller ones is very good clue of your understanding of the problem.

A few years ago I was daring too much at once and playing with a way too big refactoring all at once. In the commit of my dreams (literally :-)) nowadays I just edit a few very consistent lines of code.

Don’t punish your volunteers.

I was in a team. The team was working in a very ill environment. I dared to try fixing our daily life. I succeeded in many places. I was wrong once. I got to pay a €20-equivalent fee in croissants and I was required to accept the status quo.

How. The hell. Does it. Make sense? No sense.

Well, I mean, I don’t expect everyone to be happy and congratulate with me for breaking production code. Neither I think that human actions should be judged only by their intentions: I may have the best ones, but a damage is a damage. Just don’t ask me to accept a rotten status quo just because that’s the only way to go, just because you don’t care enough to fix it.

All in all, you know, only those who do something are those that make mistakes. If you punish people for being wrong while trying to improve, you’ll only make them less willing to improve.

So what?

You may ask: “They shouldn’t have blamed on you. They shouldn’t have tolerated errors too. What do you think they should do then?”.

I think an healthy team builds a fault-tolerant environment up together to nurture an experiment-oriented atmosphere. I expect my teammates to build upon each other’s mistakes, analysing their root-cause and setting a new standard every day. A few years ago I expected my team to join me in the refactoring. In last night’s dream I expected my teammates to understand that introducing a bug while refactoring untestable code is as likely as in hearth surgery is to have a patient in atrial fibrillation: it’s bad but may always be a part of the game.

And fortunately you don’t even need to dream about Giorgio and Danilo to agree, do you? 🙂

What mom and dad never told you about your job as a developer

If you are a developer and you were born in the 80’s or in the 90’s, it is very unlikely that your mum and dad pushed for you to start coding. If you are even older it is close to impossible then.

Parents from the 20th century were – and are – usually more concerned about jobs that have been around since the dawn of modern era: lawyers, doctors, architects and all those like these. That also reflects on kids dreams: “I will be an astronaut!” you’ve always heard. You never heard a kid stating with steady shining eyes “I am going to be a programmer!”. So far.

To tell the truth, odds are that you had to fight quite hard to convince the whole family that what you were doing everyday once back from school was not wasting time on videogames, but exploring some very interesting new problem, building your mind up around a brand new kind of job that eventually became yours: developing software.

You started developing software because you liked it and you wanted to.

How does it feel now? Does it still feel amusing? Are you still feeling the urge to solve that very next problem? Are you still willing to improve the way you code? When was the last time you learned a new technique?

At least, the bare minimum: do you still like to code?

Ask yourself this question and be sincere for your health’s sake. If your answer is “no”, think about the reasons that brought you here. No one was pushing on you when you started coding, no one asked you to become a professional programmer, you liked it when you started.

What happened in between?

Interview about Cocoon Projects’ open governance model

About one year ago I took part of a Stoos Sparks program hosted by Sander Huijsen and Dawna Jones. We talked half an hour about Cocoon Projects and its open governance model which a few months later we distilled out into LiquidO, made available for everyone with a Creative Commons license.

After one year though the video still irradiates the good vibe it meant for us at that time. Enjoy!

Virtual & physical: the best of two worlds for our kanban board

Physical kanban boards are paramount to visualize the workflow of any company and engage people in managing it. Digital tools allow for remote work and for data crunching. A few months ago I asked myself: can we get the best of these two worlds?

It is now a few months that I joined Onebip, a mobile payment company. My main occupation here is to streamline the organisation to maximise its value stream, making sure we attack each bottleneck. Sometimes it comes to polishing the system deployment procedures, sometimes it is about making benefits and risks more visible to company’s strategists and sometimes it is about shaping the right (mix of) tools to serve the whole team needs.

People let uncomfortable tools down

When I arrived in Onebip everyone was nostalgic about the old kanban board. No one was truly using it anymore for a few important reasons: a part of the team is remotely located across Italy and Europe and some key managers wanted visibility on some metrics. The old index-cards-based kanban board was very good and appreciated by the team, but it was lacking the chance to be used and seen by remote teammates. It also allowed for no chance of computing the required metrics according to the team’s availability of time to compute them. These requirements left unfulfilled, the kanban board had grown used by just a part of the team, left out of the central role a kanban board should play:

  • a central meeting point for conversations, where people only talk about what is truly happening
  • an information radiator, capable of intruding in the peripheral view of people when bad patterns arise
  • a very usable tool which is a pleasure to use for everyone involved in those conversations

Digital is good and bad

I have already had my experiences with digital tools. They may be powerful but are dangerous too:

  • usually they propose you their way, instead of letting the team grow and forge its own tools
  • they don’t provide any muscular memory, giving people a very cheap way to just click and then let go
  • they are buried behind a browser window as long as you don’t click a few clicks to unveil their content

All in all they just miss a key point: they don’t become the totem of the community of people also known as ‘the company’.

One board to rule them all

We needed something to bring tasks front-center in our conversations, to engage people physically, to make flow visible to friends in Belgrade, Rome or Istanbul. I proposed to use:

  • Kanbanize, easy to customise, letting users veeeeery free to shape the board’s layout
  • an Epson EB-475Wi anamorphic interactive video projector which allows for people to gather around the screen projecting no annoying shadow
  • an HD Logitech webcam to reproduce telepresence

I had to put some extra care about Kanbanize CSS layout because the standard one was overloaded of commands that don’t favour a totemical conversations. I went for Stylebot, to just hide any exceeding DOM element and fine tune font size.

That’s it. As you may see in the video, now the whole company has its own powerful augmented real totem to drive its conversation.

If you are curious about other details or just to share your thoughts, feel free to comment here below or tweet me your comments through @jacoporomei. Ciao!

Organize for complexity: a review

A month ago I received a very nice and pleasant gift from Niels Pflaeging: Organize for Complexity, his very last book. I had to wait a bit to read it because I truly try to walk my lean talk, so I finished the book I was reading first and then I started this one out.

The subject of the book was – and still is – very attractive to me. The book is all about answering the question

How can I overcome my current company’s performance bottlenecks, making it grow and prosper without incurring in a bureaucracy nightmare?

Niels’ point of view is sharply articulated in 7 chapters, going from introducing the difference existing between complex vs. complicated systems up to a clear leadership model through an analysis of companies as dynamic-robust networks. It is a book meant to non-address the inherent complexity lying in companies, which are already networked. [They are] just not allowed to operate as one.

The book is very lightweight, more or less a hundred pages written in a very sparse way. It’s concise, dry, shrunk to the bare minimum. It states a lot and explains so little, I loved the style. If you want to know more about systems, complexity thinking, network science, well… you got plenty of books to read! [I promise to write a list in a post within July 2014!]. Don’t expect this book to be exhausting. Expect it to be thought-provoking.

This is a book I will use for two main reasons during my coaching activity:

  1. I will suggest it to everyone willing to learn a little bit about any of the following:
    • What’s the future of knowledge work.
    • What’s the approach I will face organisational challenges with.
    • What’s my job, tout court 🙂
  2. As a brief memo, a book of hours to read and re-read and re-read every time I have to re-align myself and my actions with my values, which I share 100% with the author.

My favourite quotes from the book

Some “general purpose” advise,

Profit maximisation and shareholder value theories are mechanistic and, ultimately, anti-social dogmas. Success is not a zero-sum game. And neither is it just “win-win”.

A memo for my daily coaching activity,

Resistance to change is as natural as sweating is in professional sports.

A very nice reminder,

One cannot, at the same time, lead and exercise hierarchical power. In complexity, leadership as a social process, as a system’s capability, gains prominence.

A deep guts feeling turned into words,

If you let formal structure interfere negatively with value creation, you are not doing your job.

Read this book, you are not going to regret.