6 ms·

My biggest problem with using these tools is mandates forced by someone in the company that no one on my team has ever met. As another commenter pointed out, I

My biggest problem with using these tools is mandates forced by someone in the company that no one on my team has ever met. As another commenter pointed out, I just want a big checklist, with sub check lists, and a handful of properties, that i can create update and delete at will. 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.

ethbr0 5y ago
There are two things I've decided are true, regarding project management. #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.
- travisjungroth 5y ago
  I've kicked around the idea that project manager should be a very low level job. Like first job out of college or maybe high school. The job would be: make sure the current state of the project is reflected in our software. No predicting the future (burndown, gantt), no changing the future (make sure it gets done on time) and no responsibility without authority trap. I think one person could support a very large project (or more smaller ones) this way. 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.
gego 5y ago
I totally feel you, I sometimes just set up a local Redmine or simple task list in the lan that really gets used while I make the entries in whatever our corp gods decree the flavor of the month...
- liketochill 5y ago
  I’ve been using Redmine for nearly a decade. Download the bitnami VM with it preinstalled and away I go. I use it for all my time tracking to generate invoices, and project estimates. Then when working on the project I can put time against an existing estimates task or if I missed something in the estimate or something was added I’ll create a new task for the extra. Works great and I love that the UI hasn’t been redesigned and just works.
jrodthree24 5y ago
This also applies to how we work too. 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.
qudat 5y ago
> 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. 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!
ElFitz 5y ago
Yeah. Another of the issues is that it’s picked by people who (supposedly) chose the right tool for them, without considering wether or not it was optimised for those actually doing the tasks. 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.
- robertlagrant 5y ago
  It's possible to misconfigure any tool, that's for sure.
  - ElFitz 5y ago
    Even more so when those allowed to do the configuring aren’t those that’ll actually have to work with those tools and didn’t bother to ask anyone anything. Just like when creating software, incidentally.
nradov 5y ago
A big checklist of planned changes can work fine for a small team with a single product. It breaks down when you have many teams working on a whole portfolio of products with interdependencies and external customer commitments. In that situation a tool like Jira or Rally is usually the least bad option (unless your organization is huge enough to justify building your own custom project management tool that precisely meets your needs).
vosper 5y ago
IME this is a problem of policy, not of Jira. Empower teams to administer their own Jira projects and it’s fine. But if you lock Jira down and make people beg to some distant and aloof gatekeeper every time they want to change anything, then it’s a recipe for frustration. 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)
- robertlagrant 5y ago
  Yes, this. I wasn't recognising anyone's problems with Jira, and this is probably why.

ethbr0 5y ago

There are two things I've decided are true, regarding project management. #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.

travisjungroth 5y ago
I've kicked around the idea that project manager should be a very low level job. Like first job out of college or maybe high school. The job would be: make sure the current state of the project is reflected in our software. No predicting the future (burndown, gantt), no changing the future (make sure it gets done on time) and no responsibility without authority trap. I think one person could support a very large project (or more smaller ones) this way. 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.

gego 5y ago

I totally feel you, I sometimes just set up a local Redmine or simple task list in the lan that really gets used while I make the entries in whatever our corp gods decree the flavor of the month...

liketochill 5y ago
I’ve been using Redmine for nearly a decade. Download the bitnami VM with it preinstalled and away I go. I use it for all my time tracking to generate invoices, and project estimates. Then when working on the project I can put time against an existing estimates task or if I missed something in the estimate or something was added I’ll create a new task for the extra. Works great and I love that the UI hasn’t been redesigned and just works.

jrodthree24 5y ago

This also applies to how we work too. 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.

qudat 5y ago

> 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. 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!

ElFitz 5y ago

Yeah. Another of the issues is that it’s picked by people who (supposedly) chose the right tool for them, without considering wether or not it was optimised for those actually doing the tasks. 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.

robertlagrant 5y ago
It's possible to misconfigure any tool, that's for sure.
- ElFitz 5y ago
  Even more so when those allowed to do the configuring aren’t those that’ll actually have to work with those tools and didn’t bother to ask anyone anything. Just like when creating software, incidentally.

nradov 5y ago

A big checklist of planned changes can work fine for a small team with a single product. It breaks down when you have many teams working on a whole portfolio of products with interdependencies and external customer commitments. In that situation a tool like Jira or Rally is usually the least bad option (unless your organization is huge enough to justify building your own custom project management tool that precisely meets your needs).

vosper 5y ago

IME this is a problem of policy, not of Jira. Empower teams to administer their own Jira projects and it’s fine. But if you lock Jira down and make people beg to some distant and aloof gatekeeper every time they want to change anything, then it’s a recipe for frustration. 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)

robertlagrant 5y ago
Yes, this. I wasn't recognising anyone's problems with Jira, and this is probably why.