Agile and MBSE: Fusion or Fission - Modprod2013
24
-
Upload
paer-hammarstroem -
Category
Technology
-
view
185 -
download
1
description
When cultures collide: Fusion or Fission? In order to deal with the inherent complexity of large scale development two clear paradigms have emerged during the last decades: - Model Based Systems Engineering, where complexity is handled by levels of abstraction, and - Agile Development, where complexity is handled by delegation and a “frequent inspect and adapt” philosophy Can these approaches be combined in order to reinforce each other or are they mutually exclusive concepts? The presentation is a reflection on my experiences of real life development projects where Agile and MBSE ,in various degrees, have been forced to co-exist. Particular attention will be paid to models as facilitators for sensemaking through dialogue and gestalt in large scale system development. 7th MODPROD Workshop on Model-Based Product Development Linköping University – www.modprod.liu.se – February 5-6, 2013
Transcript of Agile and MBSE: Fusion or Fission - Modprod2013
Knowit Technology Management
When Cultures Collide: Fusion or Fission? - MBSE and Agile
Pär Hammarström Senior Mgmt Consultant
Knowit Technology Management
072 202 6277
MODPROD 2013 Linköping 130206
• My personal experience – no aspiration of universal truth • A handful large scale product development projects
– Several companies in different industries – Cyber-physical, embedded, information systems – 100-500 developers – 3-100 MLoC – Greenfield – >1 year to start of operation
• Long life time expectancy, system will be partly designed and partly evolved after intital start of operation
• Upgrade expensive, will be done in large chunks • High level of integration • -ilities
– Flexibility, safety, resilience, extendability, interoperability, …
Context for This Presentation
Technology Management
Forbidden Area
Technology Management
Product Development is Understanding What to Build
Delivery
Necessary
Knowledge
Technology Management
Accelerate Learning
Real World
Information Decision
Decision making rules
Mental Model
Feedback
Reflection
Technology Management
A Typical Project Model
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Technology Management
Agile?
Analyse & Design
Implement Verify &
Integrate Validate
Lessons Learned
Analyse & Design
Implement Verify &
Integrate Validate
Lessons Learned
Technology Management
Agile?
Analyse & Design
Implement
Verify & Integrate
Validate Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Analyse & Design
Implement
Verify & Integrate
Analyse & Design
Implement
Verify & Integrate
Validate Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Analyse & Design
Implement
Verify & Integrate
Technology Management
Agile?
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
Analyse & Design
Implement
Verify & Integrate
Validate
Lessons Learned
• Team centric
– X-functional Feature Teams!
– Self organization
– Emerging architecture
• Product Owner balance stakeholder’s requirements and guards the vision.
• Emphasis on collaboration and communication
Technology Management
Complexity Handled By Delegation
• Learning per time unit Maximized – Deep understanding of a slice of the design space but narrow
understanding of the problem space, hence, is it the right System we have learned about?
• Feature Teams seldom realistic – Component teams working in a web of dependencies, hence, illusion of
autonomy
• Product Owner needs to be telepathic and omniscient – Myopic design
• Remember Conway’s Law – "organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations“
• What about the –ilities? – Need for Intentional Architecture
Technology Management
Reality
Req Analysis
Architecture & Design
SW Analyis & Design
SW Module Implement-
ation
Module Integration
& Test
System Integration
& Test
System Validation
Model R
epository
Another Idea
Technology Management
Identification Modelling Simulation Review Protoype Test Delivery
Phase
Kn
ow
led
ge
Complexity Handled by Layers of Abstraction
Visual and formal – Reduces misunderstandings
Balanced Architecture and Design
Early and ”cheap” Verification and Validation
Automatic generation of sw, test, documentation
Technology Management
Tim Weilkiens’ blog model-based-systems-engineering.com
Reality
• Validity – Broad understanding of the
problem space but shallow understanding of the design space , hence, illusion of feedback
– Tool focus instead of domain and modelling focus
• Simplification vs completeness – Same level of complexity
as a general programming language
• Inadequate Tools – Diff and merge?
Technology Management
Sensemaking -> Analysis/Insight -> Synthesis/Architecting -> Detailed Design
Dialouge Experimentation/Reflection
Bracketing Formalism Gestalt Supports
Designer Needs
Technology Management
Desig
n
Idea/R
eq
.
Humans are Not Information Processing Devices
Fusion?
Technology Management
Kn
ow
led
ge
ab
ou
t th
e S
olu
tio
n S
pa
ce
Knowledge about the Problem Space
Design Space
Rational boundary
Technology Management
The Design Space
Kn
ow
led
ge
ab
ou
t th
e S
olu
tio
n S
pa
ce
Knowledge about the Problem Space
Design Space
Rational boundary
Technology Management
The Onion and the Orange
Kn
ow
led
ge
ab
ou
t th
e S
olu
tio
n S
pa
ce
Knowledge about the Problem Space
Design Space
Rational boundary
Technology Management
The Onion and the Orange
Kn
ow
led
ge
ab
ou
t th
e S
olu
tio
n S
pa
ce
Knowledge about the Problem Space
Design Space
Rational boundary
Technology Management
Reality
Kn
ow
led
ge
ab
ou
t th
e S
olu
tio
n S
pa
ce
Knowledge about the Problem Space
Design Space
Rational boundary
Technology Management
Fusion View
Technology Management
Vision/Epics
Architectural Runway
Release Train
Pro
du
ct B
acklo
g
Product Management,
Systems Engineers &
System Architects
Te
am
Ba
cklo
g
Te
am
Ba
cklo
g
Release
Planning
Re
lea
se
Ba
cklo
g
Team A
Team B
Iterations Iterations
Version Version ++
Product Owners
System V
alidatio
n / Sp
ike
System V
alidatio
n / Sp
ike
Planning Framework S
yste
ms In
teg
ratio
n
Vis
ion
an
d
Arc
hite
ctu
ral
Inte
grity
PO
D S
cru
m
Adapted from Scaled Agile Framework
• MBSE and Agile Fusion – A Planning Framework is needed – Tools are still very immature
• Rich pictures, gradual transitions, iterations and increments • Whiteboard and post-its still superior for dialouge & gestalt
– Code generation not neccessarily benefical – A Common language is the main benefit – Architural awereness leads to Intentional Architecture
• Fission – Emerging Architecture vs Intentional! – Agility used as an excuse for rituals and happy hacking – MBSE viewed as a formality done after the end of the design
cycle
Summary
Technology Management
