Scrum

Just like DDD and TTD this, surprisingly, is not bullshit. It is not because other people says so, but because it captures some fundamental principles, and the results are just direct consequences of “doing the right thing”.

“Doing the right thing” itself is not a meme. A systematic backtracking search, captured by the A* algorithm, lets say, is both complete and optimal, which is an operational definition of “doing the right thing”.

Scrum distilled, is a sequence of short “steps” (iterations or “sprints”), while at the end of each “step” one corrects one’s course (direction) according to objective measurements.

This implies universal principles like “backtracking and restarts”, which are so essential that almost always neglected, “quicker feedback loops”, “seeing things as the are” (no self-deception, wishful thinking or cognitive biases).

There is nothing new so far. Just an exploration and systematic search problem. It also could be restated as a driving problem, when one has to react to the actual conditions on the road, not some plan, assumptions or imaginary abstractions. On just must do the right thing to survive.

The “magic” comes from prioritizing (according to goal-centered heuristics), planning (of each iteration), measurements (collecting a feedback) and “correcting the course”, which means, re-planing, re-prioritizing and correcting the next iteration (sprint).

The whole thing is, again, a spiral - it moves in some direction in supposedly shrinking recursive “coils”. This is, indeed, a recursion, while the base case remains the same, but each recursive case is being corrected and adjusted, based on the feedback from the previous ones - a properly generalized process.

These are traditionally considered as “management” skills, and applying them to oneself (not some other people) requires self-discipline and deliberate practice .

This is sort of self-observation or even introspection “at the end of the day”. Neglecting it would cause a waste, both of resources and motivation.

the Waterfall

The Waterfall model simply does not work in the “going into an unknown” situation. It does not work even in a “driving along the road” settings, because all the detailed plans became irrelevant in actual “emergent” traffic, full of idiots, drunks and what not.

Driving of a motorcycle is somehow a perfect metaphor for the kind of processes, in which it is not planing but skills and proper reaction (which is another name for adapting to the situation) matter.

These kinds of processes - “driving in a traffic” and “building a cathedral” are in principle, fundamentally different, and the detailed planing in advance is simply not applicable to social or any other kind of dynamics.

Software projects are not cathedrals, precisely because almost every problem domain is a “new one” and “for the first time”, otherwise there would not be any project in the first place.

Cathedrals, on the other hand, are just fancy houses - there is almost nothing “unknown” with them.

Dopamine

The lack of self-discipline comes, in part, from too many choices available.

At any given moment I have

10 different ideas what I could do with my system (rising, etc)
20 different books to read a few pages from.
10 different online courses which I would enjoy refreshing
some youtube videos
and just random browsing through websites, hunting for something new

Notice that all this has very few meaning, but a quick dopamine release. Any small “accomplishment” is the source, and lots of such “accomplishments” can be make up when dopamine is running low.

Yes, messing up with system configuration facilitates problem-solving skills and even programming skills in case of Emacs and Neovim, but this excuse is absurd.

All these random-drift activities are grossly sub-optimal and barely useful, if at all, compared to “straightforward” planned and executed mundane tasks, like cooking of a meal.

The insight is that these activities are both addiction and waste and should be replaced with planned, scheduled, uninterrupted, focused well-defined tasks with explicit goals (stop conditions) and tests to be sure that everything is according to the expectations (the check-expect of Kiczales).

As long as we just drift from one activity to another, following our dopamine instead of our disciplined mind, we are fucked.

Don’t switch until done

The key is to avoid switching activities or even contexts until the task (however small) is done.

Planing of small tasks could easily degenerate into a micro-management addiction, with all these shiny, useless planing tools and systems.

What we must do is just develop some habitual self-discipline and self-control, so we cold finish (complete) any short simple task without switching the context, exactly like athletes do (for different reasons).

Again, short, planned, scheduled, well-defined, uninterrupted, without context-switching, focused “tasks” or “sprints”, each of which has to be finished in a partially-complete state, meaning that everything is “done”, not postponed or left in an inconsistent state.

Following the ABC principle is the least. The reason is that once the mind loses its “currently loaded context” it will not be possible to recreate it to be the same. It will always worse that the one which has been lost due to switching off.

This is a neurological fact - we are very bad at maintaining and recreating our mental “contexts”, and it takes about 15 minutes to reach a required mental state (to prime up some and calm down other circuitry). We ran on neuro-chemicals (modulators and transmitters), not some abstract “free will”.

Social aspects

Scrum is also big in managing (mostly eliminating the toxic) social aspects. This is why it works - it removes waste, instead of adding too much nonsense.

Nothing more to remove, is another emergent universal principle. This is the “base case” for naturally occurred “optimizations” – the less complex system with less “moving parts” will out-evolve all the others.

Only the “simplest” systems work (smallest set of rules).

It tries to limit down and thus optimize unnecessary social interactions, which are well-known to be wasteful and emotionally costly. It begins with an optimal size of a group, which is based on our cognitive capacity limits. We have evolved to function efficiently only in small groups - families, either farming or roaming.

Big groups do not work as efficiently as 5-8 people. This has been observed innumerable times.

Another crucial aspect is that, just like in rural farming communities, everyone has to understand everything what is going on. Not only that, but all the information about the current state of affairs must be shared immediately and freely.

This facilitates quickest possible feedback-loops and cooperation and mutual support, instead of selfish competition, again, just like in a farming setting at the time of harvest or planting.

This is why “removal of any social status within the team” is required. Everyone has to be just like a big family (competing with the neighbors).

The “No assholes” rule, thus, is not a nice wish, it is the required law.

Just rules

Of course, we do not have to explain all the theoretical considerations, like special forces teams, surgeon teams, etc. We also should not invoke the explicit family metaphor to a bunch of unrelated, usually same sex people - this will only make them cringe.

We just set the rules, such that they create an optimal social environment - cooperative and common goal-oriented, just like a military squad deep into the enemy territory.

The common goal without any social positions, social status and any form of a redundant social hierarchy, is what “works” really efficiently, while bureaucracies are just exact opposites.

Every team member has to understand the absolute necessity of woring as a small team and the benefits of removing all the social bullshit from its structure. This is not “managing”, this is an optimal configuration.

Going into unknown

This is the most difficult challenge a man could face. It is easy to do simple, repetitive tasks, like in a gym, but this has nothing to do with facing an unfamiliar problem domain.

All we could hope for is to reduce the complexity, through familiarity and gradual understanding, to well-known underlying principles and familiar mathematical formalisms (provided that the mappings are justified).

In short, everything we optimize out is for going into an unknown and to be able to adapt (backtrack, learn and restart) quickly and “cheaply”. Think of a mountaineering expedition on an unfamiliar range. The same principles apply.

Measure everything

Again, this could easily become and obsession and wasteful addiction, when one measures every single mouse click – that would be bullshit.

We have, however, to measure our actual performance with respect to the changes we just adopt, to obsectively know whether the adaptation or a change “works” or not.

Basically, the only real heuristics are time spent and how many tests fail. It is not “LOCs”, because sometimes a few lines of code have to be researched (the underlying principles and the details have to be understood). Basically, any “/going into an unknown” cannot be measured as a “speed”. It has to be a qualitative metric.