It could be me, but none of the off-the-shelf project management tools work for us. They’re either overly complicated like Jira or too simplistic and lack the functionality and flexibility we need so much.
For that reason, we use Fibery.io. It’s great because it allows you to model your process however you want. It also has a full-blown API to integrate with any systems you like. This helps augment areas where Fibery falls short. For example, they don’t have the flexible permissions that we need.
We will see, but we will likely build yet another project management system tailored for our needs. We’ve spent so much time finding the right mix already. Hopefully, it will be useful for other teams as well. After all, according to Conway’s law, organizations produce a system that mirrors the organization’s communication structure.
That’s why there are so many different tools out there. There are many ways we can structure our communication. That’s also why so many organizations build their own internal systems. At some point, to be truly efficient, you need to stop adjusting to someone else’s communication approach. Instead, you need to build a system tailored to your own. But it would be best if you got there through a painful and long exploration process first. You have to figure out what’s not working for in your case along the way.
I look for a few things in a project management system as a CTO. Let’s go through them one by one.
Sprint view
First of all, I want to have a useful sprint view. This view should show what we’re working on in a given sprint, the time spent on each piece of work so far, and its state. It’s a no-brainer, right? Well, yes and no. With a decently-sized team, it quickly becomes unreadable for you as a manager.
The problem is that most systems aim to provide as much information as possible. However, your brain starts to freeze from information overload when you’re a busy manager or C-level executive with 5–6 back-to-back meetings daily. Instead, these screens need simplification and summarization. I prefer to see a list of higher-level features in progress, with the ability to drill down rather than a complete, extensive task list.
There are usually three types of things we’re working on. Each category represents a combination of the effort required, as well as the importance and urgency of the task. It’s either one of the major roadmap priorities, an unplanned but significant and time-consuming feature or chore, or a relatively small item like a bug fix or library update. However, even the tiny things must be significant enough to work on them (if not, why are we doing them?).
Roadmap view
The roadmap view shows us what we’ve committed to this quarter and this year. We work with OKRs and maintain a list of extensive, fundamental features we’ve pledged to deliver. Sometimes, the roadmap lacks details, which we figure out as time passes. But we know our areas of focus. For instance, we semi-manually handle a process for a client each quarter. Ideally, we want to fully automate it by year’s end. We have yet to learn how, but we will do it anyway, and it’s a priority because the manual process is extremely inefficient.
The problem with the roadmap view is balancing deadlines and realistic time estimates. Our process is dynamic. Despite analysis and requirements, new details inevitably emerge during work. Circumstances change. Today, a developer thinks a task takes two days. A project manager might estimate a week. But an urgent, critical bug arises along the way, distracting a developer and consuming a few days. The developer then finds a library that needs updating to complete the initial task, further delaying progress. Switching between tasks also carries costs.
I am trying to figure out the best roadmap approach. But Gantt charts don’t work for us. They suit simple projects, but for our dev team, they’re simply unreadable. I prefer a monthly/quarterly list view. The tricky part is estimating work and keeping estimates current. With priorities set, we can roughly calculate timelines and visualize them if we have estimates.
Requests view
Finally, the third view I need is a comprehensible list of user requests. There are usually a few types of requests — bug reports (e.g., the email that I sent is not showing up in the system), requests for small things (e.g., prepare a report that gives me this list based on that criteria), and feature requests (e.g., we have a calendar integration module, now we need to take the location of the meeting into account and show it in the system in a certain way).
The problem is that these lists are enormous, at least in our work. Maintaining and organizing feature requests is a separate line of work, a product manager’s responsibility. Product managers must categorize and prioritize feature requests and add them to the main roadmap. Some feature requests can be skipped, but some are urgent. We must find a way to add urgent requests to the roadmap and decide what sacrifices we’ll make without overloading it with information.
Bug reports need timely attention — how you respond to and fix them affects how users perceive the engineering team. However, bugs also need to be prioritized. If you rush to fix every bug a user reports, you’ll unlikely have an efficient development process. Requests for small things are like bugs in that they are usually time-sensitive. You can’t always add them to the next sprint. You often have to find a way to address them in the current one.
The Main Challenge
I’ve listed these three views and realized we already have them in our system. However, the issue is that they are too complicated, and these views require manual updating. This manual process is the root of the problem. Someone must manually generate a sprint and add tasks to create a sprint view. Since we aim to be reactive and even proactive, we update sprints on the fly. However, these real-time changes do not automatically affect the roadmap.
A project management system’s biggest challenge and expectation is automatic roadmap calculation. One of the first systems I used was Pivotal Tracker, which excelled at this. For every work item, you would add story points. The system tracked the average story points the team completed each sprint. It then showed you the team’s capacity — how many things they could achieve in a future sprint. The problem was that you had to finish work within a single sprint, which doesn’t fit our process. Some features really span multiple sprints.
I’m looking for a tool that dynamically adjusts the roadmap based on real-time additions and changes without confining work to single sprints. Descriptions of new features and updates to existing items should automatically factor into the roadmap projections. The goal is an agile, responsive process that maps progress as it happens. With an automated roadmap that evolves with the work, we can plan more strategically and communicate timelines transparently. Our tool needs flexibility to support multi-sprint efforts, not force-fit them into one. An intuitive system that computes the roadmap on the fly could handle our shifting needs while keeping stakeholders informed. The key is finding the right solution to sync flexible planning, execution, and forecasting — one that fits our dynamic development style.
Originally published on Medium.com
