4 ms·

What a pile of rubbish. Adding people to a team already falling behind? Specifically new hires? By the time the new people are up to speed, the experienced o

What a pile of rubbish. Adding people to a team already falling behind? Specifically new hires? By the time the new people are up to speed, the experienced ones will have finished burning out and left, and the cycle continues. Oh, and a system fix is to add process? That's about as counterintuitive as it gets. Especially disingenuous: "A friend is six months into supporting a sixty person engineering group"...you mean managing. Say what you mean, and don't wrap it in nonsense like that.

herval 5y ago
What works, in your experience?
- g051051 5y ago
  If the team is falling behind, stop incoming work until they catch up. If the team is treading water, stop incoming work until they start making progress. If the team is repaying debt but not at the desired capacity, then add more people. In that case, the effort of training and integrating a new person is just another form of debt. In all cases, if the team is overloaded in some way (debt rising, not delivering quality, missing deadlines) also add slack.
  - herval 5y ago
    Have you seen that work anywhere, at any scale? What you’re describing is pretty much every single chronic underperforming team I’ve ever watched. It leads to an organization where everyone is essentially “blocked”, and since work tends to expand to take all available time, it’ll remain “blocked” forever (as you remove the main lever for having to unblock yourself - inbound work)
    - g051051 5y ago
      > Have you seen that work anywhere, at any scale? Of course. It's the only logical and effective way to deal with the problem. > It leads to an organization where everyone is essentially “blocked” There's a big difference from being "blocked", and what the article called "falling behind": >> "A team is falling behind if each week their backlog is longer than the week before. Typically folks are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied." So, you deliver one or two features, or consume a backlog item, but more work comes in, so there's net negative progress (as measured by the list of pending work items). So, you stop the incoming work so that the existing work can proceed to completion, the team can then figure out how to add capacity without falling behind again. If the team is incapable of doing the work for some reason, that's a completely different problem.
      - herval 5y ago
        > Of course. It's the only logical and effective way to deal with the problem. ...where, if you can share?
        g051051 5y ago
        At the last two companies I worked at, before a big management shakeup at my now previous employer. That's when the Agile cultists came in, and started spouting drivel like was in the article. If you want to add capacity, fine, but you can't do it to a team that's already overloaded. When would they have the time to select, train, and integrate new people into their flow, if they don't have any bandwidth? So you put "add capacity" to the top of the backlog, and clear work until it can be done.

herval 5y ago

What works, in your experience?

g051051 5y ago
If the team is falling behind, stop incoming work until they catch up. If the team is treading water, stop incoming work until they start making progress. If the team is repaying debt but not at the desired capacity, then add more people. In that case, the effort of training and integrating a new person is just another form of debt. In all cases, if the team is overloaded in some way (debt rising, not delivering quality, missing deadlines) also add slack.
- herval 5y ago
  Have you seen that work anywhere, at any scale? What you’re describing is pretty much every single chronic underperforming team I’ve ever watched. It leads to an organization where everyone is essentially “blocked”, and since work tends to expand to take all available time, it’ll remain “blocked” forever (as you remove the main lever for having to unblock yourself - inbound work)
  - g051051 5y ago
    > Have you seen that work anywhere, at any scale? Of course. It's the only logical and effective way to deal with the problem. > It leads to an organization where everyone is essentially “blocked” There's a big difference from being "blocked", and what the article called "falling behind": >> "A team is falling behind if each week their backlog is longer than the week before. Typically folks are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied." So, you deliver one or two features, or consume a backlog item, but more work comes in, so there's net negative progress (as measured by the list of pending work items). So, you stop the incoming work so that the existing work can proceed to completion, the team can then figure out how to add capacity without falling behind again. If the team is incapable of doing the work for some reason, that's a completely different problem.
    - herval 5y ago
      > Of course. It's the only logical and effective way to deal with the problem. ...where, if you can share?
      - g051051 5y ago
        At the last two companies I worked at, before a big management shakeup at my now previous employer. That's when the Agile cultists came in, and started spouting drivel like was in the article. If you want to add capacity, fine, but you can't do it to a team that's already overloaded. When would they have the time to select, train, and integrate new people into their flow, if they don't have any bandwidth? So you put "add capacity" to the top of the backlog, and clear work until it can be done.