“Right Side” Technology Systems Paul Titus Rick Dietrich David Sais WikiSpeed Work

Team:. _______Right- Side___________________ System: Team: _______Right- Side___________________ System: ___Wikispeed_______________________ Descriptive Statement Create a highly fuel-efficient, street legal, safe automobile using an all volunteer design/production team. Rethink design so that the vehicle is extremely modular and the design cycle is drastically shorter than current standards. Ability to utilize the cars modularity to customize the vehicle to user’s desire. Strategic Values/Objectives Rapid Configurability 5 Star crash safety rating Greater than 100 MPG fuel efficiency rating High Performance Vehicle High Modularity/adaptability Inexpensive High customer visual appeal

Response Situation Analysis for System: _____WikiSpeed____________ with [t,c,p,s] metric-priorities for each issue, t = time of change, c = cost of change, p = predictability of change, s = scope of change Change Domain Change/Response Issue Proactive Reactive Creation (and Elimination) What must the system be creating or eliminating in the course of its operational activity? Willing/volunteer/diverse project team (t, c); system requirements (t, p); System Tests (t, c, s); system architecture (t, s); Test-based system design (t, c, p); Paired team collective understanding and learning (t, p); Improvement What performance characteristics will the system be expected to improve during operational life cycle? activity effort estimating (p); Team knowledge (t, p) activity completion to plan (t, c, p); Rapid prototyping (s, t) reducing uncertainty and risk (t, p, s); process effectiveness Migration What major events coming down the road will require a change in the system infrastructure? compelling new technology availability (t, c, s); Government regulation change (s, p) project scope change (s); lean process principles (p). Modification (Add/Sub Capability) What modifications in resources-employed might need made as the system is used? new added team member unfamiliar/uncomfortable with management strategy (t); Changing to full production capability (s, p, t, c) Correction What can go wrong that will need an automatic systemic detection and response? inadequate situational awareness (t); wrong focus of requirements (t); inadequate skillset of volunteers (t); failed safety test (t, c); non-compliant supplier (t, c). Variation What process variables will range across what values and need accommodation? expertise and skill levels among team members (p); all-volunteer workforce causes schedule variance (t, c); Procedure compliance (p); availability, interaction, and expertise of customer involvement (s). Expansion (and Contraction of Capacity) What are “quantity-based” elastic-capacity range needs on resources/output/activity/other? Scope changes to production from development (t, c, p, s); team-size changes of x-y volunteers distributed across multiple locations (t, s). Infrastructure expansion required (t, c, p); Reconfigu-ration What types of resource relationship configurations will need changed during operation? unanticipated expertise requirement (t); Governmental regulations change (p, t, c) development activity-sequence priority change (t); system/sub-system design change (s, p)

Team Wikispeed Agile Engineering Process Graphic template for your modification Resources Integrity Management Product owners Scrum masters developers Product backlog Burndown Situational awareness Resource mix evolution Resource readiness Activity assembly Infrastructure evolution Product owner, scrum master, developers scrum master, developers All team members Scrum master Product owner Active Infrastructure Sprint Retrospective Passive Config 2 Config 3 Config 1 Sockets Signals Security Safety Service Collaborative interactions Daily scrum Open communication / team cohesiveness / team interactions Flat organization / peer review Con-ops / iterative development / process

RRS Principles for System: __Team Wikispeed______ (Think: Plug-and-Play, Drag-and-drop) Reconfigurable Scalable Reusable Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure. Prod development teams Evolving Infrastructure Standards ConOps and module interface and interaction standards that evolve slowly. Scrum rules Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal. Daily scrums Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options. Redundant develop & tester scrum teams Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules. Sprint retrospective Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure. Redundant develop & tester scrum teams Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Daily scrum meetings Developer / tester interactions Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. Daily scrums / scrum release milestones / retrospectives Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary. Project backlog prioritization Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. Sprint structure and inherent agility