The first question to ask when requested a new feature
It is not 'When this needs to be done'
Stop coding first, start questioning the purpose!
This isn’t just a bold statement; it’s a game-changer in the realm of software development.
« Why it needs to be done? »
Before diving into coding a feature, the pivotal question isn’t about the ‘how’ but the ‘why’. What’s the business interest behind it? In a landscape where many developed features end up unused, a developer who can judiciously say no to an unnecessary feature is not just a coder but a cost-saver.
« Because I was asked, so I’m asking you »
There are often a lot of intermediaries between the developers and the users, or the business owner. They’re called various names, product owners, scrum masters, business analysts.
I have nothing against these people. I do think they are very competent. But it is all a game of chinese whispers: by having many intermediaries, the actual purpose of a feature get lost. It is a simple observation that I make over and over.
Thus, the meaningless tasks pile up in the backlog. The more tasks, the more cloudy the vision of what needs to be done.
A proposition
Imagine having a panel of users directly accessible to your developers. No Product Owners, no Business Analysts, just unfiltered, raw user feedback. This direct user-developer interaction is where the magic happens. It’s in the developer’s understanding of user needs that the right functionality takes shape, not just in the code they write.
Then, by making sure the user need is properly aligned with the company strategy, and make sense within the product, it can be implemented directly, without waiting time.
This is how products evolve and businesses flourish, preventing them from being overtaken by competitors due to sluggishness.
So, encourage your teams to probe, delve, and question relentlessly. Seek to understand the real pain points of your users. This approach is far more valuable than ticking off hundreds of items in a backlog. It’s about building features that truly matter, that solve real problems, and ultimately, that add tangible value to your business.
In software development, less can indeed be more, when it’s the right ‘less’. Let’s shift focus from “working the whole backlog” to “working only what is necessary”.