So the derivation of Eli Goldratt’s ideas for programming is necessarily different because we are doing artisanal work rather than manufacturing. But yes taken naively it is a measure of Git commits merged into the main branch after running precommit checks and tests and code review and whatever else, and ideally shipping to prod directly. And this is where you want to enable the ability to ship broken code without breaking prod (feature toggles are super handy for this)... This speeds the code review time for example, “oh all that stuff is behind a feature toggle, we won't ship it until it's ready.”

A better derivation of Eli's ideas ultimately causes your entire team to work on one feature before deploying another before deploying another. Sprint planning is “what do we want to take on next, how are we separating it across the team, and how will we pass the baton?” The relay-race baton-pass becomes the crucial concept, whoever has the baton is expected to be working 100% on this thing and only this thing, anyone who does not have the baton is either meant to be preparing to receive the baton, or else they are free to work on whatever refactoring or bug-fixing or side-feature or user support or whatever needs to be done. They are the equivalent of this non-welder helping out. And this is also why it's important for the baton to pass from person to person, because it can be exhausting to hold the baton for too long: what do you call someone who sprints for an hour—a jogger.

This also unlocks the true value of daily standup, which is the person with the baton telling everybody else what they need in order to be successful, and the person who is about to receive the baton to be aware about the timescale at which they have to drop everything else they are doing and work 100% on the next part of the sprint, and the rest of the team checking in on the personal health of the person who has the baton, making sure that they are not overworking themselves to death. Are you okay?

What's at stake is covered in Goldratt’s book Critical Chain, that in a “project context” there is a complex network of dependencies, including hidden ones that come from the raw logical fact that one person can't be working on two different parts at the same time, and the constraint, the thing that actually needs to be tracked and preserved is temporal safety buffer. The default state for a project is that if a step is completed late, that delay has passed on to the next step, but if a step is completed early, that advantage is not communicated to the next step because the person working on the next step isn't ready to drop everything and start working on the project yet.

I actually use these principles to manage the cooking of Thanksgiving meals for our family. My wife was very upset the first time I did it because there was a lot of drawing graphs and stuff, a bunch of diagrams, I had never done it before. But now she wants me to do it every year because it is absolutely intoxicating for her to ask me “what should I be doing right now?” and for me to reply “ nothing, you should rest, but in about 30 minutes you are going to have to drop whatever you are doing and put together everything for the corn casserole.”

That this is how it works should not shock us, not those of us working in web development. Everybody here who works in web development should understand that you overprovision your servers and 90% of the time. They don't do anything. That's not for no reason, it's not because we're wasteful, it because it gives us a much better latency on our incoming requests. Making it clear what the Sprint goal is, and whose shoulders that goal is currently falling upon, is part of making a very low latency system which can respond to whatever fires occur on a day-to-day basis while still getting these longer term projects done ahead of schedule. 80% of the team should be resting or dealing with the latest crisis while one person is legit sprinting on the Sprint goal, and progress on a feature should never have to stall just because the sprinter's significant other is suddenly in the hospital: the feature was owned by the team and the whole team needs to be able to work on it, with everybody checking their work in daily and everybody willing to help out to make the group's deadlines.

I've kind of given the sales pitch for it so let me give one major limitation, a lot of our current methodology is structured in order to identify underperforming people by concrete metrics like how many features they complete, how many story points are those features, and the above methodology kind of creates a space where people can hide: they never take the baton so they never are really in the hot seat, but the whole group takes credit for the success of their individuals. Random assignment and pair programming are one mechanism to rectify the concern and then rectify an obvious concern with that solution (“what if we give a frontend task to a backend programmer?”—answer is, they should do the frontend task, but as the person holding the baton they are running the show and thus entitled to say “I want help, can someone who knows more about frontend code pair with me so that I can just ask “how do I do that in the browser?”).