Agile and MBSE: Fusion or Fission - Modprod2013

Post on 23-Jan-2015

185 views 1 download

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

par.hammarstrom@knowit.se

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