Agile Project Management

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.

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?

Owning a product, leading a team, hiring a professional, designing an architecture with colleagues, and almost everything in life is a negotiation. Serial trade-offs, intercessions, conciliations or dialogues.

A great way of learning how to negotiate is through the George Siedel course in Coursera: Successful Negotiation: Essential Strategies and Skills. Have a look and try it out. I learnt a lot!

You can see everywhere that more and more companies are not including a Scrum Master in their teams. Others renamed the Product Owner role as Product Managers or Product Marketing Managers, and these don’t play the same rules as the PO. Many are even dropping Scrum and moving to a plain Kanban.

Software industry got fed up with Agile Coaches, stiff ceremonies, games and multitude of meetings. I don’t blame them for doing so. I personally reckon you’ll do it OK if you pick the best of each framework and remove any practice that is not working for you or it is not as productive as it should be (Law of Diminishing Returns).

Keep stuck with the basics: deliver software frequently, welcome changes, work close to Business people, and more important than anything, keep it neat and simple. You’ll be OK.

We tend to believe that creating comprehensive Gantt diagrams, precise roadmap documents, and making the customer sign the meeting minutes will make us and our projects more trustworthy.
We need to plan, and try to foresee what is coming, but you can only be sure of a few things: estimations are going to be wrong, customers are going to change their minds, and you’ll need to adjust the Gantt.
Suggest, propose, execute, test and iterate again. As Naval Ravikant says, do 10,000 iterations not 10,000 hours.

What to do if it takes me ages to get to production? Have a look to this article if your cycle time is huge: https://www.antoniomartel.com/2023/10/theory-of-constraints-toc.html

What to do if your to-do list and backlog is growing endlessly:

• https://www.antoniomartel.com/2023/09/when-everything-is-a-priority-nothing-is-a-priority.html
• https://www.antoniomartel.com/2023/11/dont-even-write-it-down.html

And when your tangled with bugs and incidents, but no any new features: https://www.antoniomartel.com/2023/11/equilibrium.html

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

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?

Many teams are constantly struggling to keep a clean and focused 15 minute daily stand-up meeting, but we cannot help asking our questions to the tech lead or senior members when an issue has been bugging us for the whole day. Others just talk too much and derail the conversation on important topics.

In such cases, you just can say “Greg, let’s allow everyone to explain their hurdles and complete the daily stand-up. We can save that for the sixteenth minute item”. After everyone talked about their impediments, we open the discussion and let them propose any matter they wanted to talk about. Make sure everyone is free to leave if the theme to be discussed is too specific to the work of other colleagues.

The Bystander effect or Bystander apathy is a well known social psychological theory that indicates that people are less likely to intervene in a crime or in a crisis if there are more witnesses of the crime. All of them seem to be thinking: “Someone else will call the police, for sure”, but nobody does.

This also applies to product management. When we trust only in documentation and processes, we all think someone else is having a look and will take charge of the hurdle, but nobody does. Meanwhile the issue grows endlessly. Focus should be on our product and not in the process (better if we got one, but it is not our main goal).

Tasks should always have someone assigned who will feel in charge of their delivery and have a clear deadline to avoid the blurring of the responsibility. Besides that, the Product Owner or Product Manager will be concerned of any difficulty we might be facing. The product is their ultimate duty.

Mercedes Benz made some surveys among their potential customers and they said they wanted smaller cars with less gas consumption per mile. They created the Smart. Meanwhile, cities were crowded with 4×4 vehicles as big as an airplane.

You don’t know what people want. They don’t know it either. You think you know but you don’t have a clue (me neither). Choose a reasonable option, test it, fail soon and fail cheaply. Learn from it and try a different thing. Keep as many options open as a small budget allows you.

But above all, avoid the Sunk Cost fallacy and insisting on a failure as “market wasn’t ready”. Nobody likes admitting they were totally wrong, but there won’t be more opportunities if you sink with the ship (or the department, the project, the product).

You have been working in chronograms, Gantt diagrams, risks and resource management, more graphics specifying who reports to whom, dreamed plans, and the name of the people who should be blamed in case of not meeting a deadline. You are probably thinking everything is under control, but nobody reads those documents, skimming them at best. 

When you see paperwork like that one, you might be thinking “What a great project manager I am. Every single detail has been captured”, but it might be only an Illusion of Control. What are you doing to help the team to be more productive? How do you plan to overcome Parkinson or Hofstadter’s laws? Other than getting everyone nervous when a deadline is getting closer, have you helped them to remove obstacles? Are you sure the team is delivering value? Ticking a checkbox for every completed task is not getting you any closer to the objectives if the outcome is faulty or doesn’t provide any utility.

It’s based on the search of bottlenecks and critical paths in your operations, so you can improve the process as a whole as any improvement in that point will enhance the total outcome. The idea comes from factory lines where a machine or an activity is delaying the whole line and preventing you from manufacturing more tomato soap cans. 

Your team probably (I hope) follows a sequence of actions: First user story is refined, then developed, tested, reviewed by colleagues, after that a pull request is triggered, software is merged, then tested in an integration environment, and finally reviewed and approved by Product Owner. What is constraining you from delivering more value at the end each iteration? Maybe your refinement session is not long or frequent enough to get all the stories refined, or perhaps Tech Lead is too busy for the huge amount of pull requests she is receiving, and they start to pile up in the repository tool. Do you need another pull request approver? 

Analyze the series of steps your team follows. Try to tweak your proceedings a little bit every time. You’ll make significant progress in your cycle time.