Chess -

Archivos de Categoría: Blog 1

Cómo completar antes tus proyectos

Según la web de Eliyahu Goldratt, la evidencia prueba que puedes completar tus proyectos (y productos) más rápido si:

  • Pasas menos tiempo planificándolos. Evita la parálisis por análisis y utilizar mucho tiempo intentando adivinar lo que solo sabrás cuando te pongas manos a la obra.
  • Usas estas tres reglas en su ejecución:
    • Retrasa lo más que puedas el inicio de los proyectos (conseguirás así terminarlo antes: para cuando lo inicies tendrás más conocimiento del mercado o de las incertidumbres por resolver).
    • Elimina la multitarea: cada persona debería tener solo una tarea concreta a la vez.
    • Pon en cuarentena las tareas que generan dudas o incertidumbre y gestiónalas adecuadamente (incluyendo la Ley de Murphy).


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.

Learn Lean, learn Agile

As per James Clear, in Atomic Habits, referring an article published in the New Yorker:

“Japanese firms emphasized what came to be known as ‘lean production’, relentlessly looking to remove waste of all kinds from the production process, down to redesigning workspaces, so workers didn’t have to waste time twisting and turning to reach their tools. The result was that Japanese factories were more efficient and Japanese products were more liable than American ones. In 1974, service calls for American-made color televisions were five times as common as for Japanese televisions. By 1979, it took American workers three times as long to assemble their sets.”

Americans had to learn Lean in order to compete. Shouldn’t we learn Lean?

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