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

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

3. 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)

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

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