Software Engineer Toolbox Granularity

My personal approach here is that software creation tooling—both managerial and engineering—is often presented in books and media as monolithic. In reality, these are composites of dozens to hundreds of smaller, independent tools that each bring their own value.

For example, Scrum, single approach theoretically considered as "light", in fact contains 40-50 moving parts (principles, practices, rules, techniques). Applied rigidly as a whole, it fails to deliver the desired result (1, 2).

At the same time, if we consider these Scrum components as independent tools ¹ in our managerial toolbox, they can provide value individually or in tailored combinations.

This applies to any managerial or engineering concept, approach, framework, or practice—all of which contain many more independent fine-grained tools than they initially appear to.

The engineer’s task here is twofold: first, expand their toolbox by extracting these finer tools; second, masterfully combine them for each project’s unique needs "on the fly" ². That requires intentional, dedicated, prolonged correct practice and time to make it second nature.