A critique of project management software
erock.io
erock.io
Instead of being a tool to help us do our job more efficiently, it has become a source of busy work, that requires extra employees to use properly.
After switching to Jira it was so locked down with arbitrary rules that I need to take a break every time I use it.
I'm seriously considering looking for a new job that doesn't use a corporately mandated system, or have daily stand ups.
#1 - "Those who manage best, manage least." Spend the minimal amount of time on project management. Even project managers should spend a minimal amount of their time "project managing," which leads directly to #2...
#2 - "Project manager is a task, not a job." No one in the company should be a "project manager," and nothing else.
The rationale is that if project management is a job, project management becomes the sole work output. And optimizing for that output leads to all the worst excesses I've seen at companies. And consequently, all the shit products (or shit design choices within good products) listed.
If you have a perfectly tracked project that took 100s of person-hours to generate and update tracking docs, what does that do for your end users?
People do their jobs. Make sure everyone's ultimate job is to bring value to the company.
PS: And to head off the complaint that this ignores project scale, your company is not IBM. You don't have the management problems 1960s IBM had. So stop using solutions to "How do I orchestrate the progress of 100s of developers all working on the same project?!" Because the number of projects that large, that can't be broken into subprojects, is very few.
And why do it? So proper data is in the project management tool. Then people with the actual correct responsibility/authority/expertise can make good decisions based on good data.
Also cuts down on interruptions. You go from quadratic communication (M stakeholders pinging N engineers) to linear (M stakeholders consuming 1 feed that's fed by N engineers). In theory, everyone just keeping their tickets up-to-date would get rid of that need. History has shown that doesn't work. Also a sufficiently smart tool would cover it, but it hasn't been made yet. Maybe a 20-year-old who sits in on meetings, gets a notification for every PR state change and nicely asks people how things are going would do a better job.
Works great and I love that the UI hasn’t been redesigned and just works.
Everyone is having a blast doing SCRUM until some manager decides it would be cool for them to keep track of how many story points the team completes as some sort of performance metric.
Author here. I totally agree with you. We are currently using JIRA at Aptible and the general consensus is to use it as little as possible. I'd much rather have a system that is streamlined around delegating tasks to teammates and then a playground for the independent contributors to figure out how they want to break the tasks down.
I'm definitely keeping your feedback in mind if I continue to build this prototype out. If you'd like to receive updates about my progress, signup with your email at the bottom of the blog article.
Thanks!
At least that’s how I ended up with boards that absolutely didn’t match my workflow and required me to copy / paste tasks from one board to the other to pass it off to the next step (QA), with QA feedback via Slack.
That’s not quite my ideal "single source of truth" regarding what I have to do.
Just like when creating software, incidentally.
Having IT own Jira administration is great for IT job security and terrible for everyone else.
(Note: old Jira absolutely encouraged a one-size-fits-all approach to administration. Everything was done with the assumption that it would be cross-project, which created a morass of assigning things things. “New” Jira project are more self-contained, and so much easier to configure)
I want something much much simpler. Stick to the worse is better approach and adhere closer to the philosophy of doing one thing well.
It creates a class of salty user who go around doing things like calling you a blight in public.
Know your audience. UX != DevEx.
I hope not to do that again.
Everyone does Task #1 fantastically. Task #1 is easy, it's greenfield by definition.
How does your solution scale to Task #5509 when things have gone pear-shaped and there are legacy considerations that demand consideration?
The idea here is the "Roadmap" view you're seeing only shows tickets which are not completed. You might have Phase 1 -> Bugs (e.g. #803) opened 2 years ago and not closed if you choose to organise them that way but the Task #5509 comes, get completed then is removed from the view.
Still playing with how to scale projects across multiple departments and show only the tasks your team cares about though, which would make that view even smaller. Right now I'm thinking either by being able to filter on any single Task or just use the existing Labels. Thinking about how to do this without bloating the language with Teams or Squads etc. though is interesting.
It ticks all of the boxes and more boxes than its competitors in customers' managements' requirements spreadsheet, it's priced to sell well, there is an ecosystem and a marketplace, and the sales demos show that all of this works smoothly.
We should be praising Atlassian for following the UNIX philosophy, not condemning it.
Jira's JQL is it's superpower, at least for finding and summarizing stuff, though it is better if issues are categorized well. The key to that is making sure it's not actively hostile to your users. Unfortunately the defaults and the way the admin tools enable BOFH-syndrome make this an uphill battle, which is why so many jira installs are bad.
Now that said, the speed, stupid markup syntax and some other things still would make me do a good look for others prior to starting something on jira again. But jira can be decent, and there is much, much worse.
Author here. I totally agree with you. Not only that, we purchase the software because it sells us on being able to fit the needs of the organization but at the end of the day most of the companies I worked for only use sprints successfully.
I wonder if Jira inevitably becomes slower, overtime, as customers add configuration they deem necessary. Jira, having multiple options available, will happily accommodate it without considering optimization as a boundary. A vanilla instance of Jira, more than likely, outperforms any custom configuration a customer will eventually apply.
But that's just one theory.
If you've got a team of people that need a lot of hand-holding, the two can be the same. In most cases though there is a lot of experience on the team. In that case task management too easily becomes micromanaging.
What is needed instead is managing against milestones and trusting your team members to execute against it. Some team members can be trusted on certain tasks more than others, but the solution is closely monitoring those that need support, not forcing task tracking across the entire team.
In all my self-directed work with small teams- you’re right, we just needed a task manager. The overhead of PM would have been a net negative. We basically just needed to track our own conversations with each other.
Some of our clients use MS TFS and it's a complicated mess
I’ve been looking for various software for a while as a potential replacement, and after looking at a variety of open source tools for different parts of our devops process (code hosting, CI, ticketing) I’ve realised that, bigger more well known projects have the best integrations with other tools by far, and also due to their integration between features have the least friction when using day to day.
I’ve lately been looking to GitLab, which looks like it has the middle ground between simplicity of task management, and complexity with a billion features and concepts like Jira. Does anyone who has used it extensively have any experiences to share?
Depends perhaps on what you mean by “task”, but I don’t get this one. Surely your OKRs are how you measure success of most of what you do that quarter, and there are only a few of them. What value does task-level tracking really add?
I’d go as far as saying that task-level tracking may be of value to the individual, but progress generally should be tracked at the level of deliverables and outcomes. When I was a manager, I made a point of not looking at task-level data. To focus on them is a recipe for micromanagement.
The main critique about OKR software that I don't like is that it's a separate system from where things get done. When thinking about a product team and having an OKR set, it's sometimes beneficial to think about what the team is doing every week that helps them achieve their OKRs.
I'll be writing more articles about the product idea to make it more clear what I want to build. Happy to read any feedback or if I'm wasting my time!
What I liked most about it is that you can combine the same tasks together in multiple places... which helps me since many tasks don't always fit in a single hierarchy. I.e. a circuit board design could be in the "electronics" folder, but also could be part of a specific prototype build.
It's actually slower than JIRA, which is impressive.
it's something i have always been missing, the graph-like nature of all these things, always being bricked into some tree-or-list-like single-parent stiff structure..
* Rigid and difficult to experiment
* Difficult to scale with a company
* Difficult to couple OKRs (objective and key results) with tasks
There are features that involve project and portfolio-level reporting, forecasting, task assignment, feature definition, change-request management, team collaboration, etc.
All of these are important, but maybe bundling is not the right answer at this point.
I think that's why do much discussion comes down to "feature debate". Users talking about features they hate in their PM software and new software explaining they don't have those features.
It's a discussion focused on reducing pain rather than productive benefit.
It would be good to rethink what we really want from PM software, specifically, and how to optimize one or two core use cases.
This is not criticism of Wormhole. It might be a great software, but it follows the same pattern of discussion "You know all those features you hate in your current PM software? Well, this software doesn't have those features."
I don't want software that just sucks less. I want software that makes my life better.
> It would be good to rethink what we really want from PM software, specifically, and how to optimize one or two core use cases.
I love this line of thinking. What do you really want from PM software?
I guess good PM software should be more than the sum of its parts. Using a bunch of best-of-breed solutions with no integration is a pain, but that's usually better than well-integrated mediocrity. Although at larger scale, the integration becomes more and more important.
This is great because you can replicate tags, folders or any other organization structure this way
Other project management tools enforce a rigid containment hierarchy (projects contain tasks which contain subtasks) and allow flexible organization only through filters (which tend to produce flat and not tree-like output). Wormhole would let me create hierarchical views without copying content
Personally I like to generate a lot of documentation for my own needs. (Lately I started a diary of chocolate bars I eat, but there's a story behind that.)
That's how I can pick up on Monday where I was Friday. If I get interrupted it's how I get back on track. It's how I can pick up the code I wrote six or eighteen months ago and repurpose it.
I'd be happy to file my notes with the ticket, but this would drive my coworkers up the wall, so I don't.
It doesn't provide the granular control or extensibility like Jira, but do try to read about their manifesto and how things should work.
What's interesting is your wireframe actually looks a lot like Basecamp, with Sprint options. At one point we were using Basecamp as well, and find Basecamp don't cater to more complicated ticketing and workflow.
FWIW, we built Kitemaker to tackle some of the points that the original articles highlights, but of course, our solution is a bit different from the authors. Our basic idea was that each work item should be a collaborative workspaces and allow you to track work at the level of deliverables (which basically is what many would say is the correct level, but AFAIK no issue tracker actually supports).
Also, always curious why you switched to Linear :)
I have a hobby of trying out different project management software and I even went back to a pen and paper notebook for a while.
But I’ve become a huge fan and advocate of Todoist. So lightweight yet very flexible.
*sorry if this sounds like a marketing message. I don’t work for the company or know anyone that does. I’m not invested in the company other than a happy customer.
In my opinion, based on my needs on every project I've worked on, I've yet to use a project management software that did anything better than a simple Trello board or the like. At the end of the day, I want a list of tasks, a way to indicate the status on the task, a discussion section for the task, and to be able to close it when I'm finished. That's about 99% of what I need it for. Well, besides the fact that it also should provide insight to management.
My issue with project management software that's more complicated than a set of to-do lists is that they seem to be designed to make you invest in that specific product. They are different enough from each other in terms of layout and workflow that they are unique yet those differences offer no clear value. Depending on which one you use, you have a "task", or a "story", or a "ticket", or an "issue", or something entirely unique if it was written by some clever person for internal PM software.
Then there are concepts like "milestones", "epics", "iterations", and "sprints" (speaking of more concepts I've never needed). You might be "assigned" a task, or perhaps you are the "owner". It's all so tainted by Agile that we have to speak this goofy ass language which makes us feel more sophisticated than the rest of the world which... does the same thing using common verbage.
Worst of all is these tools have barely any meaningful integration with source control hosting like GitHub or GitLab. Yes, they can do nifty things like show the title of the GitHub issue, but every place I've worked for forced me to ping pong between the PM software and GitHub/Lab and I always ended up having to manually sync things between the two. Or I would have to manually copy information between the PM software and whatever non-engineers were using, like Asana.
Like, I really don't care that badly about having to sync some things by hand, but it's a nuisance when the tool pretends to be advanced by shoving a bunch of information, terminology, and processes in my face. Give me a tool that will stay out of my way.
---
Oh, yes, the article.
> The thing I really like about this idea is that the user can organize their hierarchy however they like. They are not restricted to what the software defines as an “epic.”
Yep, exactly. It should get out of the way and not force organizations or individuals into hard and fast paradigms. Funny how we overuse abstractions in code but our project management tools are overly concrete.
> Want to create a sprint? Create a circle and reference other circles within it. Want to create an epic? Create a circle and reference other circles within it. Want to view your circle and its children as a kanban? It supports that. Want to move circles around, such as nesting them or unnesting them? It’s as easy as pressing “tab” or “shift+tab.”
Although obviously I'm not a fan of adding more neologisms, the way that circles work here definitely sounds appealing in terms of flexibility. In this case, it kind of makes sense since a circle doesn't necessarily have to represent anything in particular besides what the user wants it to be.
> I want a project management solution that:
> - Emphasizes team collaboration
> - Is able to scale with a company’s growth
> - A playground for teams to experiment and build tasks
> - Ability to capture OKRs (objectives and key results)
> - Task management
Most project management software claims to do most of those things. Not that you aren't right in wanting those things, but the possibilities circles have is the main selling point IMO.
I do, though, often see stuff managed using Kanban when it's pretty clear that there are dependencies making the work out of sequence and inefficient. It seems there are fewer and fewer people that can break out a Gantt or Pert chart and identify stuff like "the critical path".
As to the article, I agree with a lot of the author's points. The author talks about lack of features for collaboration. and I agree. What's wrong with the comment systems in Trello or Jira? I think it's that they don't model how people actually collaborate, which often goes something like this: (1) I have a question for someone else on the team, (2) that person answers or passes it to someone else who can, (3) repeat until I've got the answer, (4) reflect the answer somewhere (designs, description, etc.), (5) consider the matter resolved. Many of these might be going on in parallel, and the back-and-forth is often asynchronous. A single comment stream just doesn't lend itself to this kind of collaboration. Neither does Slack where, as the author says, requests for follow-up easily get lost.
The extreme flexibility of the "circles" is interesting. On the one hand, it's nice to give control over to the users and let them model whatever use case they have. On the other, a tool that's too open-ended may overwhelm users with options when they should really be focusing on dev. (Of course, that could be solved with intelligent default templates, or something along those lines.) I'm curious to read others thoughts about that.
Author here. I agree. A big concern is I build this flexible system and a user jumps in to use it and sees a blank screen. No story section, no sprint section, no epic section. They get bewildered and end up not using it. Do you have any other thoughts on how to combat users being overwhelmed by a blank screen? I could have templates that people could "load" that would set a project up like a traditional project mgmt solution would?
Author here, I totally agree with you! I love using trello but every org I've worked at eventually outgrows it and moves onto something more akin to Trello. Why do you think that is?
> My issue with project management software that's more complicated than a set of to-do lists is that they seem to be designed to make you invest in that specific product.
Definitely. As a team lead there's this natural inclination to make your sprint "perfect." I've gone down the rabbit hole of creating a strict workflow where cards have to move from status to status in a specific order. People end up overriding it and doing what they want. And at least for startups, most of the tickets we thought were important, in a few months, are totally irrelevant, thus negating all the work that was done to get those cards properly written.
I'm hoping that I can keep what makes Trello great but add just a touch more team collaboration and project managemenemt-like features to make it so teams don't eventually jump ship to something like JIRA.