Product Owner Agile Systems Engineering Strategies

Draft INCOSE 2013 Paper

In the Scrum Agile approach there is an important role defined for the Product Owner who is the proxy for the Customer and who is supposed to be engaged in laying out the work to be performed by the team by prioritizing the product Backlog. It turns out that this is a neglected role in the literature with only a few books dedicated just to this role, the most interesting of which is by Prichler [1], while there are many books dedicated to the Scrum Master role. Of course the role is mentioned in many other of the basic books on Scrum, but we would expect more explicit refinement of the role based on the fact it is essential in driving the process. Also in larger organizations this role becomes conflated with that of the Product Manager, and Leffingwell suggests that the Product Owner is a transformation of that role and that Product Owners probably work for the Product Manager on large projects. What is called Product Manager in commercial firms is the Systems Engineer role in aerospace. The Systems Engineer is the person responsible for the whole product working as advertised when delivered to the customer. The techniques that the Product Owner should draw from are those developed in Systems Engineering as a discipline. However, we need to make those techniques of Systems Engineering more agile in keeping with its spirit of increased efficiency and effectiveness in product development. Here we will apply what we learned about the essential structure of the product and its lifecycle in terms of traceability in the paper “The Essential Nature of Product Traceability  and its relation to Agile Approaches” in order to explore the nature of this role, along with the idea of Pichler not mentioned in his book but developed later about multidimensional backlogs.

---

[1] Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. Upper Saddle River, NJ: Addison-Wesley, 2010.

See http://www.mediafire.com/view/?r217d28fzrlh0u1

Hacking The Essence of Software

Working paper on the nature of Software

This paper is a condensation of second part of a monograph called “Tangled Hierarchies” which has been cut down a briefer version for publication. The first part of the paper concerned the way in which tangled hierarchies might be used to model the design of systems, and perhaps give us a way to show the consistency of domain specific design languages like the Integral Software Engineering Methodology (ISEM) first described in Wild Software Meta-systems[1]. In a subsequent paper “Reworking the Integral System Engineering Method Domain Specific Languages” at CSER11 the original language was expanded from 750 to 1700 some statement templates based on research into General Schemas Theory in the dissertation of the author Emergent Design[2]. This further part of the monograph looks again at the core of the realtime minimal methods which is the State Machine along with its dual the Petrinet and attempts to look at them in a new way based on the ideas of C.S. Peirce which are used to re-understand the notion of the Turing Machine. In order to understand Software in its essence we must return to well-worn concepts again and again and attempt to comprehend them more deeply. There are perhaps more secrets for them to give up and sometimes what seems so familiar and commonplace have aspects that are not recognized due to the assumptions we make about them that are unwarranted. C.S. Peirce was the greatest American Philosopher, but is hardly known in many circles where is ideas on Pragmaticism have not been fully appreciated. It could be that his work could give us a new perspective on the Turing Machine and within it the state machine if we applied the principles that he developed in his philosophy and semiotics to the Turing Machine to comprehend it in a new way.

See http://www.mediafire.com/view/?a49r4vefbn7dx2i

---

[1] See http://works.bepress.com/kent_palmer

[2] See http://about.me/emergentdesign

The Essential Nature of Product Traceability and its relation to Agile Approaches

Working Paper written for INCOSE2013

Discussion of the essential features of product traceability maps in relation to requirements, architecture, functional models, components and tests as a set of order type hierarchies and their crosslinks. The paper lays out the structure of these ideal traceability relations which define the essence of the product under development. Then the intrinsic connection of these trace relations to the representations of the product design is discussed. The importance of the trace relations to the product are made clear and then abandonment of traceability in Agile approaches is discussed, and a way to transform between narrative (story) representations that appear in the product backlog and the canonical form of the trace structure of the product is discussed. The fact that it is possible to transform back and forth between narrative and canonic representations of trace structures, and the fact that trace structures can be produced in a just in time fashion that evolves during product development shows that it these trace structures can be used in both an agile and lean fashion within the development process. Also it is shown how by doing trace structure outside the narrative representation has the additional benefit of helping to determine the precedent order of development so rework can be avoided by developing component out of sequence that their technological infrastructure and architectural expression of capability demands. Thus canonical trace structures using this model can be seen as an essential tool for product owners to use to help structure and prioritize the backlog in the Agile approach to software and systems development.

See http://www.mediafire.com/view/?uuhfm8arf8zwpe6

What are the Principles that arise in Practice?:

Working Paper on Principled Software Systems Engineering Practices

Bret Victor (http://worrydream.com/) has made an appeal for Principles in Life and in Software Engineering. His own principle is that creators should not have their tools obscuring their work, so that outcomes are transparent even in Software Programming. He has created some examples of what that means to him which he expresses eloquently in the video “Bret Victor - Inventing on Principle” at http://vimeo.com/36579366. Watching Bret Victor’s presentation brought home to me something I had always felt and believed, but had not articulated very well to myself previously, which is that we need to live by Principles, and guide our lives and our work in the world by Principles, and also if necessary die by Principles (like Freedom). And this includes not just our moral life as he says but our creative life within our chosen vocation. But where I differ with Bret Victor is that there is not just one guiding Principle but many of them in my life’s work and I thought I would attempt to lay the groundwork for expressing something about the nature of principles and their implications in this paper which is inspired by the work of (Bret) Victor.

See http://www.mediafire.com/view/?ce9kscom91shcj0

First tutorial in Systems Science Intensive

I have written a first tutorial in the Systems Science Intensive series which is here.

Systems Science for Systems & Software Engineer Proposed Course Syllabus

I have written a proposed course syllabus for a course in Systems Science for Systems Engineers and Software Engineers. That course syllabus is available here.

ISSS presentations posted

I posted my presentations from the ISSS.org conference July 2012 at http://archonic.net