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.

Continue reading “How loss aversion killed the turkey”

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? Continue reading “Make yourself a valuable employee by measuring your Net Promoter Score”

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? Continue reading “Dream of your build & build your dreams”

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!