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.