Part I — The Actors
Your blocked processes are now beautifully documented. And still blocked.
The actors, the policy, the mechanism and the separation of concerns
One team, nine months of planned work compressed into three, with the same people.
Agile Scrum methodology is a lot closer to Computer Science fundamentals than one might think. If I were to build this analogy further, something like the following is the result.
Take for example, an ‘Intern’, akin to an Async Task. Think a lot of lightweight tasks, blocked on IO1, much in the fashion an Intern is often delegated work. Think of a lot of grunt work of retrieval of information, lightly digested perhaps2.
Similarly, Associates are more like threads3, capable of more compute than just IO, but not truly independent execution entities yet4.
Junior Devs, a bit more like a Process, can spawn ( read lead ) threads / tasks ( Associates / Interns ), can typically work independently i.e. don’t explicitly need a ‘parent’ execute entity. Interestingly, if the reader may allow me to stretch this analogy a bit further, the work assigned to the “Devs” is representative of how an ‘Instruction Pipeline’ of the CPU is setup. If not frequently switching contexts, the CPU performs optimally, subject to of course some basic decency in writing code5 which AFAIK, is rarer & elusive than gold6.
Senior Devs are analogous to Containers since they are able to cater to a set of composite, perhaps even complex, requirements and be able to serve them as a black box, with a bunch of Processes baked in for them to be able to do that.
A key parallel, the Scrum’s Product Owner, i.e., the Scheduler, makes sure that the highest priority work is queued and as soon as the OS Tick expires, it starts to get executed. Hence the “Backlog” of the Scrum is akin to a “Prioritised, Ordered Queue” from which the individual dev’s Instruction Pipeline is loaded. In an ideal geek’s world this change in the pipeline / context switch should happen at Tick transitions, a.k.a, Sprint Starts and Stops, which again, in a geek’s ideal world are atomic.
Continuing the analogy, the Sprint, rather the duration of the Sprint represents the Tick of the OS, where the Kernel assesses and runs the highest priority tasks to be executed. Within a Sprint, the resources required by the “Devs” are supplied by the OS via Kernel calls and hence the simile between the Kernel & the Scrum Master.
What, one might ask, is the utility of this reductionist model? Well recently a CEO of a Tech Company asked me to help streamline their 50+ Dev Team to be a bit more “efficient”, and it was an interesting experience, and this model helped me connect to the crowd of geeks in the Org.
Separation of policy and mechanism — one of the oldest principles in OS architecture. Both dogmas violate it.
SM is the kernel: services resource requests, unblocks, frees things. Syscalls.
PjM as commonly practiced records status. A logging daemon in this context!
Substitute a logging daemon for your kernel and blocked processes stay blocked. Your blocked processes are now beautifully documented. And still blocked.
One of the best practices I’ve witnessed is the closure of every Story every Sprint, cloned and moved to the next Sprint just to keep the “Velocity” high. This went on for more than a year till I put a stop to it in the first week into the Org.
PM sets policy: what matters, for whom, why → the comparator function PO runs mechanism: which item is next, dispatched now → the scheduler Fuse them and every scheduling decision reopens the strategy question. O(1) peek becomes a debate. Thrashing, in the strict sense.
TBH one person CAN hold both at small scale, the way one core runs two threads as long as it stays a Capacity statement7, not an Identity statement8.
The backlog is a prioritised, ordered queue — a claim about an abstract data type, which says nothing about cost.
My first job involved a day of photocopying which I finished in two hours out of sheer boredom. I have not since encountered a task so thoroughly IO-bound, nor a person so thoroughly blocked on one.↩︎
Productive as they might be, with the advent of the virtuous AI pair programmer, this layer of work is seriously threatened for the wrong reasons!↩︎
You could of course argue that Associates might lean more towards tasks than threads.↩︎
a.k.a GPT Engineers, as the Co-Founder of a Cloud Solutions outfit I recently met with, fondly calls them.↩︎
A very polarising topic, deliberately sitting this one out.↩︎
Or crypto, in all its flavours perhaps.↩︎
In my experience, the younger the PM in age, the more it becomes an identity statement!↩︎
TBH There is a special circle of hell reserved for whoever first wrote “Product Manager / Product Owner” with a slash in the middle. That slash is doing a truly heroic amount of work, in the way “and/or” does heroic work in a prenuptial agreement.↩︎