Building software has become more complex (too complex!).
Yesterday, I was having a heated discussion on a ticket. Let’s just say I was disagreeing with someone else on the said ticket :). As in any discussion, each time I posted a comment, I was awaiting the reply. And I know for a fact that the other person was doing the same. But how did I know when I got a reply? Not from the ticket page, which wouldn’t show me if the other person was writing or didn’t update itself when a reply was sent…I would wait for the Slack notification, which prompted me to refresh the page.
Why should just having a conversation on a ticket be so difficult? Can’t we have some chat-like experience at a ticket level? No wonder I see so many developers switching to Slack to have a conversation on a ticket rather than discussing it on the ticket! But then, the content of the discussion is lost to all other members of the team. If another developer wants to understand the decision that was made, they can’t just go to the ticket and understand the reason. And obviously they won’t go try to find it on Slack.
Then, I thought about this: why do we have this kind of love-hate relationship with our project management tools, and just feel pure love for tools like Slack. Why is that, what is the difference?
So, I decided to research this topic, while mostly focusing on the software project management use case – because that is my expertise and most familiar to me. What would make the perfect project management platform for developers and managers alike?
Let’s start by looking at the specific needs of project management.
Project management is about team collaboration based on tasks. That implies task updates all day long from you and your team. Some might not impact you and your work, but some might. This implies that you need to be notified of the impactful updates, and as soon as possible while screening out those that don’t impact you and would be distracting.
Every team is unique and views things differently based on their role in the organization. Therefore, they most probably have unique workflows, meaning workflow customization is a must within organizations. And, the greater ability to personalize is better for the team’s productivity.
The process of building software is highly collaborative. Discussions are an important and essential part of the process. There will always be synchronous discussions among team mates and at times multiple threads.
Whether you have a customer-driven or top-down approach, your team will have team priorities and goals. Each individual in your team will have part of the responsibilities to achieve those goals, and will therefore have their own priorities. And of course, your department will have overarching goals that should reflect all its teams’ ones. Having visibility across those hierarchy of goals and priorities impacts the teams’ and individuals’ ability to achieve their own.
So, given all of this, here is a list of things that I would like to see in the project management tool that my organization is using. Please feel free to disagree or add things in the comments.
Why? Because project management has a high-frequency and possibly high-urgency use case. There is a great article showcasing when a desktop brings much more value than a web app. I’m borrowing the article’s chart:
Urgent means that you need to react fast to things happening, for instance, an incoming chat message or quickly muting the music. Frequent is self explanatory.
Think about it. What does desktop bring more than the web app?
Easy access with Alt+Tab (or Cmd+tab) or to the icon in the dock
Visibility of the app status with the icon in the dock that can show badges to show you how many new messages you missed. Just a quick glance and I know if I can continue working without losing my focus.
Better access to the notification system with more controls.The icon in the dock can move to draw attention for any important information for instance.
There are some drawbacks using desktop apps, too. You need to install the app, and keep it updated. If the app is distributed through the App Store, updating becomes easy since it is automated for you.
Now, let’s look again at project management. With Slack, this is probably the tool that I use most often during the day (and of course my text editor!). Imagine a Slack-like experience for the comments on a ticket within your project management tool. You would see when you have a new message on a ticket based on the badge of the tool’s icon. You would have easy access and wouldn’t need to open a new browser tab for each new ticket update you want to view or act on. In my case, I typically have between 6 and 15 tabs open for the project management tool I’m currently using. That is slowing my browser experience altogether.
The Slack live chat experience is what I’m expecting from my project management tool because of the need for frequent collaboration. That makes me wonder, what if we could we see an indicator when another user is currently writing a new comment on a ticket and it could update the ticket page instantly without having to do anything, like refresh the page? I can assure you conversations wouldn’t happen on Slack if this was the case and they wouldn’t be lost. It would make our lives much simpler and productive to have all decisions documented and reside in the same place for reference later, if needed.
Interruptions are the top productivity killer for developers, We’re overwhelmed by the notifications coming from all the tools we use between project management, code versioning, crash reporter, CI, etc.
Having great control over notifications is important. For instance, getting your notifications through Slack will give you a chronological feed of all what happened. You won’t miss anything, but the data is not structured so that it is easy to understand what you missed. The Asana “Inbox” does a better job at structuring and displaying this data and giving you control on what you should be notified about. Jira Cloud’s mobile app is also heading in the right direction with the ability for me to manage the notifications I missed with “Mark as Read” or “Clear”.
But also being able to access external information related to a ticket is very valuable for a developer. For instance, having all sentry.io’s crash information directly in the ticket, or all information on the commits and pull requests right from there simplifies the developer’s understanding of tickets. That’s why deep integration with the other tools is so important for a project management tool.
Another point is the speed of access, so ideally the ticket page should load very fast. Any time wasted on a page loading is productive time lost in my day. Textual information could be loaded before assets or any other heavy files. Just make it fast!
We need to be able to set up workflows that correspond to the way the team is working. Jira is the most customizable tool out there at the moment, and no doubt this is one of the reasons why a lot of us use it. Still, personalizing workflows with external tools feels like a full-time job right now, while it shouldn’t be. We shouldn’t need to code script to use the Jira API to do the workflow we want between our code versioning tool and the task management one.
Knowing what to work on should be easy for any contributor. Actually, maybe Asana nailed this one with its section “My To-do”, where you can see all that is assigned to you, and you can even reorder the way you want (without unnecessarily notifying your team). This is great for personal productivity.
I’ve been talking to a lot of managers lately. And a lot of organizations are using spreadsheets on top of their project management tools because they don’t have easy access to a high-level picture. Indeed, current tools are limited in terms of parent-child relationship. At best, you have 3 levels with epics / stories / sub-tasks. Being able to have a full tree with unlimited levels and ability to have visibility at any level would help tremendously.
It would give better visibility to managers, but also to contributors helping everyone understand, are we on track or not? Where are the risks and dangers? We could have interdependencies across teams that would better highlight those risks, leading to better collaboration across teams. That’s why you have project portfolio management tools that integrate with project management tools. But why can’t everything be in the latter?
Sure, there are other details that come to mind too. For instance, our scheduled work is during the day, but there are also times when we work during the night. So having the option of a dark mode that is easier on tired eyes could be interesting. Developers are very proficient with keyboard shortcuts. So that’s important too, anything that can enable us to do the things we want to do in a faster way adds value. Same for command lines. I’m sure you have other ideas like this. I would actually be interested to see them, so please add them in comments.
No, not right now. We have bricks here and there.
Actually, you can see what is most important to teams. Jira seems to be the clear leader among engineering teams. And it is the best at customizing to your workflows, along with other tools integration. Those two points — customization and integration — are very important to engineering teams.
But at the same time, if you talk with developers, you clearly see a love-hate relationship with Jira. A lot is missing for the individual use cases: personalization at the individual level, live conversation features and notifications using a desktop app.
But that doesn’t mean it’s not coming. At Anaxi, we’ve actually started to build such a platform. For the moment, we integrate with GitHub and Jira (both cloud and on-premise). But we intend to integrate all your tech stack, so you have all the information you need for every ticket. We just released today our Mac and Windows native apps, because we do intend to leverage the desktop specific capabilities to provide a better collaboration experience. You will be able to deeply personalize what you see and how you access the information, based on your individual needs — without Anaxi messing with your data sources. If you’re curious to learn more, check out anaxi.com.