5 ms·

Check out Beyond The Goal and Beyond The Phoenix Project for a deeper dive in this area. I work in cyber security and use many of the concepts often. The root

Check out Beyond The Goal and Beyond The Phoenix Project for a deeper dive in this area. I work in cyber security and use many of the concepts often. The root cause of many poor outcomes are poor assumptions, prioritizing ideology over customer value, and misaligned shared mental models. I use a simple doc format to address. It's based on evaporating clouds. 1. What's the shared (understanding of current state with a focus on objectivity? 2. What are the problems with current state? Subjectivity is OK here. 3. What's desired state? 4. What are the experiments we can run ASAP to learn if our understanding of desired state is correct and learn how we can get closer. Simple concept. Works great.

hinkley 2y ago
As computer people, I believe we have access to more information on this through the field of Queueing theory. One of the aspects of Queueing theory is responsiveness, and a system with a saturated queue has none. I see this play out over and over again in both machine and human capacity planning. Even with Agile we can’t get stuff done in a satisfactory time frame because we always have a backlog sized for a team twice the size of the one we have, when responsiveness is maximized when the system is running at 50% of maximum throughput. One of my mentors was really into Goldratt and Ohno, but The Goal got stuck in my tsundoku pile for years. I’m a third of the way through it now (I’m using audiobooks to get through books I “should” read but never do), and it is starting to turn into thinly veiled queueing theory, but from what my mentor said he refers to it instead through the metaphor of drum-buffer-rope. But there’s a lot more to this field, and as I said before, you can apply it to our applications directly, not just to the building of them.
- psunavy03 2y ago
  > Even with Agile we can’t get stuff done in a satisfactory time frame because we always have a backlog sized for a team twice the size of the one we have, when responsiveness is maximized when the system is running at 50% of maximum throughput. Agile falls down when people misapply it, same as anything else. It's not just the size of the backlog; it's being able to limit work in progress so that you have the ability to adjust. What's more, management needs to get on board with the idea of probabilistic forecasting that's continually revisited, as opposed to trying to stuff complex work into Gantt charts and deadlines. Sadly, most of modern management refuses to make these changes, and too many folks in the trenches don't want to take ownership of their work and just want to be told what to do.
  - kjellsbells 2y ago
    > management needs to get on board with the idea of probabilistic forecasting that's continually revisited From the manager's pov, though, that just sounds like guesswork. "When will my house be built?" "Eh, not sure, but theres a 60% chance the framing will be up by July". Development managers need to learn to communicate on the same wavelength as their customers, and vice versa. It rarely happens.
    - hinkley 2y ago
      The thing is construction people do talk like that. I think that’s why rich people often make terrible customers. They are just as grouchy at plumbers and general contractors as they are at us. Which reminds me, one of my life goals is to get a full rundown of GC tricks to apply to software development. I’m running out of time for that to make a quality of life difference.
    - psunavy03 2y ago
      You're conflating the complicated with the complex. Construction workers don't need Agile methods, which is why "there's a 60% chance the framing will be up by July" sounds so dumb. The physical properties of wood framing, electrical wire, shingles, and drywall haven't changed in decades. You can make detailed plans around these known facts, and workers generally know predictably what it takes to build a house. Software is not like that. Codebases are too big, especially counting third-party dependencies. Tech debt is lurking everywhere. Customers don't know what they want until they see it. So yes, in enterprise-sized software, you need probabilistic forecasting precisely because you're NOT building a building. It's impossible to know things in enough detail up front to make big up-front plans that don't largely change like you could if you were building a house.
      - pwatsonwailes 2y ago
        I say this with love but, you've never worked in construction have you. Architects drawings are little more than nicely descriptive hopes and sketches of an intended idea, which a good contractor has to turn into an actual plan of work. You want to see chaos go talk to the person running the development of a high end property in New York.
- heymijo 2y ago
  OP mentioned The Phoenix Project [1]. It's The Goal applied to IT. One key issue the protagonist has to overcome is how to address the issue of an endless backlog. [1] https://www.goodreads.com/en/book/show/17255186 https://www.goodreads.com/en/book/show/17255186
- dvfjsdhgfv 2y ago
  > we always have a backlog sized for a team twice the size of the one we have While it certainly is true, the side-effect is at the same time the oldest items in the backlog deprecate with time.
- skybrian 2y ago
  A backlog is not a queue. It's just a mutable list. A principle of Agile is that you can change your priorities and reorganize the backlog to put the currently highest-priority stuff first. (This isn't unique to Agile - any bug database could do this, though they don't typically stack-rank things.) Putting high-priority tasks first increases responsiveness for them, but will starve lower-priority tasks. That's inherent, but at least management gets to prioritize.
  - hinkley 2y ago
    > A backlog is not a queue. That's only slightly true, and it's a dangerous assertion from a process standpoint to say it is so. Everything is queues. Work in progress, undeployed code, dark features, sales pipelines. There is a queue of requirements we have defined but haven't acted upon. That's contained within the backlog, along with bug reports and wishful thinking. The backlog is approximately a superset of incoming feature request queue (modulo anything that skips the backlog and goes straight into WIP)
    - Jtsummers 2y ago
      To expand on your point: Queueing theory applies whether the thing is a proper FIFO queue, a LIFO stack, a statically prioritized priority queue, a dynamically prioritized priority queue, or a bunch of cards grabbed randomly out of a hat. If things keep coming in faster than they can be handled, the queue, no matter its form, will just continue to grow. That a backlog is not a proper FIFO queue in most orgs doesn't change this fact.
    - skybrian 2y ago
      I still think "mutable list" describes the situation better than "queue," at least for programmers familiar with common data structures. No argument that queuing theory is useful. Defining "responsiveness" in terms of everything that anyone has ever wished for seems like a bad thing, though. We can have a brainstorming session that comes up with a long list of features that would be nice to have, end up throwing them out, and that's perfectly fine.
- edorsey 2y ago
  It’s more of a stream or a pipeline than a queue. Wait till you realize optimizing data flow through an API process serving multiple requests is the same meta problem as optimizing value flow through a development team. :)

hinkley 2y ago

As computer people, I believe we have access to more information on this through the field of Queueing theory. One of the aspects of Queueing theory is responsiveness, and a system with a saturated queue has none. I see this play out over and over again in both machine and human capacity planning. Even with Agile we can’t get stuff done in a satisfactory time frame because we always have a backlog sized for a team twice the size of the one we have, when responsiveness is maximized when the system is running at 50% of maximum throughput. One of my mentors was really into Goldratt and Ohno, but The Goal got stuck in my tsundoku pile for years. I’m a third of the way through it now (I’m using audiobooks to get through books I “should” read but never do), and it is starting to turn into thinly veiled queueing theory, but from what my mentor said he refers to it instead through the metaphor of drum-buffer-rope. But there’s a lot more to this field, and as I said before, you can apply it to our applications directly, not just to the building of them.

psunavy03 2y ago
> Even with Agile we can’t get stuff done in a satisfactory time frame because we always have a backlog sized for a team twice the size of the one we have, when responsiveness is maximized when the system is running at 50% of maximum throughput. Agile falls down when people misapply it, same as anything else. It's not just the size of the backlog; it's being able to limit work in progress so that you have the ability to adjust. What's more, management needs to get on board with the idea of probabilistic forecasting that's continually revisited, as opposed to trying to stuff complex work into Gantt charts and deadlines. Sadly, most of modern management refuses to make these changes, and too many folks in the trenches don't want to take ownership of their work and just want to be told what to do.
- kjellsbells 2y ago
  > management needs to get on board with the idea of probabilistic forecasting that's continually revisited From the manager's pov, though, that just sounds like guesswork. "When will my house be built?" "Eh, not sure, but theres a 60% chance the framing will be up by July". Development managers need to learn to communicate on the same wavelength as their customers, and vice versa. It rarely happens.
  - hinkley 2y ago
    The thing is construction people do talk like that. I think that’s why rich people often make terrible customers. They are just as grouchy at plumbers and general contractors as they are at us. Which reminds me, one of my life goals is to get a full rundown of GC tricks to apply to software development. I’m running out of time for that to make a quality of life difference.
  - psunavy03 2y ago
    You're conflating the complicated with the complex. Construction workers don't need Agile methods, which is why "there's a 60% chance the framing will be up by July" sounds so dumb. The physical properties of wood framing, electrical wire, shingles, and drywall haven't changed in decades. You can make detailed plans around these known facts, and workers generally know predictably what it takes to build a house. Software is not like that. Codebases are too big, especially counting third-party dependencies. Tech debt is lurking everywhere. Customers don't know what they want until they see it. So yes, in enterprise-sized software, you need probabilistic forecasting precisely because you're NOT building a building. It's impossible to know things in enough detail up front to make big up-front plans that don't largely change like you could if you were building a house.
    - pwatsonwailes 2y ago
      I say this with love but, you've never worked in construction have you. Architects drawings are little more than nicely descriptive hopes and sketches of an intended idea, which a good contractor has to turn into an actual plan of work. You want to see chaos go talk to the person running the development of a high end property in New York.
heymijo 2y ago
OP mentioned The Phoenix Project [1]. It's The Goal applied to IT. One key issue the protagonist has to overcome is how to address the issue of an endless backlog. [1] https://www.goodreads.com/en/book/show/17255186 https://www.goodreads.com/en/book/show/17255186
dvfjsdhgfv 2y ago
> we always have a backlog sized for a team twice the size of the one we have While it certainly is true, the side-effect is at the same time the oldest items in the backlog deprecate with time.
skybrian 2y ago
A backlog is not a queue. It's just a mutable list. A principle of Agile is that you can change your priorities and reorganize the backlog to put the currently highest-priority stuff first. (This isn't unique to Agile - any bug database could do this, though they don't typically stack-rank things.) Putting high-priority tasks first increases responsiveness for them, but will starve lower-priority tasks. That's inherent, but at least management gets to prioritize.
- hinkley 2y ago
  > A backlog is not a queue. That's only slightly true, and it's a dangerous assertion from a process standpoint to say it is so. Everything is queues. Work in progress, undeployed code, dark features, sales pipelines. There is a queue of requirements we have defined but haven't acted upon. That's contained within the backlog, along with bug reports and wishful thinking. The backlog is approximately a superset of incoming feature request queue (modulo anything that skips the backlog and goes straight into WIP)
  - Jtsummers 2y ago
    To expand on your point: Queueing theory applies whether the thing is a proper FIFO queue, a LIFO stack, a statically prioritized priority queue, a dynamically prioritized priority queue, or a bunch of cards grabbed randomly out of a hat. If things keep coming in faster than they can be handled, the queue, no matter its form, will just continue to grow. That a backlog is not a proper FIFO queue in most orgs doesn't change this fact.
  - skybrian 2y ago
    I still think "mutable list" describes the situation better than "queue," at least for programmers familiar with common data structures. No argument that queuing theory is useful. Defining "responsiveness" in terms of everything that anyone has ever wished for seems like a bad thing, though. We can have a brainstorming session that comes up with a long list of features that would be nice to have, end up throwing them out, and that's perfectly fine.
edorsey 2y ago
It’s more of a stream or a pipeline than a queue. Wait till you realize optimizing data flow through an API process serving multiple requests is the same meta problem as optimizing value flow through a development team. :)