Monday, March 3, 2014

Notes on a perspective in managing the acquisition of technology

Managing the processes of creating new Software technologies, delivering a product from conception to implementation, can be described as a process of balancing cost and benefit. A first step is in the identification of the principal issues on the horizon, and their implications for Engineering cost and benefit. The horizon metaphor separates the natural strengths of abstract reasoning in outline from the effort to resolve additional detail: a separation of concerns which translates into qualification, planning, and tasking.

In an Agile process, the challenge is expanded to include a preference for maximizing open options (degrees of freedom) in the evolution of requirements, design, and implementation. This approach describes a dynamic relationship between many contributors to a product development process, either individual or organizational.

This kind of evolutionary process requires two strategies: one within each element of the product development effort, and another among the many elements of the development effort. The element - internal strategy to not close degrees of freedom in product outcome is to minimize the implications of each iteration of an element: to define or close no more than necessary to successfully deliver an increment of work, while applying this principle to issues large and small. The element - external strategy is acquiring and applying the knowledge of which degrees of freedom need to remain open: because the product outcome reference frame is complex, the identity of degrees of freedom is fuzzy, and the external strategy has a significant component of intuition.

Most software projects are developed in a process of evolution that benefits from the Agile / Scrum formalization. This is true for a number of reasons, but one most significant would be that the alternative, relatively static process requires substantially more effort (higher cost per result). Perhaps it's interesting to note the relationship between the Agile formalization and the "less is more" approach found in some projects. Certainly the two principles of "maximizing open degrees of freedom" and "less is more" could be presented as one concept stated in two contexts.

No comments: