I’ve played with my fair share of project management and issue tracker tools. Their claim to make our team more productive drew me in, only to leave me disappointed and frustrated.
I’ve written about how issue tracking software hurts your product development before. Today, I’d like to show you three problems your team is likely going through because of it.
And the worst part is, you probably don’t know about it!
3 hidden problems in product development to watch out for
Problem 1: False indicator of productivity is visualized
It’s easy for teams to look at graphs and think they’re being productive. While the reports may indicate that the team is shipping plenty of features / enhancements / bug fixes, it can never tell you is if those things moved the needle.
By introducing any form of metrics that focus on productivity, you influence the behaviour of the people contributing to them.
- Developers may cut corners to "get it done”.
- Tests and code reviews may get skipped.
- Instead of finding the root cause of the bug and fixing it, your team might just throw a series of
ifstatements to fix it.
Of course, before it’s deployed to production a product person will look at it. If they aren’t technically sound or don’t obsess over edge cases, a lot of the corner cuttings will get deployed to production.
This is snowballs into a series of poor experience for the customer and unnecessary bugs that could’ve been avoided.
Problem 2: Disconnected view of what needs to be built
Developers get only a fraction of the information they need to build good software.
They’re told “Hey we need to build feature X. It will help our customers achieve Y. And we need to ship it within Z date.”
Tickets are created and assigned with the assumption that it has enough detailed information that developers need to know. In reality, there are so many other things that get missed out when you think in tickets/issues.
This is where the problem starts:
- Key interactions are missed because the path to achieving a benefit from software is never linear. This is rarely communicated explicitly.
- Hidden capabilities are added to the feature because it was assumed to be "cool". Teams never communicate what a feature must not do. And this is more important than what it must do.
- Edge cases are never thought through or talked about. Sometimes, it’s the developers who bring it up. And that’s okay. Because some things are unearthed only during the creative exploration that a developer undergoes while they build it. However, most of the times, even the simplest of cases fall through the cracks.
Any developer who’s tried to build even a small chrome extension knows that building software includes ambiguities, uncertainties, intertwined relationships.
Problem 3: Sequential, issue-driven development
Issue driven development leads to nothing but issue swamp. It gets messy very quickly as developers independently work on each issue sequentially. More code gets piled on as required and getting it to a production-ready state becomes a nightmare.
This also leads to a narrowed focus on the issue instead of the bigger goal of building a quality feature.
Let me explain with an example.
The customer requests for the ability to view a series of images in a grid view. An issue titled “Get a series of images and display them in a grid” is added. This is then broken down to actionable steps. A front-end and a back-end developer picks it up and together they build it out.
Side note: When your customers ask for a "feature", why do you call it an "issue"?
At a surface level, the feature might look completed. However, a series of issues come up that diminish the perceived quality of the feature:
- Some images look good, while many look pixelated.
- Images don’t have captions. Nor do I have the ability to add a caption to the entire grid.
- The page takes ages to load because of the images.
- How many images should you load at a time?
- Should the images be interactive?
As you can see, what looks like a simple ticket has a bucket load of questions that need to be answered and functionalities that need to be built.
The problem with issue driven development is, it quickly shifts the mentality from “Let’s solve this problem” to “What next?”
As a result of “What next?” mentality, a simple sorting of an object will get implemented using the easiest method. While it might not be the wrong method, it’ll make it exponentially harder for others to debug or understand the code. Cross-pollination or exchange of ideas about the problem rarely occurs. And makes it impossible for teams to communicate the essential details required to build the product.
These product development problems come from a deep need to satisfy a metric or to show productivity. They pigeon-hole developers to ticket-movers and do not enable them to think at a system level.
It ties back to the previous point I made on how teams begin to visualize false-positives.
So, how can you fix these product development problems?
Understand the difference between issue tracking vs product development
The road to shipping anything that isn’t a bug is filled with speed bumps and diversions. Product development is never as simple as “do X, Y, and Z, and voila!”
A feature, unlike a bug, goes through a series of exploration. Many functionalities are an implicit necessity. This implicit requirement can never be communicated in a single ticket.
While a bug, on the other hand, is a lot easier to communicate. All you need are three things:
- Steps to reproduce,
- What you expected to see, and
- What you saw instead.
Even for something like a bug, that requires only three specific details, the developer will still have to go through an exploration phase to identify the root cause.
If a bug, that has all the details specified accurately, has to go through an exploration phase, imagine how much more complex it is to build a feature that has an arbitrarily broad spectrum of scale and detail.
It’s those chock full of implicit requirements that get missed out in a ticket that makes a developer mad and frustrated.
The next time you ask your developers to build a feature, don’t try to squeeze it all in a two-line ticket. It never works. Instead, spec each interaction and functionality of your feature into separate user stories. That way, you can zoom-in to track each work item and zoom-out to track an entire feature.
Negotiate the outcome vs duration
“But the product manager wants the feature shipped by next week!”
Of course, it’s important to not take a year to build a feature. However, teams obsess too much on the deadlines and turn “time taken to build and ship” into a metric.
This doesn’t happen explicitly. But even the slightest of hints reduces your team’s functional standards to “It runs, let’s deploy.” The quality of the code (and sometimes even the feature’s standards) becomes an afterthought. What you’ll get is a hodgepodge of enough code to get a working product that will eventually fall apart.
When teams negotiate on what can be built within a timeframe, it pushes the product person to think deeper about what’s really needed. Your customer might have requested guest access with fine-tuned rights. But if it’s going to take three weeks to implement, it might be more sensible to buy time by implementing view-only mode and then iterating on it.
Sometimes, what a product manager wants isn’t feasible in a given time-frame. The solution to it isn’t to get your team to pull all-nighters. It’s to work together to find a solution that meets the customer’s requirements. If not fully, at least in partial.
Because sometimes all a customer wants is to feel heard.
If you liked what you read, I think you’ll love what the project management tool we're building for software product teams. Go ahead and try Zepel for free.