Planning: a result-driven approach (italian)

I presented this talk about using pirate metrics to guide planning at Mini Italian Agile Day Trento.

“Pietro Campagnano ci spiega come fare un planning basato sugli obiettivi di business al posto che solamente sulle feature, usando le pirate metrics come bussola del progetto. Un approccio al planning data-driven relativamente semplice e poco costoso.”

The slides are here:


There is the video of the same talk presented at “Crafted Software Milan” one week ago:

Your team is not too small

Working as a consultant, I could see different teams in different companies, and I’ve heard some sentences that sounds like a red alert to me. They are not necessarily false, but often they hide a different kind of problem from the one identified by words.

This team is too small, we need more people to grow our capacity.

Every healty business has a lot more business ideas than time to execute them: some good ideas, some are bad ones. What a lot of businesses lacks is the ability to choose which business idea is the most important now. If you can’t choose which is most important, you will be overwhelmed by a huge number of ideas all at the same priority that will start at the same time and will burn your precious time, without permitting you to complete any of them. If you can’t choose the fate will do it for you.

instagram team
The entire Instagram team when it was bought by Facebook

If you grow a team but you don’t have focus, your capacity to complete your projects will remain unchanged. You will simply start a lot more secondary things that will continue to steal your attention, and your important goal will be lost in a even worse mess of business opportunities.

But why choose which is the most important goal for your product now is such a difficult issue?

Well, the causes can be multiple:

  • to choose is a risk: if you choose you need to take the responsability of your choice, if you don’t choose your chance of success will be much smaller, but won’t be your choice to make you fail;
  • it’s not clear who should choose: in some company the responsability to choose the focus are not really clear, no one feels entitled to choose a focus;
  • who should choose doesn’t want to choose: sometimes the person in charge of taking the decision doesn’t want to take decisions because he doesn’t feel qualified, or he doesn’t want to be accountable for that decision;
  • different visions: sometime the people at the head of the company have different ideas (which is normal), but they can’t reach a consensus (which is problematic);
  • no vision at all: no one really cares about what this product should be, and even more importantly not be.

The solution is simple but not easy, you need to analyze and overcome all the obstacles that blocks your organization from committing to a single goal, to unlock your organization real potential.


Thanks to Nicole Bartolini and Riccardo Franconi

4 tips to begin to work remotely

A couple of years ago after a couple of email, some long skype call, a micro-project on Github, ideato hired me without ever having seen me, neither in webcam, neither in real life… and it seemed simply right.


There are a lot of things you can do without being in the same room, but it’s not simple the first time you try… these are the lesson I learned along the way to make everything running smoothly.

Remote working has its own etiquette

We are used to an implicit etiquette in colocated working, but remote working has some different rules. Work from home without pants can be ok (like the Scott Berkun book) but make a Skype call with a microphone without noise reduction is very rude (don’t let me start about not having headphones at all). Likewise, when you have a slow internet connection trying to speak with you can be a real pain. To care about these things is a way to show respect to your colleagues, exactly like having a shower before going to work.

Sometimes you need to meet physically

People and relationships are the first things to care about, and to build a trust between team members and with customers is a much more accelerated process when you pass some days physically together.
In ideato this means two things:

  • when you are just hired you work from one of the offices for 1–2 weeks
  • the kick-off of a new project is done with the team and the customer in the same room for a couple of days

Be explicit with your needs

In a colocated environment people often sees when you are stuck, when you are upset or when you need some help. In a distributed team this is more difficult or requires wider times. You need to learn to make your needs more explicit (that is anyway a great skill for your life):

  • is better to ask twice when something is not clear than to wander in uncertainty
  • is better to ask for a pause (in pair programming) when you are tired instead of loose concentration
  • is better to make explicit when you disagree, because it is possible that no one will see the doubt in your facial expression

Get the benefits

When you work in a colocated team, your social life by day, from Monday to Friday, are your colleagues. They can be intelligent, fun, kind and so on but you will see the same person day over day, for years to come. When you are a remote worker you can choose everyday who you want to see that day, you can find the most inspiring people to pass your day with. It’s not always simple, but it’s a great opportunity you can (and should) take. Remote working doesn’t only mean work where you want, it is even work with who you want.

Originally published on

Programming is the easier part

Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.

So, about this Googler’s manifesto – Yonatan Zunger

The Second Law of Consulting: No matter how it looks at first, it’s always a people problem.

The secrets of consulting (1985) – Gerald Weinberg

Anyway writing software is hard, but unfortunately is the easier part.

Your software’s architecture is not MVC

Everything starts with a simple CRUD, you add the migration on the database, create the entity, insert a controller, a couple of views and everything seems fine. Then one feature after another the controller begins to grow, and begin to be more and more complicated and difficult to understand.

Rarely the software you are developing is just a CRUD, even if initially seems like this, every business domain has its own set of rules more or less complicated.

Then you realize that the framework architecture is not really perfect for your software, and you are right, because your architecture and your framework architecture are not the same thing, design your software is much more than deciding if some lines of code should be in a model or in a controller. You probably need classes to represent the concepts of your software domain, that are not pages, database tables and routes (that are the domain of your MVC framework), but maybe invoices, taxes, cost calculations or whatever your domain is about.

There are a few presentations that helped me to understand better how to put in practice these ideas:


Don’t ask your customers which features they want

Some years ago I used a soulseek client for linux to download music. It was an open source software, so when I experienced some bug I report it to the kind developer that fixed the issues. One day I thought that the UI would be much better with an option to hide some components, I opened an issue for this enhancement that was accepted and done. When I tried the updated software I discovered that my suggestion was wrong, now the UI was too crowded, it was much less comfortable to use… I slowly stopped using that software.

It may seem strange that when my suggestion was heard I was not satisfied, but this is not uncommon, because customers know their own pain and needs, but are not expert in suggesting the right solution. They are expert in their problems, but it’s much harder for them to evaluate all the trade-offs that needs to be considered.

To avoid this problem you need to understand why they want that feature instead of focalizing on what they want, and starting from it find the best solution that could satisfy the customer. So for example if you want to know in which direction develop your software, use something like UserVoice is a bad idea, because you will have a long list of features without any simple way to understand the reason they are needed, a better way is to interview some of your customers with questions smarter than  “Which features do you need?”, as Nelson Joyce suggest in this post.