Interesting approach as it relates to fixed timeline, flexible scope principles as seen in works like Shape Up. Seems clever, as RR ensures short jobs will always be completed faster than long jobs even when we have no prior knowledge of the length of jobs, which is the case most of the time. Small batches have overhead of context switching and large ones, maybe like 6 weeks, act like a FIFO system. A good heuristic for RR scheduling is to ensure 80% of job is cleared through he system in a single quantum of time, where 20% will take multiple trips through the system (we revisit a pitch to improve later, not as a follow on). Not sure if this helps to communicate concern around how teams can connect seemingly disparate small projects (cycles) that roll up into big ideas, especially when incubating a new product. Thoughts?
I’m familiar with RRS in computing, so I’m assuming that’s what you’re referring to. I’d love to hear more! Are you just wondering aloud about applying that to a system of people performing the work, or is there an ongoing discussion about this that you could link to?
Simply about how people performing the work this way might apply to Shape Up cycles.
Conceptually, I am unsure whether round-robin scheduling is compatible with Shape Up. To continue the computing analogy, shaping work is a “pre-processor” that makes sure all the “work packets” are properly sized. This eliminates both the need to actively manage the queue, and the risk associated with keeping unfinished work in limbo. Within a cycle, I would prefer that the build team choose how to sequence work vs. arbitrarily dictating an RRS/FIFO policy.
This is pretty helpful. Thank you.