Dual Track Methodology+discussion

For larger teams, I would add QA processes including acceptance testing in the lower right box and other contribution to the neighboring boxes. Also, a product manager often represents the users in the process rather than users interacting directly with users.

There's quite a few peripheral boxes that could be added. Besides ATP, there's often a set of specialists one has to pull in -- Ui/UX experts, graphic (or more generally, media) designers, domain experts, network experts, tooling/dependency experts, release candidate management, revision after production management, etc. I think that's where a PM's facilitation really comes into play.

But then again, once we add more boxes, we move away from the question that the diagram was personally intended to answer, and more into the realm of complex systems of interaction, agility, roles, etc.

The direction that would be interesting to me is to move towards the process view. Actions and coordination in time and space. As you know, when working as the sole developer for a client there is a very different environment in terms of communication and such. Linear relationships of growth in value/stress ratios, vs. N squared for point to point (phone) networks vs. networked (2 to the N) drive and limit growth.

In big teams, there are the inevitable support systems, issue tracking and all the systems that support product/program management. In OS, we tend to mimic commercial development, after all it is what most of us know in experience, but I think CBPP really requires that we re-examine just how well these fit.

In my design thinking on this, FlowPlace/Space is where we can address these concerns better for OS (CBPP). Tools need to implement JF's concept of holopticism as a technical reality. I don't think JF has a clue how the technology actually works at the detail level; I value his insights for design.