Hacker News Reader

Comment by sb8244 | Hacker News Reader

Asking seriously: is it that it's not possible with today's tools, or philosophically not possible?

I'll try to explain the perspective some people have, including myself, about tools like Jira.

I do not believe that what Jira attempts to accomplish is possible. Organizations tend to utilize Jira to automate project management. I see that as a mistake. I want managers and project owners to be forced to keep the entire project in their head as much as is humanly possible. Software development is a messy process with a lot of moving parts and cliffs someone needs to be looking for to avoid going over.

With Jira I see people attempt to essentially automate keeping track of the project and they stop having a high level and deep understanding of the project. I think Jira helps make certain role's jobs easier, as opposed to making them perform better. In shops where Jira is heavily utilized, most developers and managers tend to get in their own little worlds at the expense of the project as a whole. Which again is because not having to worry about the entire project is more comfortable for everyone at the expense of the overall success of the project.

I find that smaller more specific tools solve enough of the problem of project organization and tracking without the side effect I described above.

I know this is a bit of a hot topic and I understand and appreciate that many people do not share my opinion.

I'd go so far as to say that, when I'm wearing my project manager hat, our tool (which isn't Jira, but is similar) actively wants to make things worse. When I'm wearing my product manager hat, it's simply a disaster.

Sticking everything in a ticketing system makes keeping a project organized more difficult for the same reason that owning lots of stuff makes keeping your house organized more difficult. There's only so many random odds and ends a person can be expected to keep neatly arranged. Especially if keeping them arranged is tangential to their actual job.

I got a lot more effective at my PM responsibilities, with a lot less time spent doing it, after I laid some ground rules limiting the use of ticketing system on my project. One of the main rules was, if nobody needs to be actively thinking about it right now, it doesn't get a ticket.

I have seen attempt to make project roadmap for next 6 months in JIRA, that was terrible. It is confusing for developers, it is confusing for business people, you cannot show it to the customer because they don't care about your tickets. It was too much of work to go through it so stuff that was not built because prio changed had to be closed and all clicking around taking too much time.

I think you should have next 2 sprints of work max in there, probably better if you only make stories for next sprint.

I think the odd thing about this thread is that ticketing systems really only provide me a value-add for stuff that isn't being worked on actively. Oh its time to pick up this ticket, its marked as high priority, here's a conversation about it in the ticket, here's the acceptance criteria, etc. If I know what I'm working on all the time I can just write it down in my notebook. Its the stuff where I needed to step away to another task for a week or something and I've lost my mental model for the last task, that's where JIRA can be a helpful tool IMO.

For the meta project/product management I'm just not sure. I'm endlessly frustrated by estimations and burndown charts that never seem to look good. The estimates are always too high, and the burndown charts often look like horizontal lines (sometimes they even go UP). And you can't figure out the cause of that shit by looking at a chart, or even at the board of tickets. You would need to talk to the team to figure that out.

> I want managers and project owners to be forced to keep the entire project in their head as much as is humanly possible.

So what do you do for projects that are too big for any single person to hold it all in their head?

My manager had a rule, that each member of the team was only allowed to have one unresolved ticket at the end of day.

We had a weekly meeting where we would be badgered about every >1 unresolved ticket and had to come up with an action plan to make sure it never happened again.

So coincidentally, we would "forget" to create a ticket for every issue, that would take more than a day, until it was one day from completion.

This is another excellent example of how making rules only tends to encourage working around them. Things get done when they get done, and no amount of managerial bureaucracy will make things go faster.

I do sometimes follow this rule. Caveat: it requires unassigninig tickets that I'm not actually working on.

It makes some people cringe in horror but once you start doing that it does wonders.

Is the idea behind this "I can only focus on one thing at once, so unassigning myself allows someone else to take up the task in the intirim", or something else?

Mostly this. Obviously, this assumes shared understanding of assignments as "things I'm working on" rather than "queue of things and also commitment do to everything".

Combining the original "one open ticket" rule with the second approach is rather bad. That's why I hope it was used in the context of the first approach.

What gets measured gets done. If closing lots of tickets is seen as productive, you not only get lots of very granular tickets, but all sorts of grouping tickets and epics as well!

But all things considered, was the situation improved by that rule? I understand that it could be worked around ("cheated") but did it bring benefits as well?

If someone has a reason for this rule, feel free to chime in. I believe it was an implicit way to tell us to do overtime off the books.

Most of the issues, that took more than one day, couldn't realistically be completed in one day. Waiting on other parties, too many issues at once, low priority, etc.

Occasionally, a ticket about something non-urgent, with no follow up from the business users, would get dredged up from the past to finally get worked on again. But I would attribute that to generally cleaning up unresolved ticket, rather than a benefit of the rule.

The theory would be that you can't have any more than one "thing I have started doing, and will resume doing first thing in the morning" which should be the meaning conveyed by "in progress" and everything else should be yet-untouched "backlog" or in a priority queue "prioritized" and therefore out-of-mind, or explicitly marked "blocked" with a comment about who or what is blocking it -- so that there's no question about why things aren't getting done or who is working on what (if everything on the board is sitting as "in progress") so people aren't over loaded, haven't bitten off more than they can chew, or have a bunch of things blocked but haven't raised their hand and spoken up about any of them (the typical dysfunctions).

This explains agile vs reality beautifully.

The limitation isn't really our tools, to some large extent it's our brains and our ability to wrap our head around the whole pyramid. In a tiny startup that might be manageable, but even at 20-30 people you have to start abstracting.

When you choose to use JIRA for something, you are giving up an organizational dynamic where you previously depended on judgement, and you are now handling it with process. Judgement is adaptable but very hard to scale, process is rigid but maybe too easy to scale by fiat (whether it's a good process is a different question).

To be clear I don't mean that your PM's become mindless drones the moment you standardize on JIRA. I mean that where previously your 1-week projects and your 6-week projects would use custom planning processes, now with weekly sprints the 6-week project has to subdivide itself. There may be good reasons to subdivide longer projects, but I think this is an example of the class of problems that come from reality slipping through the cracks of processes.

When you look to JIRA or any other tool for the answer, you have to make sure you are not implicitly giving up the role that judgement plays as the safety release valve for procedural red tape. In that sense it's not even the tools' fault, because you can't blame them for trying. It's that the organization has to see the tool as "just a tool".

I think that in a large enterprise organization the scale of people who would have to interact with such a tool (from executives to developers) have reasonably different interests about what sort of information would be helpful for them and in what arrangement. As a thought experiment I can imagine one monolithic monster tool that could cater for all these needs. However, I think its complexity would render it utterly unusable. Much like there is no one person who can work comfortably at each and every level of the org.

Alternatively, this hypothetical tool may be a chain of components/screens/etc. mirroring the various levels in the org. However, I think they would likely provide unusable outputs, because without the precise understanding of how these components build on each other people using the tool wouldn't be able to populate inputs correctly and data may be wrongly classified/consolidated or lost (filtered out) very easily.

There is also infinite flexibility needed for such a tool because as middle management comes and goes they come up with various creative ideas about how to present progress and added value. This may lead to frequent changes in properties that can trickle down to the bottom without any well-defined meaning.

To sum up, I think it would just not be practical.

It depends on your problems. Small companies have different problems in mind than big ones, so it might work pretty well for some smaller companies. In big companies, as GP said, it is often a utopian idea of full transparency and automatic progress generation in one click. Reality is more complex, of course.

JIRA is omnipresent, therefore critique should be taken with grain of salt – you can find complaints about too vague tickets/user stories and complaints about too detailed tickets (with implementation details).

It boils down to micromanagement. Engineers shouldn’t be managed by small tickets. They should be given bigger scope of work and manage themselves.

Depends on who else needs visibility. I definitely agree developers shouldn't be micromanaged, but IMO there is no such thing as an "80% done" ticket - it's either done or it's not. So things may need to be broken down a little more than a particular developer would want so that other team members (e.g. QA, design, management, etc.) can pick up their own tasks if they are dependent.

Reply on news.ycombinator.com