Chess -

Archivos de Categoría: English

Preferimos programadores que trabajan hasta las tres de la mañana

Hay un dilema que nos explica Gerald Weinberg en su libro Becoming a Technical Leader. Nos dice: si tuvieras que hacer un viaje con alguien que conduzca, ¿con quién preferirías ir?

  1. Con alguien que nunca ha tenido un accidente, pero probablemente estaría indeciso en caso de tener uno.
  2. Con alguien que tiene un accidente de media por semana, pero es muy resolutivo en soluciones de emergencia.

Aunque parezca mentira, mucha gente suele preferir la opción 2. La guerra es más heroica, nos gusta el drama y que nos salven de apuros. El programador que está hasta las tres de la mañana arreglando asuntos se convierte en nuestro héroe, al que recompensamos y estimamos por habernos salvado el pellejo una vez más.

¿No sería mejor recompensar programadores y mánagers que nos mantienen fuera de las crisis? Será más aburrido, y no tendrás que organizar gabinetes de crisis o war-rooms que nos mantenga en el foco de atención, pero mantendremos un mejor estado de salud en nuestra organización (y no solo allí).

How to keep meetings limited

I hate long meetings (well, I hate meetings generally speaking). Those eternal gatherings to discuss and discuss forever what was already agreed because nobody prepared the assembly or had in mind why we were there.

Here are some bullet points on how to short them and make them more productive:

  • Send first a list of items to discuss.
  • Make timeboxed meetings. Leverage the Parkinson laws. Try to commit to no more than 45 minutes per session. The last 15 minutes are used to agreeing decisions.
  • Warn that the end is approaching. When in a hurry everyone is going to summarize their position and try to get to the point instead of discussing banalities.
  • Conclude with the agreed points.
  • Let your people know that they must come prepared to meetings. They must review the points and get ready the items they were assigned to.

Is it worth an eight person meeting where only two of them talk? How much does a three hour session cost if multiplied that time by the cost per person? Which one is the cost per month of the monthly meetings in the team? I am sure our colleagues would be better working on other tasks than listening to the HYPPO.

The 80/20 rule

How can we avoid featuritis and concentrate just on the tasks that will make us more efficient? Many years ago, approximately a century ago, someone called Pareto realised that 20% of the pea pods in his garden amounted for 80% of his crop. The remaining 80% of his pea pods amounted to the other 20% of his pea crop. Intrigued by this ratio, he also checked that he could use this rule to other fields. He went on to discover that, back then, 20% of the population had 80% of the income. The remaining 20% of the wealth was in the hands of the poorest 80% of the population. This principle, based in empirical knowledge, has been in use since then. It helps improve efficiency and productivity in economics, commercial distribution, marketing, engineering, and, naturally, in software development.

For example, we start to develop our product with a huge list of requirements and features as a base. Yet we know that only 20% of those features will be used 80% of the time. A large chunk of the remaining features will only be used 20% of the time. We can apply this principle to development time. Using it, we can deduce that if it takes us about 10 months to build a product, in 2 of those months we will be able to develop 80% of the features. Thus it would take us about 8 months to solve the remaining 20% of the most complex and difficult features. This leads us to ponder:  will people use these features? Are they really indispensable?

Say we manage to identify the most important features, and we keep them as simple as we can. Wouldn’t we be able to dispense with 8 months of work and deliver a highly effective product in 2 months only? We already know that 20% of our effort will produce 80% of our results. Wouldn’t it be worthwhile to sit for a moment and think for a bit about what we should devote our time to? I’m sure it would.

Translation by Begoña Martínez.

Usage Index

As per D. McGreal and R. Jochan in their book The Professional Product Owner, the Usage Index determines how a product and its features are difficult to use, difficult to find in a messy User Interface, or if we are maintaining costly software which nobody cares about.

The functionalities at the bottom of the chart might be features for the admin users, or our biggest bet a few releases ago. We expected it to be a “killer” functionality, but it looks irrelevant for most users. Should we invest more in users’ training or highlight that menu option in the main page of our application? It might be worthy, but please make sure you have not fallen prey to the Sunk Cost fallacy. After a few attempts, maybe it’s time to remove that code from our code base.

According to the Chaos Standish report, as mentioned in the book, even this follows a kind of Pareto principle: only 20% of production functionalities are used often, meanwhile a sound 50% is hardly ever used.

Listen and note everything down

Throughout my career I have had some successful projects and products (along others that were a mess, I hope I learnt enough from them). When I took stock of what was wrong or working OK, what most people valued was:

  1. I don’t forget anything. I “remember” what everyone said or asked for.
  2. I am able to reach agreements even with the most “stubborn” people.

I am afraid I don’t have an astonishing recalling ability. It is rather a plain simple trick. I just note everything down, then I read it again the next day, move it to my online notes, date it and set frequent reminders in my calendar: Did we get the new password? Did we send the long-pledged information? If someone asks me about anything, I just look into my notes. If that was ever mentioned to me, it should be in my notes, my calendar, Confluence pages or whatever tool I am using at that time.

Although taking into account the considerations from “difficult” people also provided me with great satisfaction. Most are not obstinate or bull-headed, they are just having issues with their request, budget or even their boss. They are worried and want to know you understand them, you are going to do what is in your hand to ease their problems. If you need to get something out from that meeting, do you have something to give in return to the other side of the table?

People just don’t recall if I am using Scrum, a User Story Mapping technique or sending a report with the information on the cycle time or Jira Control chart. They just want to feel heard and know I am not going to forget the preparations for a deadline or fail to solve a dependency for another team. Just listen and note everything down.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información