5 Reasons Why Scrum Teams May Not Deliver the Backlog

[This is a post from 6 years ago, but I came across this situation recently with a client, hence re-posting it here]

As a Product Manager, you should be used to hearing "NO" from every stakeholder, including the engineering teams. And then comes the hard part of persuading people to listen to you, even when they do not report to you. Of course, if you are talking to a vendor, or an IT services firm, you occasionally face the other challenge, of hearing a "YES", for every product initiative. With engineering teams, sometimes there is a hidden reason behind their "no" for a product/feature concept. Here are 5 reasons why PMs I know were not able to push through product requirements.

It's not cool enough

In the web world, certain technologies and features are considered cool. Others are not. So if you have a strong engineering team, they may simply nix the basic features such as logging, event viewer etc. in favor of features such as cross-domain APIs, "social" features etc. The trick is to keep a judicious balance in every feature review. And in case that's not possible, just promise them that the "cool" features are coming down the road. And be careful about the ever-present "code conversion" projects where they want to migrate the code from JavaScript to TypeScript or to use node.js and introduce SVG viewer and other features. Unless there is a business need or a strong performance reason, the "coolness factor" could be lurking about.

It's too tough

This is what I heard from an intern who joined the engineering team. They had worked on a matrix based hierarchical organization of real-time data for a year, and then they gave the same project to the intern to take analyze. Additionally, this was always the project that got de-prioritized over other initiatives. By sitting with the intern for an hour, it was easy to understand that this was an NP-complete problem, and optimizations were simply too tough for our data dictionary. (Here is a description of NP-complete).

It's too easy

I have been in teams that often said "no" to easy fixes. After developing the core feature, however badly, nobody wants to simply fix all the bugs or add the security requirements. Again, one workaround is to offer a bundle of features to the product team, where they cannot pick and choose specific features. 
In normal circumstances, these are the features that will slip the most in an early release, as they are deemed "non-core" features. For instance, the web-based admin GUI for a SaaS app often falls in this category.

We don't have expertise in that

No true engineering team will admit this, but this is also another hidden reason why teams say "no". In one instance, the team had no idea of the internals of Oracle's 11g release, so they simply delayed releasing a plug-in based on that. After several weeks of waiting and testing alternates, and with shipping of the core product getting delayed, this is the actual reason that came out during a hallway discussion with an engineer. The product management solution was to drop the plug-in and release the product.

If I agree, I will look weak

This is one of my favorites. Engineering managers in world-class organizations have a top educational background, have often won awards for their work and are viewed as stars. So if a great PM comes along with a perfect PRD, and has all the right features dictated by competitive needs, market analysis and user requirements, the engineering manager will simply say "no" to many features to satisfy his ego. (I do not know of any way to solve this problem, except to avoid entering such situations.) And going Agile, and becoming the Product Owner and backlog owner still does not always solve this situation.

No comments:

Post a Comment