1. 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.

2. 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

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

4. 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

5. 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