Recent observations and reflections prompted me to ponder this thought:
A Technical Debt Conjecture:
For a given non-trivial project,
Given [z] budgeted sprints,
for [m] developers,
Where for sufficiently large [m],
[n] items of technical debt (or defects) are introduced - as the total for all [commits | builds],
which will subsequently require [x] additional sprints to fix.
One wonders if there are lower limits for [z], [m], [n] that would allow for approximations of [x]?
One wonders what recurring ratios of m:n might occur with some predictable frequency across different organizations, and if those ratios might vary to a greater (or lesser) degree if further considered within the specific vertical context of a given industry?
One wonders if these values are the same for on-shore vs. off-shore vs. hybrid project teams?
One wonders if there is a predictable relationship between m:n and x?
One wonders how the duration [t] of a given project might affect the trend line and predictability of these factors - and if there might be clustering of values around certain frequencies of [t]?
One wonders, given the planned / budgeted value for [z] - at what sufficiently large size of [x] do most organizations kill a project?
One wonders, what ratio of z:x does a project qualify for the 'death march' designation?
One wonders what minimum ratio of m:n should be sufficient, as a monitored metric, to serve as an indicator to management that one or more of the following might apply?
- Requirements may not be [sufficiently | clearly] defined or finalized
- One or more developers may need to be removed from a project team
No comments:
Post a Comment