Archivos de Categoría: English

From The Professional Product Owner book: Growth of technical debt by poorly designed software where budget is progressively consumed as the old software is kept alive. If you fail to address technical debt now, you will end up paying more interest in the future.

Netscape’s project to improve HTML layout in Navigator 4 has been cited as an example of a failed rewrite. The code base was so bad that developers couldn’t work on it anymore; they decided to rewrite a new engine, causing many failures in existing features and a delay in the release of several months. Meanwhile, Microsoft used incremental improvements to Internet Explorer and overcame those obstacles.

The Professional Product Owner book

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”.

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.

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: https://medium.com/@Milan__Amin/a-summary-of-rework-change-the-way-you-work-forever-by-david-heinemeier-hansson-and-jason-fried-cf7a0d49c2c8

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«.