Team: Three Maintainers and a *ing Op System: Team WikiSpeed Strategic Values/Objectives: Collective collaboration Collaborative workspace (pair mentality) Test to Design (as opposed to Design to Test) Minimize cost through innovative manufacturing Enhance team morale to increase production velocity Be Awesome! Descriptive Statement Be Awesome! Team WikiSpeed will - through the use of Agile, Lean, and Scrum techniques – assemble a team of geographically-distributed members that will develop the next generation of high-efficiency vehicle, while maintaining low costs, adaptability, pleasing aesthetics, and functionality. Team members: The Hammer; Wonder WoManelski; Magic Mike; Woody

Response Situation Analysis for System: Team 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? Eliminate communication/cultural barriers Eliminate ineffective team members Build collaborative environment Improvement What performance characteristics will the system be expected to improve during operational life cycle? Response ability Adaptive learning and implementation Effective communication Migration What major events coming down the road will require a change in the system infrastructure? Technological advances Changes in/Applications of regulations Modification (Add/Sub Capability) What modifications in resources-employed might need made as the system is used? Learning new techniques/applications Determine less-expensive (or free) solutions to unexpected problems Correction What can go wrong that will need an automatic systemic detection and response? Personal injury Ineffective Scrum Master/Project Leader Language barriers Asymmetric schedules Variation What process variables will range across what values and need accommodation? Language barriers Time zone differences World events Expansion (and Contraction of Capacity) What are “quantity-based” elastic-capacity range needs on resources/output/activity/other? Team size Workspace needs Funding/Raw material Reconfigu-ration What types of resource relationship configurations will need changed during operation? Individual responsibilities

Team Wikispeed Agile Engineering Process Graphic template for your modification Resources Integrity Management Development Teams Scrum Master Test Team Product Owner Manufacturing Team Funding Situational awareness Resource mix evolution Resource readiness Activity assembly Infrastructure evolution WikiSpeed Team Scrum Master Everyone Activity Dependent Product Owner Active Infrastructure Passive Config 1 Config 2 Config n Sockets Signals Security Safety Service Peer-to-Peer Interaction Internet Daily stand-up meetings Document/Test reviews XP/XM ConOps

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. Carbon-fiber team Drivetrain team Combustion team CAD modeling team Evolving Infrastructure ConOps and module interface and interaction standards and rules that evolve slowly. Test-driven development Process reviews Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal. Collaborative tools (Google Docs, YouTube, etc.) Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options. Collective collaboration Parallel module work Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules. Modeling & test development Stubs Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure. Open distributed collaboration Team member fluctuation # team members Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Paired engineering Stand-up meetings Swarm engineering Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. Scrum organization Lean Asking questions of “deep nerds” Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary. Crash tests deferred until desired tests achieved through simulation Design patterns (aesthetics) Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. Autonomous module work