Chess -

Archivos de Autor: Antonio Martel

Hot potato management

You can get some relief by moving forward the hot issues to the next team, but two things are going to happen: the problem will never get solved, and it will get back to you faster than you think. If the hurdle needs to be handled by another team, make sure you add some value to it before sending it away: provide notes, your tests or thoughts, steps to reproduce it, the name of people who can help or a summary of the previous steps your team have done.

From the Gerald Weinberg’s book “Quality software management”:

“Another way an individual can relieve overload is by passing problems to other people. As a result, in a quality crisis, problems don’t get solved, they merely circulate.

“Problem circulation is usually the result of spasmodic management style that punishes people who happen to be holding a problem when a manager’s interest reawakens. This dynamis is exactly equivalent to the children’s game of hot potato (…). Any problem that doesn’t have an immediate, obvious solution will show this same dynamic if management punishes whoever happens to be holding it when the bell rings”.

Six basic principles of good business management

From the Personal MBA book:

  • Recruit a small group of people capable of achieving what they have set out to do quickly and with the highest possible quality. Make sure the team is not too large.
  • Communicate clearly what the objective is being pursued.
  • Treat people with respect.
  • Create an environment where everyone can be productive.
  • Refrain from harboring unrealistic expectations regarding uncertainty and prediction. Create an aggressive plan to complete the project, but be aware of what uncertainty and misleading planning can cause. Apply Parkinson’s Law constantly.
  • Propose KPI to see if what you are doing works, if not, change your strategy. Planning includes learning, and that means making ceaseless changes to the plan.

Don’t even write it down

Some time ago, when digital transformation was in its infancy, I migrated my backlog document to an online spreadsheet using the brand new Office tool. Every single new request was logged there and an inscription number was assigned to it. Unfortunately, the IT department decided to start the Office tool again from scratch and rewrite the folders configuration, but the email warning the, by then  few users, had arrived when I was on vacation.

Suddenly, all my backlog documents were lost. Hundreds of items in half a dozen backlogs simply evaporated. I was anxious and distressed by the feeling of having to populate all these backlogs by interviewing again every director and stakeholders.

But nothing happened, I collected the last open requests from my previous open A3 report and now the backlogs consisted only in five to seven items. This very much reminds me of the book Rework by David Heinemeier Hansson and Jason Fried. As Milan Amin says in its blog when writing lessons learned from the book:

Every time you get feedback, don’t rush to implement it. Heck, — don’t even write it down. The thing that is most important, will NOT go away. People will keep on reminding you, even if it’s not the same people, other people will ask you again and again, and you will not be able to forget it”.

See blog post at:

The Agile A4 Sprint Report

I have been sending different flavours of the Agile A4 Sprint Report at the end of each sprint for more than 5 years since I read from it in The Professional Product Owner book. In each email I also add a few observations on what can be improved and suggests a couple of actions for the following sprints (the Lean way). Quite an useful tool indeed.

As Ralph Jocham says: «I am a big fan of the Toyota A3 Reports (…) So I was wondering how you could use them for reporting when using Scrum. The result is what I call the «Agile A4 Sprint Report» as it fits nicely on a page«.

Are we being unpredictable?

Gerald Weinberg in his book Quality Software Management, long before that Product Managers came around, explained an anecdote on the way a number of programmers he interviewed used to set the priorities for their work: one programmer declared: “This customer is an SOB. If I solve this problem, he’ll stop calling me”. Another programmer in the same organization affirmed: “I’m solving this problem because the customer is so nice to me. The ones who get abusive on the phone, got to the bottom of my stack”.

A third programmer explained: “I do the customer work last. The jobs I have to do for the development staff come first, partly because it’s more important work, but mostly because they’re right across the hall”.

We, as Product Owners or Product Managers, are supposed to make decisions based on value, but value is usually a rather subjective term. Aren’t we really being as unpredictable as those programmers?

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