3 ms·

> If you're changing multiple different components then you need to sync them all up so that they're all releasable at the same time You don't need to sync the

> If you're changing multiple different components then you need to sync them all up so that they're all releasable at the same time You don't need to sync them all up at all. In the majority of cases it's feasible to release multiple changed components one by one. Doing so results in better outcomes than trying to aim for big bang releases. > WIP limits are great until you're waiting for more information from a supplier on one ticket, feedback from a customer on another, and help from an expert from another team on a third ticket, so you sigh and pick up a fourth ticket so you're getting something done. This is a failure of management, not a failure of WIP limits. The correct thing to do in that situation (at least, from the point of view of WIP management) is to down tools and escalate, not to bring more work in.

AndrewDucker 3y ago
Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? I do not think I want to work with people like that. Things can not always be done instantly to fit the whims of developers. The customer may need to get together a few people and discuss what they want, which may take a few days to schedule. People may be doing other important things and not instantly free to drop everything to get you what you need. You may need to realise that you are not the center of the universe.
- regularfry 3y ago
  > Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? It depends on context, but I won't write it off. Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%. If you actually don't care about WIP, sure, pick up the work. > Things can not always be done instantly to fit the whims of developers. It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do. > I do not think I want to work with people like that. That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.

AndrewDucker 3y ago

Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? I do not think I want to work with people like that. Things can not always be done instantly to fit the whims of developers. The customer may need to get together a few people and discuss what they want, which may take a few days to schedule. People may be doing other important things and not instantly free to drop everything to get you what you need. You may need to realise that you are not the center of the universe.

regularfry 3y ago
> Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? It depends on context, but I won't write it off. Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%. If you actually don't care about WIP, sure, pick up the work. > Things can not always be done instantly to fit the whims of developers. It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do. > I do not think I want to work with people like that. That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.