Through the Stack 2-10 (Week 15)
This is "Through the Stack," a weekly focus on a topic and links relevant to Lead developers (actual or aspiring) working with an internet-related product.
Many lead developers, tech lead, and staff engineers have their hands in many projects and influence many layers in their organizations. As such, they work Through the Stack: from Strategy, through Operational to Tactical work. This newsletter reflects those dimensions.If you have comments or content to suggest, please reach out to us by email.
This week ...
We focus on "Backlog bloating", which is an issue we encounter in many, many teams. Still, before jumping into this important topic, let's look at a few links that made it through the noise in my feeds.
7 ways to build an effective Platform team: a good article by @ashwini_md with 7 points that can be used in any team. Even if your company lacks a dedicated Platform team, you should encourage your teams to act that way.
Resilience is about how you recharge not how you endure: a great article from 2016 on a false idea we have about Resilience. You can find similar ideas in our recent "Slack and WIP limits" itself a musing after a read on slack and efficiency.
@gradybooch's little tweet reminds us not to confuse what GPT (& friends) outputs for understanding
@arvidkahl sharing the list of podcasts he listens
we published a quick overview of Analytics tools to start with. If you are starting a website or product and wondering what to use to have some usage statistics ... you want to have a look
That's it for this week. Let's move to the main topic: Backlog bloating. This has been a recurrent theme in my work for the last 10 years. It took me a while to develop an opinion and approach to this. For many of those ten years, I just let the backlog grow. But nowadays, I advocate for a drastic approach: discard it all.
As you might guess, this doesn't sit well in the ears of many, but, from experience, that's basically the only way forward.
Backlog bloating
As a tech lead, one of the biggest challenges I have faced in my career is the management of backlogs. The backlog is supposed to be a tool that helps teams prioritize work, but it often becomes a dumping ground for all ideas that come up.
The problem with backlogs
The problem with backlogs is that they can quickly become bloated with items that are not relevant or necessary. Unexperienced founders, investors, or engineers can contribute to this issue, as they tend to push their ideas onto the backlog (with or without a proxy).
As a result, the backlog can become stuffed with anything and everything, making it difficult for the team to understand what's next clearly.
To avoid this fuzzy outcome, many teams add extra meetings such as "backlog grooming" and "prioritization". Those can take up valuable time and energy but have, in effect, little impact. They merely add a false sense of control.
Furthermore, some teams have months of prioritized backlog only to keep pushing things back down, delaying this and that.
As a result, The backlog keeps growing, mainly being a box of ideas that rot in there. Ask yourself: if a ticket has been in the backlog for more than 2 months, is it still relevant to the reality of the product's user? Or the team's?
As for the team, the backlog, being just an infinite list of tasks, becomes a source of stress and a cause for low morale. The team can become demotivated and lose sight of the end goal, leading to a lack of productivity and progress.
What to do?
In general, backlog bloating is a symptom of a team focused on tasks rather than objectives. As pointed out in the Failure Factory, the race after shiny objects denotes a lack of clear vision and its translation into objectives for the current iteration.
On objectives: which ever methodology you pick to establish them remember the gist of the approach is setting a long term goal (the vision) and a set of objectives for the short term that help on the journey to that long term goal. The vision is your destination, the objectives are the waypoints on the way.
Having vision and objectives help the team figure out what to work on and then focus accordingly. Anything that does not help move towards the current objectives can be quickly discarded, only keeping what matters and can be done. This approach requires holding the line and keeping the backlog nonexistent or limited.
Still, as one would not want to get into another bad pattern, such as working in big batches and ignoring the rest of the world, this should be used with short iterations. This implies the approach described last week (Fast Iterations in Episode 2.09 of Through the Stack), which is a not-so-small change for many teams.
One counterargument I have heard many times is that, by doing so, there will be downtime in between each iteration. This downtime is often seen as an issue since it appears to be time not spent producing anything !? Yet, as we pointed out in "Slack and WIP limits", this "slacking time" would be precious to monitor, reflect and prepare the next effort.
In conclusion, by prioritizing what is truly important and keeping a clear vision of the end goal, teams can avoid the futility of bloated backlogs and deliver quality work on time. This won't be easy and will require an essential change in the team's culture. Yet, with experimentation and patience, this can yield important results.
Key takeaways
Ensure the vision is clear: what are we aiming to do?
Ensure the few objectives are clear: what is our current waypoint on the journey?
Keep just what is needed to reach or move toward the waypoint in the backlog: does it make a difference?
Use this with a move toward short and fast iterations
Who are we, by the way?
This content is written and published by Imfiny/Pier22, a consulting company based in France. We help CTOs, and Tech Leads grow their engineering team and stack.