System: Team WikiSpeed Process Strategic Values/Objectives Rapid Rate of Development Low Training Cost Open Source Development Modular Product Architectures Descriptive Statement The WikiSpeed development process enables fast product development and the ability to rapidly make design changes and implement new technologies with a modular product design. New team members can be integrated with little if any direct training. Minimal management is and no long term financial forecasting is required.

Response Situation Analysis for System: Team WikiSpeed Process 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? Facilitates creation of an agile product (didn’t get this section correct, too general) Eliminates wasted resources Improvement What performance characteristics will the system be expected to improve during operational life cycle? Development process efficiency (didn’t get this correction correct, too general) Product performance Migration What major events coming down the road will require a change in the system infrastructure? Lack of volunteers Change in government regulations Modification (Add/Sub Capability) What modifications in resources-employed might need made as the system is used? Add specialized sub-teams Add manufacturing capacity for higher volumes Correction What can go wrong that will need an automatic systemic detection and response? An act of God (flood/tornado/etc) Loss of funding Variation What process variables will range across what values and need accommodation? Number of available volunteers and workers Number of available sub-system teams Expansion (and Contraction of Capacity) What are “quantity-based” elastic-capacity range needs on resources/output/activity/other? Too much open source information to process Not enough funds and volunteers No manufacturing capability or expertise Reconfigu-ration What types of resource relationship configurations will need changed during operation? Customer requirements Loss of key volunteer or access to key resource

RS Analysis of Team WikiSpeed Team: Aero Outcasts Kevin Johnson, Jamey Mulloy, Pete Opper ES678 Agile Systems and Enterprises

System:Team WikiSpeed Sample Graphics for your modification into your system needs Resources Integrity Management Volunteers Team Leads Tests Standup Meetings eee fff Situational awareness Resource mix evolution Resource readiness Activity assembly Infrastructure evolution Team Leaders Team Leaders & Volunteers Tests Kan Ban / Burn Down Schedule Team Leaders Active Infrastructure Passive Config 1 Config 2 Config n Sockets Signals Security Safety Service Peer to Peer Interaction Stand-up meetings/Social Networks Competency Simplicity ConOps Rules/Standards

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. Sub-system Teams Evolving Infrastructure ConOps and module interface and interaction standards that evolve slowly. Minimize Training Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal. Pairing Training method allows fast reallocation of volunteer resources Tool/Consumable Organization Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options. Sprints Multi-cultural Viewpoints Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules. Pairing Training method allows fast reallocation of volunteer resources Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure. Open Source Collaboration Paring Training Method Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Standup meetings and social network communication Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. Teams and Team Leads Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary. Perform empirical testing when funding is available Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. Perform tasks when team resources are available