Ask HN: Any project management app you feel at home with?
I know there are tons and tons of PM apps. I wanna know if any of those drive your daily project management activities as (Engineering) Manager.
54 comments
As an engineering manager, what I want most from a project management app is something that does a good job helping engineers on my teams collaborate effectively with non-technical departments. We use Asana for this right now and it works well, and at a previous employer we used Jira which also worked well. Done well, it means the team always has shared state about what the latest designs are, how far along various pieces of work are, and what to-dos we need to keep track of. The goal is to offload onto the tool a bunch of status communication that otherwise happens in meetings.
If someone was starting from no system today I’d recommend Asana. Jira gives you way too much rope to make a custom workflow to enforce business rules, but as long as you have a light touch and use it mostly stock it’s fine. I have trouble organizing medium to large projects with many small sub-tasks in Trello. When I’ve used a more engineering-focused tool like GitHub Issues or Phabricator, I have too much trouble getting non-technical stakeholders to follow along there. I despised PivotalTracker trying to put me in a process straightjacket, and found BugZilla unusably ugly.
If someone was starting from no system today I’d recommend Asana. Jira gives you way too much rope to make a custom workflow to enforce business rules, but as long as you have a light touch and use it mostly stock it’s fine. I have trouble organizing medium to large projects with many small sub-tasks in Trello. When I’ve used a more engineering-focused tool like GitHub Issues or Phabricator, I have too much trouble getting non-technical stakeholders to follow along there. I despised PivotalTracker trying to put me in a process straightjacket, and found BugZilla unusably ugly.
Second Asana. I've been using it for years and it has really improved tremendously over that time. There are definitely still many things missing (most notably for me is the lack of advanced markup in comments/conversations)... but it works very well for cross-functional collaboration and longer-term project management.
I've just started using Asana in the last month, the very first thing I noticed was how incredibly slow the interface is to respond. Dragging things around on a board is particularly painful compared to Trello or Github Projects.
I also find it incredibly annoying that when you add a card to a column, it adds it to the top of the column, rather than the bottom.
However, aside from those two annoyances, it does seems to offer a lot of useful functionality.
I also find it incredibly annoying that when you add a card to a column, it adds it to the top of the column, rather than the bottom.
However, aside from those two annoyances, it does seems to offer a lot of useful functionality.
Thirding Asana. Just set up a major series of teams and projects and hooked in Zapier for some automation with a ticket system (Teamwork Desk). While Asana isn't a CRM by any means, we're creating a workflow with Kanban and automation to capture the vital interactions with clients.
Asana has the added benefit of allowing the user to interweave non-project-specific tasks to achieve something of a GTD workflow. It really helps me to get every actionable item out of my head space and assign some kind of priority / responsibility / due date to it.
Asana Premium is a must for the flexibility with custom fields (https://asana.com/guide/help/premium/custom-fields)
Asana has the added benefit of allowing the user to interweave non-project-specific tasks to achieve something of a GTD workflow. It really helps me to get every actionable item out of my head space and assign some kind of priority / responsibility / due date to it.
Asana Premium is a must for the flexibility with custom fields (https://asana.com/guide/help/premium/custom-fields)
The team I'm on currently uses JIRA but I would harshly recommend against using it. It's one of the tools on the belt of the Agile Clergy that is used to beat the peasant into submission.
The tool is expensive, constantly deteriorating in visual appeal, workflow, and support, and over complicates very simple tasks. The Agile Clergymen who work at my office boast it's integration abilities, it's high customization, and 3 charts it produces that inevitably say "You're not Agile enough" as being all one would ever need for a project management system.
In my opinion there are three main options right now.
If you're hosting an internal Software Development-only ticketing system that only the PM and the developers will interact with, and you are using GitLab, and you have the ability to host a robust GitLab server internally, I would recommend GitLab Issues [0]. It's free and open source and very integrated with the entire workflow even including time-tracking, gantt charts, etc. It's all bundled into what they're calling a Portfolio Manager [1] that has a bunch of other features you may want to explore as a PM.
If you want to use JIRA because the Agile mob is present within your organization it is a fine option so long as you either don't mind spending a very long time figuring out how the unnatural interface works and setting up a bunch of essentially needed "customization" then you can look into that. It even produces 3 pretty nice charts!
If you specifically need to take in issues and triage bug reports and feature requests then you may want to look into Redmine [2] or BugZilla [3]. Both are extremely dated but have been tried and successfully used by many large teams.
[0] - https://about.gitlab.com/features/issueboard/
[1] - https://gitlab.com/gitlab-org/gitlab-ee/issues/3254
[2] - https://www.redmine.org/
[3] - https://www.bugzilla.org/
The tool is expensive, constantly deteriorating in visual appeal, workflow, and support, and over complicates very simple tasks. The Agile Clergymen who work at my office boast it's integration abilities, it's high customization, and 3 charts it produces that inevitably say "You're not Agile enough" as being all one would ever need for a project management system.
In my opinion there are three main options right now.
If you're hosting an internal Software Development-only ticketing system that only the PM and the developers will interact with, and you are using GitLab, and you have the ability to host a robust GitLab server internally, I would recommend GitLab Issues [0]. It's free and open source and very integrated with the entire workflow even including time-tracking, gantt charts, etc. It's all bundled into what they're calling a Portfolio Manager [1] that has a bunch of other features you may want to explore as a PM.
If you want to use JIRA because the Agile mob is present within your organization it is a fine option so long as you either don't mind spending a very long time figuring out how the unnatural interface works and setting up a bunch of essentially needed "customization" then you can look into that. It even produces 3 pretty nice charts!
If you specifically need to take in issues and triage bug reports and feature requests then you may want to look into Redmine [2] or BugZilla [3]. Both are extremely dated but have been tried and successfully used by many large teams.
[0] - https://about.gitlab.com/features/issueboard/
[1] - https://gitlab.com/gitlab-org/gitlab-ee/issues/3254
[2] - https://www.redmine.org/
[3] - https://www.bugzilla.org/
I've been an Agile Tech Coach for ten years now and I actively recommend against JIRA -- or any other online tool for that matter.
Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work. If you've got your head stuck in an online system for any length of time during the day, you're not doing it right.
Tools, whether PM tools or not, are supposed to disappear so you can focus on value. If you're talking about them, spending time in them, going to useless meetings with pointless reports generated from them, etc? They stop being tools. At that point they become obstacles. Carpenters don't go to meetings with graphs of how many hammers they own. Brick masons don't spend half a day comparing the status of all of their trowels. Project Management has jack squat to do with configuring and using PM tools. Unless you're specifically training on skills, tools should disappear. That's the entire point. I wish more people knew that.
ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing. To them, the feature list of any tool is reassurance that they can continue not knowing what they're doing and somehow things will still work out fine. The tool will handle it.
Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work. If you've got your head stuck in an online system for any length of time during the day, you're not doing it right.
Tools, whether PM tools or not, are supposed to disappear so you can focus on value. If you're talking about them, spending time in them, going to useless meetings with pointless reports generated from them, etc? They stop being tools. At that point they become obstacles. Carpenters don't go to meetings with graphs of how many hammers they own. Brick masons don't spend half a day comparing the status of all of their trowels. Project Management has jack squat to do with configuring and using PM tools. Unless you're specifically training on skills, tools should disappear. That's the entire point. I wish more people knew that.
ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing. To them, the feature list of any tool is reassurance that they can continue not knowing what they're doing and somehow things will still work out fine. The tool will handle it.
> Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work.
> ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing.
This to me proves you're not in the bubble of people who I talk about when I say "Agile Clergy".
> ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing.
This to me proves you're not in the bubble of people who I talk about when I say "Agile Clergy".
I find the worst people to deal with are those who have already tried Agile and love it -- without all the experience that a few dozen teams gives you. To them, as you point out, it's much more of a religious thing.
I remember my first coaching gig. I was looking to dive into a team, get into the code, make things happen! Instead, I spent the first day in what could best be called religious discussions. It was quite odd.
But in their defense, they had no context. Agile was an abstract and nebulous thing. Instead they all had heroes/demigods that they looked to for advice from on-high. The focus was on "being correct"; tool features, usage, and adoption; having a good time with the teams. All sorts of crap instead of just making stuff people want.
I see the same thing in management, with or without the Agile part added in. Once you get removed from value delivery, even if it's only just a little bit, you end up adrift at sea. So many of the management schools are just as religious as the Agile folks. They just have different demigods :)
I remember my first coaching gig. I was looking to dive into a team, get into the code, make things happen! Instead, I spent the first day in what could best be called religious discussions. It was quite odd.
But in their defense, they had no context. Agile was an abstract and nebulous thing. Instead they all had heroes/demigods that they looked to for advice from on-high. The focus was on "being correct"; tool features, usage, and adoption; having a good time with the teams. All sorts of crap instead of just making stuff people want.
I see the same thing in management, with or without the Agile part added in. Once you get removed from value delivery, even if it's only just a little bit, you end up adrift at sea. So many of the management schools are just as religious as the Agile folks. They just have different demigods :)
My current company uses Clubhouse. (https://clubhouse.io/)
Clubhouse is Trello where each card can is synced with a git branch. As you add and push, the cards move automatically.
This helps me as a developer, because the business is always up to date with the latest progress and all I need to do is follow the company's git workflow.
To see the cards move when you raise or merge a PR is magical.
There are other features like collecting tickets together into an epic, sub projects and integrations with logging and deployment tools. If you are the manager and you implement this in your org, you dev team will love you.
Clubhouse is Trello where each card can is synced with a git branch. As you add and push, the cards move automatically.
This helps me as a developer, because the business is always up to date with the latest progress and all I need to do is follow the company's git workflow.
To see the cards move when you raise or merge a PR is magical.
There are other features like collecting tickets together into an epic, sub projects and integrations with logging and deployment tools. If you are the manager and you implement this in your org, you dev team will love you.
I second clubhouse. it's very easy to work with, not as loose as trello, not as heavy as jira. excellent integrations. it's a little young, but really a very good balance.
Used many of them. None really worked well.
As a PM, my main focus is just to get people to update what they're doing and trying to assign, distribute, negotiate, and see tasks and dependencies that need to be done.
Asana - Amazingly good in the first few versions. But it started getting slow as they added more features. Back then I would use it even for trivial things like bug tracking, because the keys and controls were so intuitive.
Google Docs/Sheets - It does the job. It's got history and versioning. Low learning curve. It's very powerful at searching (you can link to a document and it will search the linked document as well). Sheets is mildly programmable.
It's missing some tricks like tagging people and tracking who is assigned to what, attaching files, and has a limited comment system. You can't really subtask, map dependencies, or do burndown charts with it.
Jira - Hated it. Its core purpose seems to be covering asses. It makes a PM look extremely productive. It makes late night and remote workers look productive. It logs what people are doing and logs issues and dependencies. Extremely useful for people who have agile contracts for another company. But actually managing people seems to be the lowest priority of the tool.
Pivotal Tracker - Lots of potential. If you're using full Agile, this is probably the best. It's probably too heavy if you have a team of two, but even then it works. I think the Epics handling is a little messy, but it's much better than the others.
Trello - good for assigning tasks to a group. Too light for managing a pipeline from design to dev to testing to approval. At some point, it acts like email, where people get too many messages and ignore a lot of them.
I'm considering experimenting more with Google Sheets and maybe even group Evernotes. The others are a bit too clumsy.
As a PM, my main focus is just to get people to update what they're doing and trying to assign, distribute, negotiate, and see tasks and dependencies that need to be done.
Asana - Amazingly good in the first few versions. But it started getting slow as they added more features. Back then I would use it even for trivial things like bug tracking, because the keys and controls were so intuitive.
Google Docs/Sheets - It does the job. It's got history and versioning. Low learning curve. It's very powerful at searching (you can link to a document and it will search the linked document as well). Sheets is mildly programmable.
It's missing some tricks like tagging people and tracking who is assigned to what, attaching files, and has a limited comment system. You can't really subtask, map dependencies, or do burndown charts with it.
Jira - Hated it. Its core purpose seems to be covering asses. It makes a PM look extremely productive. It makes late night and remote workers look productive. It logs what people are doing and logs issues and dependencies. Extremely useful for people who have agile contracts for another company. But actually managing people seems to be the lowest priority of the tool.
Pivotal Tracker - Lots of potential. If you're using full Agile, this is probably the best. It's probably too heavy if you have a team of two, but even then it works. I think the Epics handling is a little messy, but it's much better than the others.
Trello - good for assigning tasks to a group. Too light for managing a pipeline from design to dev to testing to approval. At some point, it acts like email, where people get too many messages and ignore a lot of them.
I'm considering experimenting more with Google Sheets and maybe even group Evernotes. The others are a bit too clumsy.
Have you tried using Github repo? Kanban dashboard is excellent and you can use the milestone feature to add timebound projects.
Notion has been wonderful for me as a personal project management app. My main use cases are organizing and juggling personal to-dos across several independent projects and growing knowledge bases for each project organically as I add complexity to computational pipelines and record experimental results (I'm doing a PhD). I switched from Evernote which to me was significantly weaker in linking individual notes into larger structures.
[0] https://www.notion.so
[0] https://www.notion.so
The only system i've ever been able to tolerate is a 2-page google doc.
- shared but read-only, the manager writes
- at the top of page1 are your top3 quarterly goals
- each persons name starts a short outline list of their 2 -3 active task-goals
- since your team is 3 - 8ish ppl everyone fits on one page
- all other ideas, wants, tasks, goals, questions, etc go onto page 2, "the wishlist"
- meet twice a week, mon/thur
- monday you go around the "room" (its always a vid conf) and each person declares their 2 - 3 items
- thursday you go around the room and go over what got done and/or learned
- every quarter you start a new doc with a clean/only-a-few-carryovers wishlistNot a manager, just an engineer.
I was happiest when my team could just get by with GitHub issues. It was super simple and really easy to work with.
Eventually we used JIRA and Confluence, and it worked fine. Just make sure you keep workflows as simple as possible. I think there exists the temptation to add lots of constraints and requirements when creating and resolving issues, but that just raises the bar for getting actual things done. If reporting something takes more time than actually fixing the bug then your system is broken.
I was happiest when my team could just get by with GitHub issues. It was super simple and really easy to work with.
Eventually we used JIRA and Confluence, and it worked fine. Just make sure you keep workflows as simple as possible. I think there exists the temptation to add lots of constraints and requirements when creating and resolving issues, but that just raises the bar for getting actual things done. If reporting something takes more time than actually fixing the bug then your system is broken.
"Raises the bar" is usually seen as a positive phase. Meaning you have to be as good as the bar to do something. I think it's more clear to say it "raises artificial hurdles that take away from focusing on quality."
Notepad. Or any other code editor.
I wrote a book on extreme minimalist information management[1]. Notepad and git (along with the appropriate text tools, which might just be some shell programming) work just fine, as long as you know how to tag and organize stuff.
Even without the stuff I wrote about, what do you really need to know? 1) What work is there? 2) How much of it is done? 3) Who's doing what? 4) How are things going?
There's not a lot to it -- which is probably why you see fourteen million PM apps out in the wild.
I'd like to see PM apps make the transition that source control apps did to git. That is, moving from everybody-makes-an-app-they-sell-you to something bland, easy, free, highly configurable and interoperable -- and runs anywhere. There's no reason we can't have that.
1: https://leanpub.com/info-ops
I wrote a book on extreme minimalist information management[1]. Notepad and git (along with the appropriate text tools, which might just be some shell programming) work just fine, as long as you know how to tag and organize stuff.
Even without the stuff I wrote about, what do you really need to know? 1) What work is there? 2) How much of it is done? 3) Who's doing what? 4) How are things going?
There's not a lot to it -- which is probably why you see fourteen million PM apps out in the wild.
I'd like to see PM apps make the transition that source control apps did to git. That is, moving from everybody-makes-an-app-they-sell-you to something bland, easy, free, highly configurable and interoperable -- and runs anywhere. There's no reason we can't have that.
1: https://leanpub.com/info-ops
You seem to have missed the blatant self-promotion opportunity here. Link?
Fixed it.
For anyone interested. I also have a free white paper specifically about PM information management. Ping me.
For anyone interested. I also have a free white paper specifically about PM information management. Ping me.
This is the system that I have developed through the years, it's simple, kind of low-tech, but it works:
- Meeting starts every Monday night, 5PM/end of business day - Meeting ends when it ends. Usually 1-2 hours, but at times till midnight - Only executives, one per department: so CEO, COO, CFO, SW Development, Marketing/Sales... no more than 5 max 7 people - A google spreadheet - Projects are ranked by importance: 1,2,3 and 4. 1 High, 2 medium, 3. low. 4 just placeholder for ideas - Projects must have a completion date of 3 months or less. If longer they get broken down into <3 months chunks - Weekly deliverables. All deliverables are due on Monday - Each row is 1 project, then there are columns for Dependencies, Resources (people, money, things, outside contractors) - If one of the deliverables is going to be late, or there's a chance it might be late, the executive has to notify the executive committee by email no later than end of business day on Thursday with a succinct explanation of what's going on and revised project deliverable etc.... The CEO is in charge of eventually clarify with the Executive or take any action. If no such email arrives, the deliverable is assumed to be on-time, on-target, and on-budget by the following Monday. - Only the Executive is accountable. No blaming others.
The above was the original, these days I like to ADD to the above BASECAMP project management for any and all communications between anyone involved. Everything's public, from commitments to comments, if it's not in there, it didn't happen.
- Meeting starts every Monday night, 5PM/end of business day - Meeting ends when it ends. Usually 1-2 hours, but at times till midnight - Only executives, one per department: so CEO, COO, CFO, SW Development, Marketing/Sales... no more than 5 max 7 people - A google spreadheet - Projects are ranked by importance: 1,2,3 and 4. 1 High, 2 medium, 3. low. 4 just placeholder for ideas - Projects must have a completion date of 3 months or less. If longer they get broken down into <3 months chunks - Weekly deliverables. All deliverables are due on Monday - Each row is 1 project, then there are columns for Dependencies, Resources (people, money, things, outside contractors) - If one of the deliverables is going to be late, or there's a chance it might be late, the executive has to notify the executive committee by email no later than end of business day on Thursday with a succinct explanation of what's going on and revised project deliverable etc.... The CEO is in charge of eventually clarify with the Executive or take any action. If no such email arrives, the deliverable is assumed to be on-time, on-target, and on-budget by the following Monday. - Only the Executive is accountable. No blaming others.
The above was the original, these days I like to ADD to the above BASECAMP project management for any and all communications between anyone involved. Everything's public, from commitments to comments, if it's not in there, it didn't happen.
Imagining myself as one of the executives in this meeting, this all sounds absolutely awful, and I would be looking to leave as soon as possible.
You didn't tell us what would you like to do with it. What is your problem? What kind of projects and team sizes are you working with?
Do you need an application, at all?
I would suggest you to devise a WORKFLOW that you like, and you build or choose a (probably small) app that fits your needs.
Personally, I rarely found PM problems (reporting, calculating effort spent vs remaining, record task completion) that require a lot more than a spreadsheet, but again, I don't know what you're trying to achieve.
Do you need an application, at all?
I would suggest you to devise a WORKFLOW that you like, and you build or choose a (probably small) app that fits your needs.
Personally, I rarely found PM problems (reporting, calculating effort spent vs remaining, record task completion) that require a lot more than a spreadsheet, but again, I don't know what you're trying to achieve.
We eat our own dog food. We have a fairly complex piece of software called L-mobile PM (the marketing material for it exists only in German, sorry: https://www.l-mobile.com/geschaeftsfelder/vernetztes-projekt...)
The great thing about having our own tool (which we also license to our customers but it's far from our main focus) is the possibility to adapt exactly to how our company works. It is integrated into everything (integration and offline are our strengths) and when something doesn't fit, it usually takes a few days until a solution is found (or it is already implemented for a customer). It even has a lunch module which adds calendar entries in our outlook when we say we are attending a company lunch, and that is integrated into navision which takes care of the accounting side.
We also evaluated using JIRA at one point in the history. IMHO, if JIRA fits, go and use it, when not, you can bend it but that causes some headaches.
The great thing about having our own tool (which we also license to our customers but it's far from our main focus) is the possibility to adapt exactly to how our company works. It is integrated into everything (integration and offline are our strengths) and when something doesn't fit, it usually takes a few days until a solution is found (or it is already implemented for a customer). It even has a lunch module which adds calendar entries in our outlook when we say we are attending a company lunch, and that is integrated into navision which takes care of the accounting side.
We also evaluated using JIRA at one point in the history. IMHO, if JIRA fits, go and use it, when not, you can bend it but that causes some headaches.
> www.l-mobile.com
Your company's website is simply atrocious. It takes many seconds to load on my 100 MBit/s connection, the CPU fan immediately spins up, scrolling lags, opening the navigation / burger menu takes several seconds, further navigation again takes several seconds before anything but a spinner shows up.
Suppose I'm a prospective customer. If I saw your website, you're going to have a hard time to sell me your (presumably) web-based software, since I must conclude that it must be as slow and bloated (or worse, since it should have more functionality than delivering a static page) than your company website.
Your company's website is simply atrocious. It takes many seconds to load on my 100 MBit/s connection, the CPU fan immediately spins up, scrolling lags, opening the navigation / burger menu takes several seconds, further navigation again takes several seconds before anything but a spinner shows up.
Suppose I'm a prospective customer. If I saw your website, you're going to have a hard time to sell me your (presumably) web-based software, since I must conclude that it must be as slow and bloated (or worse, since it should have more functionality than delivering a static page) than your company website.
It's done by the marketing team (probably a paid theme - I'm not sure). Our web-based software is developed by completely other teams. I agree that the web site needs work, they probably need help.
Thanks for the feedback, I'll pass it forward.
Thanks for the feedback, I'll pass it forward.
People have asssumed you're asking "what PM app do you recommend" but you're not - you're asking if engineering managers use one to drive daily activity. Good question :)
Every business works differently, so all PM apps in their default config will match 80% of what you need, for 80% of businesses.
If a manager implements an app without customising it to the business, users will be frustrated, directionless and end up hating the app - see user comments in this thread!
Bespoking it to the business allows users to do their jobs with minimal interaction AND WITHOUT MICROMANAGEMENT.
Finally, without management buy-in (that's you!), without you actually using the inputs and outputs of it, it will fail - lead by example.
Hope this helps :)
Every business works differently, so all PM apps in their default config will match 80% of what you need, for 80% of businesses.
If a manager implements an app without customising it to the business, users will be frustrated, directionless and end up hating the app - see user comments in this thread!
Bespoking it to the business allows users to do their jobs with minimal interaction AND WITHOUT MICROMANAGEMENT.
Finally, without management buy-in (that's you!), without you actually using the inputs and outputs of it, it will fail - lead by example.
Hope this helps :)
For agile story tracking and development pipeline management, Pivotal Tracker. Lots of great features for team productivity and health tracking, also helps as you automate your workflow. For general tasks and individual workflow, Trello. By far my favorite UI and delightful experience in using for simple workflow management using a kanban style (which plays a large role when you use it regularly). Trello is less useful the more team members that join and the more complex the workflow you need to manage.
Two apps drive it for us which are self hosted on Google cloud 1. kallithea-scm (https://kallithea-scm.org/) generating analysis of code commits, with webhooks to 2. Taiga (https://taiga.io) for project and issue management which we use for kanban boards, sprint planning and review and issues management. They do drive our engineering team on daily basis.
https://www.phacility.com/phabricator/
Give it some love.
Give it some love.
Phacility
Phabricator
Pretty much just JIRA and communication/storage apps on the side (like Slack and Google Docs). A lot of people seem to hate JIRA, but as long as you keep it simple and only keep some border requirements rigid, it's pretty sweet to work with.
Other setups I've worked with are Trello-style (but not actual Trello) kanban boards, be it a physical board or a board implemented in something else. In some projects it worked very well with GitLab and GitHub integrated project tools. As limited as they are, they are a great minimal way to workflow your stuff. Anything more complex than that is often in the wrong place and should most likely be managed at a different (non-engineering) level. Perhaps that is why JIRA works for us as well on most projects; we tend to not mix engineering and non-engineering stuff as they often have different needs where even small differences make for a bad combination in the same tool.
Other setups I've worked with are Trello-style (but not actual Trello) kanban boards, be it a physical board or a board implemented in something else. In some projects it worked very well with GitLab and GitHub integrated project tools. As limited as they are, they are a great minimal way to workflow your stuff. Anything more complex than that is often in the wrong place and should most likely be managed at a different (non-engineering) level. Perhaps that is why JIRA works for us as well on most projects; we tend to not mix engineering and non-engineering stuff as they often have different needs where even small differences make for a bad combination in the same tool.
Emacs + org-mode has always served me well.
We tried a bunch of PM apps in my company, but couldn't find ones that did time tracking and invoicing well. We just needed something simple - an app that would let us list our project tasks and tick them off as they were completed. Eventually we built our own for internal use. Some of our clients saw us using it and asked us to wrap it into a service - so we created https://usebx.com - we still use it internally, and it's serving us well (we're a team of 25).
I have recently discovered Backlog - disclaimer: due to being hired by the company, even if not in that team. If you google "backlog project management" it should be the first result.
I honestly like it very much. It is way easier to use than Jira, nice modern UI/UX, integrates with git etc. It has enough features to help with larger projects, and you can shut off features you don't need. There's even more to say, but I don't want to spam the thread.
I feel the product deserves credit. You can try it out.
I honestly like it very much. It is way easier to use than Jira, nice modern UI/UX, integrates with git etc. It has enough features to help with larger projects, and you can shut off features you don't need. There's even more to say, but I don't want to spam the thread.
I feel the product deserves credit. You can try it out.
Pivotal Tracker.
One backlog. It forces everyone to truly think about priorities and by its design, avoids the “everything is important, mark it a P5!” issue.
One backlog. It forces everyone to truly think about priorities and by its design, avoids the “everything is important, mark it a P5!” issue.
I really, really miss pivotal. I have to use JIRA these days. The access to information, speed, clarity, and simplicity of pivotal makes JIRA feel borderline masochistic.
That's also the fault of my process-obsessed co-workers who, in my opinion, often prize how we do work over actually doing work. Our workflows are hilariously over engineered. Even so, pivotal is great. I'd choose it again in a heartbeat.
That's also the fault of my process-obsessed co-workers who, in my opinion, often prize how we do work over actually doing work. Our workflows are hilariously over engineered. Even so, pivotal is great. I'd choose it again in a heartbeat.
I’ve always found Trello to be just enough for my needs. https://trello.com/
I know Jira and Confluence get a lot of hate but the companies I’ve worked for always seem to favor it and I’ve gotten very comfortable in there now. If I were at a company with <20 people then I’d go with Trello. >20 then Jira
I know Jira and Confluence get a lot of hate but the companies I’ve worked for always seem to favor it and I’ve gotten very comfortable in there now. If I were at a company with <20 people then I’d go with Trello. >20 then Jira
CA Agile Central (Rally) works quite well if you need to manage a portfolio of many long-term programs and teams. It lets you coordinate roadmaps, balance workloads, and plan at varying levels of abstraction. But it's probably overkill for small organizations, and requires some training and customization to use effectively.
I been using Monday.com rather successfully for that past couple months, I'm using to track project work, sprints, bug queues all the way to using it for tracking my own morning routine.
While it doesn't have all the bells and whistles or even the integrations as Jira or Asana, I've found it more useful.
While it doesn't have all the bells and whistles or even the integrations as Jira or Asana, I've found it more useful.
My experience has been that the most important consideration in a project management tool is simplicity and ease of use, which is why I find Github's issue tracking with threads + tags + milestones to be the gold standard. If you need private hosting you can use GitLab/Gogs/Gitea.
After many years trying a vast variety of project management software, I've come to the conclusion that what matters most is the project manager, rather than the software. Nowadays when I consult with clients I advise them: "First, find a really good project manager, and then use whatever software they want to use." If you have a great project manager, and they prefer to keep track of everything on crumpled up napkins, then the whole team should be given an ample supply of crumpled up napkins. Great project managers are rare, but if you have a great one, you should let them set the parameters of project management for your project.
When you have a bad project manager, good software will not save you. This is my personal story of how things can go wrong:
-----------------------------------
At 2 PM we had a meeting scheduled to go over all of the tasks in PivotalTracker. John had promised Milburn that we would execute our work according to a project-management philosophy that the tech industry called agile. Agile software development, among many other aspects, focuses on the delivery of small, incremental improvements to software. It encourages self-organizing teams, evolving and continuous progress, and rapid response to challenges faced. The Celolot team would work two-week sprints, checking in at the end of each period to see where everyone was at.
Unfortunately, vague definitions of “done” haunted our progress. John read through a long list of tasks that had been assigned to Sital.
“Find all possible variations of ‘Close Date,’” John read from the screen. “Is this done?”
“Yeah,” muttered Sital. “Sure.”
His assurance meant nothing to me. Sital would never lie, indeed I was often surprised by his childlike honesty, but he lacked an appreciation for the many ways that software could break.
“How many variations have been tested?” I asked.
“Two,” replied Sital.
“That’s not enough,” I said.
“That’s enough,” countered John. “‘Close Date’ and ‘Contract.’ That’s all we need.”
“What about ‘Close’?” I asked.
“Oh, yeah,” John thought aloud. “What about ‘Close’?”
“I’ll see,” Sital responded somewhat robotically.
John marked it as done.
“Wait,” I objected. “That is not done.”
John turned back to Sital. “Do you think you can finish today?”
“Absolutely,” Sital assured us.
“Then I’ll mark it as done,” said John, returning to his screen.
“But it’s not done till it’s done,” I argued.
John pondered this for a brief moment. “It’ll be done today,” he shrugged. He marked it as done.
In my view, John’s casual use of the word “done” to refer to items that were nowhere near done meant that this whole effort to track tasks was a useless ceremony. But John felt good about it. He could tell Milburn that we were following a two-week sprint, just like an authentic agile team.
It was true we had the accoutrements of an agile team. We used PivotalTracker. We broke down goals into fine-grained tasks. We reviewed the task list once a week, and we added more tasks every two weeks. But the whole thing was mockery of what the Agile Process was supposed to accomplish. If you have programmers who cannot finish assignments, then there is no point in pretending to be making progress.
----------------------
related to here:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
When you have a bad project manager, good software will not save you. This is my personal story of how things can go wrong:
-----------------------------------
At 2 PM we had a meeting scheduled to go over all of the tasks in PivotalTracker. John had promised Milburn that we would execute our work according to a project-management philosophy that the tech industry called agile. Agile software development, among many other aspects, focuses on the delivery of small, incremental improvements to software. It encourages self-organizing teams, evolving and continuous progress, and rapid response to challenges faced. The Celolot team would work two-week sprints, checking in at the end of each period to see where everyone was at.
Unfortunately, vague definitions of “done” haunted our progress. John read through a long list of tasks that had been assigned to Sital.
“Find all possible variations of ‘Close Date,’” John read from the screen. “Is this done?”
“Yeah,” muttered Sital. “Sure.”
His assurance meant nothing to me. Sital would never lie, indeed I was often surprised by his childlike honesty, but he lacked an appreciation for the many ways that software could break.
“How many variations have been tested?” I asked.
“Two,” replied Sital.
“That’s not enough,” I said.
“That’s enough,” countered John. “‘Close Date’ and ‘Contract.’ That’s all we need.”
“What about ‘Close’?” I asked.
“Oh, yeah,” John thought aloud. “What about ‘Close’?”
“I’ll see,” Sital responded somewhat robotically.
John marked it as done.
“Wait,” I objected. “That is not done.”
John turned back to Sital. “Do you think you can finish today?”
“Absolutely,” Sital assured us.
“Then I’ll mark it as done,” said John, returning to his screen.
“But it’s not done till it’s done,” I argued.
John pondered this for a brief moment. “It’ll be done today,” he shrugged. He marked it as done.
In my view, John’s casual use of the word “done” to refer to items that were nowhere near done meant that this whole effort to track tasks was a useless ceremony. But John felt good about it. He could tell Milburn that we were following a two-week sprint, just like an authentic agile team.
It was true we had the accoutrements of an agile team. We used PivotalTracker. We broke down goals into fine-grained tasks. We reviewed the task list once a week, and we added more tasks every two weeks. But the whole thing was mockery of what the Agile Process was supposed to accomplish. If you have programmers who cannot finish assignments, then there is no point in pretending to be making progress.
----------------------
related to here:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
Phabricator!
It’s an open source software development platform can do pretty much ANYTHING you want and if you know PHP, you can add everything you need at low cost! It has task management, code repository, code review, team collaboration syatem, knowledge sharing and ...
It’s an open source software development platform can do pretty much ANYTHING you want and if you know PHP, you can add everything you need at low cost! It has task management, code repository, code review, team collaboration syatem, knowledge sharing and ...
I don't care what anyone else says, I always come back to JIRA. The basic usage is simple enough. Everything is customizable although you can shoot yourself in the foot if you overthink it. It's great at associating tickets in various relationships. It integrates very neatly with version control and CI systems. Anytime we try something simpler, we hit a wall and end up back with JIRA.
Yeah. And frankly I love making filters with jql. It really works.
I’ve tried many systems, but Thoughtworks’ Mingle is still my favorite.
Brightpod :) Everything that needs to be tasked goes in there.
[deleted]
Trello’s outstanding for relatively small projects.
I use taiga projects. It's awesome.
Nobody loves Basecamp anymore?
Basecamp
[deleted]