Dual Track Methodology

Dual Track Methodology+Image

A development process with separate user/feature and developer/architecture tracks.

The Juice

I was recently asked (paraphrasing) what parts of the work of software engineering do I find "juicy" so I came up with this diagram.  Any software engineering task involves both developers (if only me), customers (might be a client), and the processes of design and implementation.

The "external" blue lines are where the customer potentially interacts with the developers, the output of the design, and the implementation phase (you can probably imagine how Agile fits in this.)  The "internal" red lines are where the developers interact with the each other and the design and implementation phases

From a certain perspective, the left side represents the "process" and the right side represents the "results."  Process and results should be balanced - developers may discover they require training in new skills, teams adjust based on where the team is in the process, etc.  The process creates results which the developer and customer team review.

The process - results flow iterates with each result.  The earlier results are produced, the better for everyone because this is where "education" occurs, for example, the developers learn more about the customer's requirements, the customer may refine their requirements (or change them!)  Both the developers and the customers learn things during iterations which in turn create adjustments in the process.

The list of items within the boxes is basically just all the stuff that I find "juicy" - the more of those items that get checked off for a project, the more excited I typically find myself regarding working on the project.

 -- Marc Clifton, February 2017