3 ms·

Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/

Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top. This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint. Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.

jameshart 4y ago
I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. It doesn’t have to be Jira backlog grooming, sure. But it has to happen. If the developers aren’t spending their time doing this, who is?
- steveBK123 4y ago
  People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat? How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team? Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
- swiftcoder 4y ago
  > Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
  - crazygringo 4y ago
    > Putting the whole team in a room every week is just going to churn the plan constantly Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change. > inputs likely aren't changing with that frequency In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped. > and you aren't going to be able to pull in all the other stakeholders that often anyway Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint. In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.
    - plorkyeran 4y ago
      My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.
      - steveBK123 4y ago
        What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you." What else do you want us to do for 4-6 hours/week? Write poetry? Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.
- mgkimsal 4y ago
  > Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes. Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts. That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done". When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.
  - steveBK123 4y ago
    Yeah and the larger issue - putting 20 people in a room for 2 hours violates like every single management / efficiency / socio-political recommendation in the book. The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.
  - jameshart 4y ago
    > The promise of "agile" is, IIRC, faster turnaround and iterative development. The promise of agile is working software. Iterative development is a how, not a what.
    - mgkimsal 4y ago
      arguably the goal of any software project is... working software, no? i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so. "agile" itself would seem to be a 'how'. "agile software development" as a phrase is describing - at least too many folks - 'how' the software development will be carried out. but... it's also a massive amount of hair splitting it seems.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- marcosdumay 4y ago
  > How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all. If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.
  - jameshart 4y ago
    Stipulated: many companies suck at engineering management. But in companies that are good at engineering management, you will often find: - weekly planning sessions - daily standups - work ticketing and backlog systems (sometimes Atlassian ones!) - prioritization discussions So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy. P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.

jameshart 4y ago

I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. It doesn’t have to be Jira backlog grooming, sure. But it has to happen. If the developers aren’t spending their time doing this, who is?

steveBK123 4y ago
People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat? How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team? Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
swiftcoder 4y ago
> Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
- crazygringo 4y ago
  > Putting the whole team in a room every week is just going to churn the plan constantly Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change. > inputs likely aren't changing with that frequency In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped. > and you aren't going to be able to pull in all the other stakeholders that often anyway Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint. In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.
  - plorkyeran 4y ago
    My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.
    - steveBK123 4y ago
      What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you." What else do you want us to do for 4-6 hours/week? Write poetry? Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.
mgkimsal 4y ago
> Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes. Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts. That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done". When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.
- steveBK123 4y ago
  Yeah and the larger issue - putting 20 people in a room for 2 hours violates like every single management / efficiency / socio-political recommendation in the book. The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.
- jameshart 4y ago
  > The promise of "agile" is, IIRC, faster turnaround and iterative development. The promise of agile is working software. Iterative development is a how, not a what.
  - mgkimsal 4y ago
    arguably the goal of any software project is... working software, no? i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so. "agile" itself would seem to be a 'how'. "agile software development" as a phrase is describing - at least too many folks - 'how' the software development will be carried out. but... it's also a massive amount of hair splitting it seems.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
marcosdumay 4y ago
> How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all. If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.
- jameshart 4y ago
  Stipulated: many companies suck at engineering management. But in companies that are good at engineering management, you will often find: - weekly planning sessions - daily standups - work ticketing and backlog systems (sometimes Atlassian ones!) - prioritization discussions So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy. P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.