Archivos de Categoría: English

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.

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.

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.