I’m starting to think of different types of building blocks of software ( from a task definition and management technique ). I may be wrong but suspect this is linked to the thought chain you discussed regarding non-hierarchical, non linear task composition.
A current thought I have is that a concept of a Minimal Deployable Unit is of a great deal of use to me ( which should probably be meaningful deployable unit ).
We’ve ended up with a functioning prototype that is sufficient for us to have confidence in the statement that we know what we are doing.
The issue for us is turning this very well formed brief into shippable code - as there are multiple points of enrichment required to enable subtle new features.to accommodate the enhanced user journey, and the all-or-nothing approach is no good for this project.
So it turns out that it’s looking like an appropriate strategy for us to get this new feature out, in this instance, is to consider deploy-ability first, and to decompose the well formed end goal into well formed deployable chunks ( MDUs ) - potentially having two or three ( or more ) milestones on the way to the end goal.
Now to meet these milestones, we may end up with a few detours enroute to the final end-goal, but, by acheiving these milestones, it looks like we get measurable progress towards our end goal, with ( to some degree ) recognizable overhead.
Now it feels to me like these MDU’s are a little bit of a kick back from the current implementation strategy, but also a reasonably pragmatic way of building software. The classical “product increment” then becomes a set of MDU’s which result in meaningful customer proposition, with the tasks being the set of operations required to achieve a MDU.
I’ve deliberately avoided mentioned scrum and iterations as I’m not sure it’s the best fit for every problem, and i’m hoping to avoid focus on coding rather than product development, but I hope this highlights some of the issues I’m having when a perceived well formed incremental gain is substantially non-atomic. I’m also not too sure how this maps onto or relates to the USM - even having re-read the jeffpatton blog.
Is the concept of an MDU as a building block of software helpful or a distraction?