5 ms·

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

by sb8244 8y ago

throwaway9471 8y ago
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.
- praptak 8y ago
  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.
  - Wowfunhappy 8y ago
    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?
    - praptak 8y ago
      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.
- achamayou 8y ago
  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!
- jimjimjim 8y ago
  This explains agile vs reality beautifully.
- mongol 8y ago
  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?
  - throwaway9471 8y ago
    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.
    - lotyrin 8y ago
      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).
- userbinator 8y ago
  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.
kokokokoko 8y ago
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.
- bunderbunder 8y ago
  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.
  - ozim 8y ago
    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.
bloomca 8y ago
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).
munchbunny 8y ago
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".
pzs 8y ago
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.
goalieca 8y ago
It boils down to micromanagement. Engineers shouldn’t be managed by small tickets. They should be given bigger scope of work and manage themselves.
- hn_throwaway_99 8y ago
  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.

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

by sb8244 8y ago

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

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.

praptak 8y ago
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.
- Wowfunhappy 8y ago
  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?
  - praptak 8y ago
    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.
achamayou 8y ago
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!
jimjimjim 8y ago
This explains agile vs reality beautifully.
mongol 8y ago
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?
- throwaway9471 8y ago
  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.
  - lotyrin 8y ago
    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).
userbinator 8y ago
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.

kokokokoko 8y ago

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.

bunderbunder 8y ago
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.
- ozim 8y ago
  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.

bloomca 8y ago

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

munchbunny 8y ago

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

pzs 8y ago

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.

goalieca 8y ago

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

hn_throwaway_99 8y ago
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.