1. Team: _Speed Camel X__________________ Agile System-Engineering Process: Team WikiSpeed
Descriptive Statement
The Team WikiSpeed agile engineering process is the adaptation of the software agile process to hardware development and micro manufacturing. The process allows a distributed team from all over the world to design a product that is modular and lean.
Strategic Values/Objectives
Being lean - use little material as possible
Modular
Distributed team
Rapid Design Cycle
Knowledge sharing

2. Response Situation Analysis (RSA) for an Agile Systems Engineering Process
Change Domain
General Issues
Proactive
Reactive
Creation
(and Elimination)
What artifacts/data/knowledge must the process be creating or eliminating during operational activity?
Project awareness
Improvement
What process performance characteristics will be expected to improve during its operational life cycle?
Risk Management
Activity effort estimating
Migration
What major events coming down the road will require a change in the process infrastructure?
Mass Production
Infrastructure is obsolete
Modification
(Add/Sub Capability)
What modifications to employable resources might need made as the process is used?
Changing team culture
Correction
What will impair/obstruct process agility that will need an automatic systemic detection and response?
Staffing issues
Process buy in
Variation
What process variables will range across what values and need accommodation?
Process overhead
Comfort level with collaboration
Expansion
(and Contraction
of Capacity)
What are “quantity-based” elastic-capacity range needs on resources/output/activity/other?
Amount of resource required
Reconfigu-ration
What types of resource relationship configurations will need changed during operation?
Job role changes

3. Team Wikispeed Agile Engineering Process
Graphic template for your modification
Resources
Integrity
Management
Product Owner
Scrum Mastter
Developers
Tools
Materials
Materials
Situational awareness
Resource mix evolution
Resource readiness
Activity assembly
Infrastructure evolution
Product Owner
Product Owner
Product Owner and Scrum Master
Product Owner
Product Owner
Active
Infrastructure
Passive
Config 1
Config 2
Config n
Sockets
Signals
Security
Safety
Service
What?

4. RRS Principles for System: _Team WikiSpeed_________
(Think: Plug-and-Play, Drag-and-drop)
Reconfigurable
Scalable
Reusable
Encapsulated Resources Resources are encapsulated independent units loosely coupled through the passive infrastructure.
Product Owner Tools
Scrum Master Materials
Developers
Evolving Infrastructure Key elements of the infrastructure likely to evolve and need to be evolvable?
Changing product owner depending on expertise
Learn how to do it yourself
Get new volunteers
Facilitated Interfacing (Pluggable) Resources & infrastructure have features facilitating easy module insertion/removal.
Online chat, message boards, storage, youtube, scrum room, google docs
Redundancy and Diversity Duplicate resources provide fail-soft & capacity options; diversity provides functional options.
Team formed with diverse skills
Pairing
Cross training
Facilitated Reuse Resources are reusable and/or replicable; with supporting facilitation for finding and employing appropriate resources.
Youtube instructional videos, google docs
Elastic Capacity Resource populations & functional capacity may be increased and decreased widely within the existing infrastructure.
Global pool of talent
Peer-Peer Interaction Resources communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored.
No hierarchy, same room or remote interface
Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.
Decision is made by the product owner which changes depending on expertise. Knowledge is recorded and shared through youtube and google docs
Deferred Commitment Resource relationships are transient when possible; decisions & fixed bindings are postponed until necessary.
Focus on current sprint/scrum
Self-Organization Resource relationships are self-determined; and resource interaction is self-adjusting or negotiated.
Volunteers, no hierarchy, no pre-assigned roles among developers/designers. Everybody is equally empowered to do what is needed.